歴史的に、なぜそれはほぼすべての人と彼らの弟が彼ら自身の呼び出し規約を定義したように見えるのですか?あなたはC、C ++、Windows、Pascal、Fortran、Fastcall、そしておそらく私が言及しようとは思わなかった無数の他のものを持っています。大多数のユースケースでは、1つの規則が最も効率的であるべきではありませんか?どちらか一方を優先する正当な理由はありますか?
5 に答える
あなたが言及する呼び出し規約は、さまざまな言語とさまざまなハードウェアのために何十年にもわたって設計されました。それらはすべて異なる目標を持っていました。cdeclはprintfの変数引数をサポートしていました。stdcallの結果、コードgenは小さくなりましたが、可変引数はありませんでした。Fastcallは、古いマシンでは1つまたは2つの引数だけで単純な関数のパフォーマンスを大幅に高速化できます(ただし、今日ではほとんど高速化されません)。
x64が導入されたときよりも、少なくともWindowsでは、単一の呼び出し規約を持つように設計されていたことに注意してください。
Raymond Chenは、呼び出し規約の歴史に関するすばらしいシリーズを書きました。ここから始めることができます。
歴史的に、すべての人とその弟は独自の呼び出し規約を定義していたからです。それらはすべて異なる目的のために作成されたため、異なるパフォーマンスのニーズによって推進されました。たとえば、C ++は、this
パラメーターを渡すための最適化を優先します。
- それらのいくつかはパフォーマンスに関してより効率的であり、他はコードサイズに関してより効率的です。
- 一部の機能(可変引数カウント)は、一部の規則でのみサポートされます。
詳細情報: http: //en.wikipedia.org/wiki/X86_calling_conventions
その理由の一部は、マイクロプロセッサ(またはプロセッサ)の基盤となるアーキテクチャです。ほとんどの言語は特定のCPUで起動し、そのアーキテクチャに少し絡みます。たとえば、古いUnivac 1100シリーズのコンピューターには、コールスタックすらありませんでした。
理由のもう1つの部分は、いくつかの方法を試してみるまで、最善の解決策を予測することはできないということです。
それらは、さまざまな目的のために、さまざまな最適化システムで作成されています。
たとえば、「スタックオーバーフロー」を減らすために(しゃれは意図されていません)、スタックオーバーフローを不可能にするために関数を呼び出すさまざまなアイデアを考えた人もいます。
もう1つの例は、ラムダ計算です。曖昧すぎないように、ラムダでは、関数は1つの引数を渡し、1つの値を返すだけなので、独自の呼び出し規約も必要です。