パソコン、ワークステーション向けのプロセッサは 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 を実行すると不正命令例外が発生するので、それをトラップしてソフトウェア
処理します。トホホ。
OS によっては 2つの呼び出し規約は現代でも混在しています。
UNIX が C 言語で記述されたように、
初代 Mac OS は Pascal で記述されました。
その名残で Mac OS の API は PASCAL規約の呼び出しルールを持っています。
Windows も同様です(本当は __stdcall)。
C規約の関数呼び出しは C 言語自体の仕様ではないですが、
非常に一般化しています。
そのため、
Window や Mac の C 処理系では、
OS のシステムコールを直接呼び出したり、OS に渡すコールバック関数を作ることなどが、言語の範囲内ではできません
(無論、処理系独自の拡張で凌いでいます)。
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が今のまま使われ続ける可能性を否定するものではありません。
ただ、残るにせよ残らないにせよ、それは「たまたま」であって、アセンブラのそれとは違って必然では無い、とは言えると思います。
だから、「アセンブラと、Cのような中級言語と」が残る、という説ならまだなんとなく納得がいきます。
もっとも、未来における中級言語のメジャーな位置付け自体が、上か下のどっちかにシフトしてしまう可能性も
ないわけではないでしょうから、後釜がCに十分(?)似てるという保証すら、必ずしも無いのですが。
なお、Schemeの実装におけるスタックフレーム [dreamhost.com] あたりを読んでいると、
Cの(メジャーな(と言っていいですか?俺ぁ疎いもんで御免))実装の Stackの使い方とかは、
色々考えられる実装形態のうちの1つでしかなくて、それ以外の実装
(たとえばこの例ではScheme寄りの)を支援しないものに過ぎない、のだなと思っちゃいます。
つーか、そのとおりですよね?
そういう意味では、そのCの限界を超えられる言語は常に必要であり、それがアセンブラだったり
アセンブラとCの間くらいの高級度のなんらかの言語だったり、するのだろうと思います。
>もっとも、アセンブラがどういう言語かという問題は残りますが、LispマシンだったらLispがアセンブラのようなものですしね。
うーん。そうなんだろうか?
Luspマシンって、ユーザプログラミングのために提供された(隠されなかった)部分の高級度が、 Lispのソレであるわけですよね。
アセンブラというノリじゃないような気がします。
むしろ大昔のパソコン(^^;でいうROM BASICに近い位置付だったりしませんかね?
もちろん言語の出来が違いすぎるんで、BASICとLispでは色々な面で比較にならないでしょうけど、ね。
Re:100年たっても生き残る言語 (スコア:2, 参考になる)
Lisp マシンというのは、CPU の設計からすでに LISP 向きに設計されているものをさすのだと思います。例えば、あらゆるメモリにはかならずタグがついており、car や cdr など基本関数はハードウェアで実装。GCもマイクロコードでやったりとか。少なくともいまはなき Symbolics Machine という Lisp マシンは、アセンブラコードがかなり Lisp に近いもので、car, cdr, cons とかに相当するものが並んでました。
Re:100年たっても生き残る言語 (スコア:0)
Re:100年たっても生き残る言語 (スコア:1)
Cが生き残るのは「低機能で実装が簡単」だからで、機能が足らないから
廃れるってのは逆方向ではないですか?
リンク先読みましたが、組み込み系で多用されているZ80の発展型にガベコレを
実装した環境ってあるのでしょうか?Cに比べて実行時の要求リソースがかなり
大きいと思いますが。実装依存と書いてあるから、Cに匹敵する少リソースでの
実装形態もあるのかもしれませんが。
#Schemeは初めてかじったので、理解が浅い点はご容赦ください。
あっと、100年後の話でしたね。100年後でも、消費電力の関係やサイズの関係で
強力なCPUを採用できないとか、コストをギリギリまで削る必要のある用途では
低速低機能なCPUの用途は無くならないと思います。そもそもZ80程度の能力で
済んでしまうというような用途も無くならないでしょう。低機能CPUの需要が
無くならない限りは、低機能なC言語の需要も無くならないでしょう。
-//-
Re:100年たっても生き残る言語 (スコア:1)
> 実装した環境ってあるのでしょうか?
CP/M-80上で動くLispはありましたね。Prologも。APLも。
昔、TIかどっかで作ってた、PC-Schemeでしたっけ、直接
機械語に落す処理系があったと思うんですが、あれは
ターゲットプロセッサは何だったかな。
最近のものでマイクロコントローラ向けに書かれたものとしては
Bitとか。http://www.iro.umontreal.ca/~dube/ から論文への
リンクがあります。68HC11とかで走らせることを念頭に置いて
いるとか。ただ、実装はCで素直に書かれたVMのようです。
Re:100年たっても生き残る言語 (スコア:1)
(俺が)しようとしたわけじゃないですし、
恐れ多くもZ80様を忘れようと思っているわけでもありませんm(__)m
StackFrameの話ですが、StackFrameの1種類の使い方しか提供されなくて
変更不能(それを変更することはC自身の領分を超える)ということは、
都合(それこそ処理効率とか)に合わせて色々なStackFrameの使い方を
使い分けるということが出来ない、ということですよね。
ということは、もしそれが可能な(C似かも知れない)言語があったら、Cは
(組み込み用途でも)負ける、のではないか?とは思いました。
Closureだの継続だのを持ち込みたい(それが贅沢であるのか否かという議論は
ここではしません。つーか俺もまだ全然理解してないので回避)とまで
言わずとも、もっと安直なところで、関数呼び出しの処で、どうStack(とレジスタ)を
使うことにするか、なんてな問題も有りますよね。
ああいう処って、特に小さいCPUでは、きめ細かく使い分けたくなるものでは無いのでしょうか?
それとも、StackFrameの使い方を使い分ける、なんていうニーズは
組み込み方面にも無い、ということなのでしょうか?
いや、それは(素人には)考えにくいなあ。玄人考えでは考えやすいことなのでしょうか?(^^;
そりゃそうと、むしろCPUのほうが「Cに都合の良いように」作られてる、ってことは無いでしょうか?
Cの言語仕様に素直に馴染むような命令ばかりを強化しがち、というような…?
これだけCが(特定のCPUのブランドなんかより(^^;遥かに)メジャーになってしまえば、
そういう歩みよりが生じても不思議は無いっすよね。
>組み込み系で多用されているZ80の発展型にガベコレを
>実装した環境ってあるのでしょうか?Cに比べて実行時の要求リソースがかなり
>大きいと思いますが。
べつにSchemeを実装しろとかいうつもりは無いです。
「あーいう(どーいうのでもいいんだけど、とにかくCとは違う)Stackの使い方」
をするような何かを実装したくなることは無いですか?という話をしたかったのであって。
それとももしかして、「1つのCPUではStackの使い方は多様である必要は無い」と実用的に言えるのでしょうか?
それならば、そのCPU用にCコンパイラを1つ移植すれば(その際にStackの使い方を1つ授ければ)
済むことだ、といえるようにはなりますが、そういうことなのですか?
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 を実行すると不正命令例外が発生するので、それをトラップしてソフトウェア
処理します。トホホ。
コンタミは発見の母
Re:100年たっても生き残る言語 (スコア:1)
わたしも玄人なんておこがましいこと言えるようなもんじゃないです。
そんなこと言ったら、本物の玄人が裸足で逃げだしてしまいます。
私にはStackFrameを使い分けるという概念がありません。
だから、どんなメリットがあるのかも理解できません。
よければ例を示していただけると。ポインタでもかまいませんので。
CPUがCに都合よくというのは歴史的には賛成できませんが
現実的に、基幹部がCで開発されることが主流である以上
あり得ない話ではないと思います。もっとも、基幹部のCに
高級アセンブラ以上の意味があるとは思えませんが。
「1つのCPUではStackの使い方は多様である必要は無い」
1つのCPUに、多様なStackの使い方が実装されている例があれば。
私はStack Lineを複数持つCPUは知っていますが、
Stack Frameの使われ方が複数あるCPUは知りません。
ところで、Cのいいところはアセンブラとの直交性です。
直交性の確保できない処理系で、Cを採用する必要はないと思います。
-//-
スタックフレームの使い分け (スコア:1)
C規約呼び出しの利点は caller が完全にフレームを制御するので、 可変長引数などが実現可能な点。複数の関数呼び出しが連続するとき フレームの解放をさぼれる点でしょう。
PASCAL規約呼び出しの利点の方は現在では認識し難たいですが、 以下のようなストーリーがあります。
RISC アーキにとってスタックレジスタ(sp) は汎用レジスタの 1本にすぎません。 しかし、CISC アーキにとって、sp は push / pop など命令と結び付く特別なレジスタでした。
CISC のリターン命令の中には、 RISC でいうところの return 命令と sp 操作を同時に行う効果を持つものがあり、 この命令を使える分callee 側でのフレーム解放は効率が良かったのです。
OS によっては 2つの呼び出し規約は現代でも混在しています。
UNIX が C 言語で記述されたように、 初代 Mac OS は Pascal で記述されました。
その名残で Mac OS の API は PASCAL規約の呼び出しルールを持っています。 Windows も同様です(本当は __stdcall)。
C規約の関数呼び出しは C 言語自体の仕様ではないですが、 非常に一般化しています。 そのため、 Window や Mac の C 処理系では、 OS のシステムコールを直接呼び出したり、OS に渡すコールバック関数を作ることなどが、言語の範囲内ではできません (無論、処理系独自の拡張で凌いでいます)。
p.s.
PASCAL規約が残っているのは、歴史的な理由が多いので、これをスタックフレームの使い分けの例として出すと、ご不満かもしれません。
もう少し効果のあるスタックフレームの使い分けてとしては、 コンパイラの関数間最適化による register promotion を挙げておきます。
コンタミは発見の母
Re:スタックフレームの使い分け (スコア:1)
以前どっかで聞いたような気がしますが、Pascal呼び出しだと、Stack後始末をするコードを持つ個所が、
「呼び出す側」じゃなく「呼び出される側」になることによって、その「数」が減る、という話だったような。
それ以外の例としては、やっぱり、Schemeの実装におけるスタックフレーム [dreamhost.com]あたりが参考になる、んでしょうか。
特に
>但し、現存するScheme処理系の多くはベースにC言語を用いており、このような特殊な スタック操作が実装しにくくなっています。
という辺りが、
Cと違うStackの使い方が欲しくなることが(こういう風に)有るのを物語っているんじゃないかと。
まあScheme(Lisp系)なので、「関数」という概念の定義自体がCのそれとは微妙に違う
(ルーチンおよびそれに直接従属する"状態"しか持たないCの関数に対し、
Lispの関数はルーチンに従属せずヨソからアクセスも可能な"状態"を持つことが出来るらしい。
つーかこれがClosureとかいう奴ことらしい。そういう考え方を導入するメリットについては
それこそそっちの頁とかを読んで下さい。俺もAuto変数とStatic変数だけじゃウンザリするのは十分経験済み)
ので、CのStackFrameとがらっと違うStackFrameが(効率を上げるために)要求されるのは、当然なんでしょうけどね。
Re:100年たっても生き残る言語 (スコア:1)
> よければ例を示していただけると。ポインタでもかまいませんので。
下のほう(#186702)に書いたもので、お役に立ったでしょうか?
>CPUがCに都合よくというのは歴史的には賛成できませんが
でも、ほかの方の話だと、なんかあながち嘘でもないようですし(^^;;;。
#歴史的って何でしょう?CPUが設計され生産されればそれは全部「歴史」なので、実装が1つでも有れば条件を満たしますよね?
実際、CPUにありがち(って俺も多数のCPUを知っているわけじゃないですが)な命令だけど
Cでは直接呼べない命令、ってのは幾つか有るわけでして。Rotate系とか。
関数にしてやればいいのは確かですが、たった1命令を実行してすぐ戻る関数なんてナンセンスです(^^;し、
Inlineを使うこととかを考慮しても、いずれにせよメリットを引き出すためには
Cそのものの能力を逸脱した何かをしないと無理っぽい。
そういう意味では、Cは「命令数が十分だとは限らない」高級アセンブラっすね。
>1つのCPUに、多様なStackの使い方が実装されている例があれば。
>私はStack Lineを複数持つCPUは知っていますが、
>Stack Frameの使われ方が複数あるCPUは知りません。
ん?CPU側の問題じゃないですよね。言語(つーかプログラム)側の問題。
CPUに与えられたStackを、言語がどう使うか?という問題ですよね。
そしてそれは、べつに一対一の関係ではなく、一対多の関係です。
#与えられた制約の範囲内なら「なんでも」やれるのが、ソフトウェアです(^^;
Re:100年たっても生き残る言語 (スコア:1)
C言語が生まれた後のCPUに限って言えば、違う結論もあるということです。
"「命令数が十分だとは限らない」高級アセンブラ"には同意。
C言語の仕様範囲だけではローテイトもできなきゃOver/UnderFlowの検出もできない。
そういうことは _asm 使えと言うことで。
1命令実行して戻る関数なんてのは、今時のコンパイラはinline展開するし
そもそもマクロ定義にするのが妥当でしょう。
StackFrameの使い方で効率を上げられる。CはStackFrameの使い方が硬直化していて
効率を上げられないということですよね?問題は、どんな用途の効率なのかが明らかで
ないことだと思います。C言語はFarm, OS Karnel, Driverといった、Hardware criticalな
部分では生き残るでしょうが、appricationの記述で使われることはもう無いでしょう。
もっと「効率」のいい言語がありますから。
hardware architectureとの親和性、assemblerとの親和性の高さは、開発「効率」を
高めるために絶対必要な条件ですが、C言語はこの条件を満たしています。
hardware criticalでない用途なら、それ用の言語を探すなり作るなりすれば良いことで
C言語のStackFrameをどうこう言う必要もないように思いますが、いかがか。
-//-
Re:100年たっても生き残る言語 (スコア:1)
>効率を上げられないということですよね?問題は、どんな用途の効率なのかが明らかで
>ないことだと思います。
(略)
>hardware architectureとの親和性、assemblerとの親和性の高さは、開発「効率」を
>高めるために絶対必要な条件ですが、C言語はこの条件を満たしています。
そうでしょうか?条件満たしてますかね?
たしかX68000方面で聞いた話だったような気がします(雑誌の立ち読み(笑)で
目の端に触れた程度の「知識」でしかなくあやふやですみません)が、
ええとなんだったかな…たしかWindowシステムが導入されたときの話だったと思ったけど、
従来の各種のC言語処理系およびライブラリと、新しいGUIライブラリとでは、
2byte整数の引数を渡すとき、それを2byteのままStackに積むか、4byteに拡張してから積むか、
という流儀の違いが(なんでだか俺は知らないが)生じ、Stackを「積みなおす」ラッパー
(Cじゃ書けないですよねえ)が介在する必要が有った、なんていう話があったように記憶しています。
まあ、ライブラリのほうを作り直しやがれ、と怒られるような気もしないでもないですが、
少なくともこれは、アセンブラとかに片足突っ込むような「低級」面における
Cのゲンカイを示す1例かなんかに、なっているような気がするんですが、どうでしょうか?
高級方面だけにStack云々の問題が有るわけではなく、それどころかむしろ低級方面にその問題は多いんじゃないかと
俺は邪推します。少なくとも高級方面では、富豪的に「そんなもん同じにしとけ。面倒だからよ。」
で済ませてしまってもバレない(^^;ことのほうが多いんじゃないかなあ?
それとも、アセンブラレベルにおいても、Stackの使い方の違いというものは、
「気にするに値しないほど些細な」問題にしか見えない問題であるのでしょうか?
Re:100年たっても生き残る言語 (スコア:1)
>という流儀の違いが(なんでだか俺は知らないが)生じ、Stackを「積みなおす」ラッパー
>(Cじゃ書けないですよねえ)が介在する必要が有った、なんていう話があったように記憶しています。
こいつは「int型のサイズは規定なし、システムに都合がいいように決める」という仕様から派生する問題です。
問題であることには違いは無いですが、
>>hardware architectureとの親和性、assemblerとの親和性の高さ
を優先した結果であって、単純に「欠陥」といえるものではありません。
>少なくとも高級方面では、富豪的に「そんなもん同じにしとけ。面倒だからよ。」
>で済ませてしまってもバレない(^^;
「hardware architectureとの親和性」といってる時点で高級方面の話じゃないですよね。
少なくとも高級方面だけを考えればいいなら、Cよりもいいものはいくらでもありますよ。
Cを使う必然性はまるでないと言ってもいいかもしれない。
>それとも、アセンブラレベルにおいても、Stackの使い方の違いというものは、
>「気にするに値しないほど些細な」問題にしか見えない問題であるのでしょうか?
8bitから64bitまで、Stackが数KB程度の組み込み用途からサーバまでといった守備範囲の広さがCの強みでしょう。
かなり手を加える必要がある場合も多いですが、あるは程度のソースの流用が効きます。
Cというのは「Stcakに何byte積むか」といった面での互換性問題よりも「限られたりソースを効率よく利用できる」ことを優先することでアセンブラに比べれば高い移植性と互換性を幅広くサポートしようとする方向性を持っているので、富豪的アプローチを前提としている処理系と同じ土俵で比べることには無理があります。
100年後も生き残っているかはかなり疑問ですが、(アセンブラは別として)Cと同じような守備範囲で他に代替できるプログラム言語が登場しない限りCは生き残っていくでしょう。
うじゃうじゃ
Re:100年たっても生き残る言語 (スコア:1)
どこら辺が満たしてないんでしょうか。
新旧2つの処理系の間に違いがあるといわれても、、、だから?としか。
別にCに限った話でも何でもないような。
ライブラリを新しい処理系でrebuildすれば済みそうにも聞こえますし。
低水準で.b/.w/.dwのstack sizeが重要なのは当然ですね。
把握してなければ簡単に暴走するんですから。
高級言語なら、内部は全部Veriantなんてことしたってかまわんでしょう。
でも、それはStackFrameの使われ方とは別の話ではないですか?
この程度の内容に落ち着くんでは、Schemeの話は意味が無くなってしまいます。
結局、C言語のStackFrameではどんなことをしようとしたときに効率が悪いのか?
という疑問には答えてもらえないんでしょうか?
-//-