パソコン、ワークステーション向けのプロセッサは C 言語がターゲットです。
というよりも、もっと狭くてSPEC CPU ベンチマーク [spec.org]を基準にして
いると言ってもいいと思います(ちょっと言い過ぎかも)。
SPEC cpu は整数系が C (少しC++)、浮動小数点系が FORTRAN 75/90(少し C) で書かれています。
プロセッサ設計の最上流では、SPEC cpu ベンチマークを既存プロセッサで走らせた命令トレースを
手に入れ、その中に出てくる命令頻度、メモリアクセスパターン、キャッシュの挙動を調べ、新しい
機能を考案してゆきます。で、新しいプロセッサのパイプライン・機能ユニットを模したクロック
シミュレータで評価を行うのも SPEC cpu の命令トレース/バイナリです。
# 他所のことは、よく知らんのですが、、、
で、そんなことをやっていますから、C 言語のレベルでは書けない命令(ローテート命令とか)は
どうしてもおざなりになります。
例えば、レジスタ中の 1 が立っているビット数を数える population 命令が、Alpha や POWER 系には
実装されており、ビットを使った集合演算をやろうとすると非常に重宝します。
SPARC の命令セットにもこの命令はあるのですが、UltraSPARC III では実装していません。
Solaris が population を実行すると不正命令例外が発生するので、それをトラップしてソフトウェア
処理します。トホホ。
ISOってなんか意味あるの? (スコア:2, 興味深い)
よく分からないのですが、今のところ.NETフレームワーク以外に使用されるようなことはなさそうですし、標準でなくていいからMSのほうで勝手にやっていてくれという感じです。
ちなみに、
そんなことないと信じています。
というか、C#ってC++
// Give me chocolates!
Re:ISOってなんか意味あるの? (スコア:1)
ISOになると、各国政府がある程度の後押しをすることになってます。
例えば、おそらくJISにもなるでしょうし、情報処理技術者試験の
選択科目にもなるかもしれません。さらにひょっとしたら、中学や
高校の授業でとりあげられるかもしれません。
今すぐの影響は
100年たっても生き残る言語 (スコア:3, 興味深い)
30年どころか、100年たっても間違いなく生き残るであろう言語が少なくとも2つはあるでしょう。アセンブラとCです。
これらの言語の特異な点は、言語のsemanticsに面倒な実行時の支援処理や初期化が一切含まれていないことです。すなわち、自分で作ったエントリポイントにいきなり処理を飛ばしてもきちんと動作するわけです。これは計算機をbootさせるためには
Re:100年たっても生き残る言語 (スコア:1)
アセンブラは今風の延長のCPUがありつづける限り、その「後釜言語」が出現するってことを
考える意味が無いはずなので、そういう意味では未来永劫残るでしょう。
でもCは、後釜言語が出現するかも知れない。
30年後の俺らの後輩?は、今のCと似ているような似てないような後釜言語を
(そういう用途に)使っているかも知れない。
もちろんこれは、たまたま惰性でCが今のまま使われ続ける可能性を否定するものではありません。
ただ、残るにせよ残らないにせよ、それは「たまたま」であって、アセンブラのそれとは違って必然では無い、とは言えると思
Re:100年たっても生き残る言語 (スコア:1)
Cが生き残るのは「低機能で実装が簡単」だからで、機能が足らないから
廃れるってのは逆方向ではないですか?
リンク先読みましたが、組み込み系で多用されているZ80の発展型にガベコレを
実装した環境ってあるのでしょうか?Cに比べて実行時の要求リソースがかなり
大きいと思いますが。実装依存と書いてあるから、Cに匹敵する少リソースでの
実装形態もあるのかもしれませんが。
#Schemeは初めてかじったので、理解が浅い点はご容赦くださ
Re:100年たっても生き残る言語 (スコア:1)
(俺が)しようとしたわけじゃないですし、
恐れ多くもZ80様を忘れようと思っているわけでもありませんm(__)m
StackFrameの話ですが、StackFrameの1種類の使い方しか提供されなくて
変更不能(それを変更することはC自身の領分を超える)ということは、
都合(それこそ処理効率とか)に合わせて色々なStackFrameの使い方を
使い分けるということが出来ない、ということですよね。
ということは、もしそれが可能な(C似かも知れない)言語があったら、Cは
(組み込み用途でも)負ける、のではないか?とは思いました。
Closureだの継続
CPU 設計と C 言語の関係 (スコア:1)
> Cの言語仕様に素直に馴染むような命令ばかりを強化しがち、というような…?
> これだけCが(特定のCPUのブランドなんかより(^^;遥かに)メジャーになってしまえば、
> そういう歩みよりが生じても不思議は無いっすよね。
パソコン、ワークステーション向けのプロセッサは C 言語がターゲットです。
というよりも、もっと狭くてSPEC CPU ベンチマーク [spec.org]を基準にして
いると言ってもいいと思います(ちょっと言い過ぎかも)。
SPEC cpu は整数系が C (少しC++)、浮動小数点系が FORTRAN 75/90(少し C) で書かれています。
プロセッサ設計の最上流では、SPEC cpu ベンチマークを既存プロセッサで走らせた命令トレースを
手に入れ、その中に出てくる命令頻度、メモリアクセスパターン、キャッシュの挙動を調べ、新しい
機能を考案してゆきます。で、新しいプロセッサのパイプライン・機能ユニットを模したクロック
シミュレータで評価を行うのも SPEC cpu の命令トレース/バイナリです。
# 他所のことは、よく知らんのですが、、、
で、そんなことをやっていますから、C 言語のレベルでは書けない命令(ローテート命令とか)は
どうしてもおざなりになります。
例えば、レジスタ中の 1 が立っているビット数を数える population 命令が、Alpha や POWER 系には
実装されており、ビットを使った集合演算をやろうとすると非常に重宝します。
SPARC の命令セットにもこの命令はあるのですが、UltraSPARC III では実装していません。
Solaris が population を実行すると不正命令例外が発生するので、それをトラップしてソフトウェア
処理します。トホホ。
コンタミは発見の母