言語はCPU設計にどのように影響しましたか？[閉まっている]

私たちはされていることが多い語ったが、これは真実ではない、ハードウェアは、プログラムがそれだけでコンパイルされたバイナリコードを見ているように書かれている言語を気にしないこと。たとえば、謙虚なZ80を考えてみましょう。8080命令セットへのその拡張には、C-スタイル（NULLで終了する）文字列をスキャンするのに役立つCPIRなどの命令が含まれますstrlen()。設計者は、Cプログラムの実行（文字列の長さがヘッダーにあるPascalとは対照的に）が、設計で使用される可能性が高いことを特定している必要があります。別の古典的な例は、Lisp Machineです。

他にどんな例がありますか？たとえば、特定のプロセッサが特定の言語の規則を好むようにする命令、レジスタの数とタイプ、アドレス指定モードはありますか？私は特に同じ家族の改訂に興味があります。

既存の回答は、ISAの変更に焦点を当てています。他のハードウェアの変更もあります。たとえば、C ++は一般的に仮想呼び出しにvtableを使用します。Pentium M以降、Intelには仮想関数呼び出しを高速化する「間接分岐予測」コンポーネントがあります。

Intel 8086命令セットには、戻りアドレスをポップした後にスタックポインターに値を追加する「ret」のバリエーションが含まれています。これは、関数の呼び出し元が関数呼び出しを行う前に引数をスタックにプッシュし、後でそれらをポップオフする多くのPascal実装に役立ちます。ルーチンが4バイト分のパラメーターを受け入れる場合、「RET 0004」で終了してスタックをクリーンアップできます。そのような命令がなければ、そのような呼び出し規約では、コードが戻りアドレスをレジスタにポップし、スタックポインタを更新してから、そのレジスタにジャンプする必要があります。

興味深いことに、元のMacintoshのほとんどのコード（OSルーチンを含む）は、68000に簡単な命令がないにもかかわらず、Pascal呼び出し規則を使用していました。この呼び出し規則を使用すると、パラメータを取るすべての関数のリターンサイトでの4〜6バイトのコード。

1つの例はMIPSです。これには、オーバーフローをトラップおよび無視するための両方がaddありadduます。（またsub、subu。）明示的にオーバーフローを処理するAda（私は思う-実際にはAdaを使用したことはない）のような言語には最初のタイプの命令が必要で、Cのようなオーバーフローを無視する言語には2番目のタイプの命令が必要でした

記憶が正しければ、実際のCPUのALUには、オーバーフローを追跡するための追加の回路がいくつかあります。人々が気にかけている言語がCだけだったら、これは必要ないでしょう。

バロウズ5000シリーズはALGOLを効率的にサポートするように設計されており、IntelのiAPX-432はAdaを効率的に実行するように設計されています。Inmos Transputerには独自の言語であるOccamがありました。Parallax "Propeller"プロセッサは、独自のBASICバリアントを使用してプログラムされるように設計されたと思います。

言語ではありませんが、VAX-11命令セットにはプロセスコンテキストを読み込むための単一の命令があり、これはVMS設計チームからの要求の後に設計されました。詳細は覚えていませんが、ISTRの実装には非常に多くの命令が必要だったため、スケジュールできるプロセスの数に重大な上限がありました。

これまで誰も言及していないように思われることの1つは、コンパイラの最適化の進歩（基本言語はほとんど無関係）が、CISC命令セット（ほとんどが人間によってコーディングされるように設計された）からRISC命令セット（ほとんどがコンパイラーによってコーディングされるように設計されています。）

Motorola 68000ファミリは、CPUを介したデータのコピーを非常に効率的かつコンパクトにする自動インクリメントアドレスモードを導入しました。

[更新された例]

これは68000アセンブラーに影響を与えるC ++コードでした

while(someCondition)
    destination[destinationOffset++] = source[sourceOffset++]

従来のアセンブラーで実装されています（擬似コード、68000アセンブラーコマンドを忘れていました）

adressRegister1 = source
adressRegister2 = destination
while(someCondition) {
    move akku,(adressRegister1)
    move (adressRegister2), akku
    increment(adressRegister1, 1)
    increment(adressRegister2, 1)
}

新しいadressmodeでは、それは似たようなものになりました

adressRegister1 = source
adressRegister2 = destination
while(someCondition) {
    move akku,(adressRegister1++)
    move (adressRegister2++), akku
}

4ではなく、ループごとに2つの命令のみ。

IBMのZシリーズメインフレームは、1960年代からのIBM 360の子孫です。

特にCOBOLおよびFortranプログラムを高速化するためにいくつかの命令がありました。典型的な例は、BXLE「インデックスが低いか等しい場合の分岐」です。これは、ほとんどのFortran forループまたはPERFORM VARYING x from 1 by 1 until x > n単一の命令にカプセル化されたCOBOL です。

COBOLプログラムで一般的な固定小数点10進数演算をサポートするパック10進数命令のファミリもあります。

初期のIntel CPUには次の機能があり、それらの多くは64ビットモードで廃止されました。

• ENTER、LEAVE、およびRET nn命令[初期のマニュアルでは、ネストされたプロシージャをサポートするPascalなどのブロック構造化言語用に導入されたことが明示されています]
• BCD演算を高速化するための指示（AAA、AAMなど）。x87のBCDサポートも
• カウントループを実装するためのJCXZおよびLOOP命令
• INTO、算術オーバーフローでトラップを生成するため（例：Ada）
• テーブルルックアップ用のXLAT
• 配列の境界を確認するための境界

多くのCPUのステータスレジスタにある符号フラグは、符号付きおよび符号なしの演算を簡単に実行するために存在します。

SSE 4.1命令セットは、カウントおよびゼロ終了（PCMPESTRなど）の両方のストリング処理用の命令を導入します

また、多くのシステムレベルの機能が、コンパイルされたコードの安全性をサポートするように設計されていることを想像できました（セグメント制限チェック、パラメーターコピーを使用したコールゲートなど）。

主にモバイルデバイスに搭載されている一部のARMプロセッサには、ハードウェアJVMインタープリターであるJazelle拡張機能が含まれます。Javaバイトコードを直接解釈します。Jazelle対応JVMは、ハードウェアを使用して実行を高速化し、JITの多くを排除できますが、バイトコードをチップで解釈できない場合でも、ソフトウェアVMへのフォールバックは保証されます。

このようなユニットを備えたプロセッサには、プロセッサを特別な「Jazelleモード」にするBXJ命令が含まれています。または、ユニットのアクティブ化が失敗した場合、通常の分岐命令として解釈されます。ユニットは、ARMレジスタを再利用してJVM状態を保持します。

Jazelleテクノロジーの後継はThumbEEです

私が知る限り、これは過去により一般的でした。

ジェームズゴスリングが、JVMバイトコードをより良く処理できるハードウェアを作ろうとしている人がいると言った質問のセッションがありますが、これらの人々は、一般的な「汎用」Intel x86（おそらく巧妙な方法でバイトコード）。

彼は、大企業が製品に巨額の資金を投じているため、一般的な一般的なチップ（Intelなど）を使用する利点があると述べました。

ビデオはチェックアウトする価値があります。彼はこれについて19分または20分で話します。

私は簡単なページ検索を行いましたが、Forthを実行するために特別に開発されたCPUについて誰も言及していないようです。Forthのプログラミング言語はスタックコンパクト、ベース、及び制御システムに使用されます。

インテルiAPX CPUは、特にオブジェクト指向言語のために設計されました。ただし、うまくいきませんでした。

iAPX 432（インテルアドバンスド・プロセッサ・アーキテクチャは）3つの集積回路のセットとして1981年に導入されたインテル初の32ビットマイクロプロセッサの設計でした。1980年代のIntelの主要な設計を目的としており、多くの高度なマルチタスクおよびメモリ管理機能を実装していました。そのため、この設計はマイクロメインフレームと呼ばれていました...

iAPX 432は「完全に高級言語でプログラムされるように設計され」、Adaが主要であり、ハードウェアとマイクロコードでオブジェクト指向プログラミングとガベージコレクションを直接サポートしていました。さまざまなデータ構造の直接サポートは、iAPX 432の最新のオペレーティングシステムを通常のプロセッサよりもはるかに少ないプログラムコードで実装できるようにすることも目的としていました。これらのプロパティと機能により、当時のほとんどのプロセッサ、特にマイクロプロセッサよりもはるかに複雑なハードウェアとマイクロコードの設計が行われました。

当時の半導体技術を使用していたインテルのエンジニアは、設計を非常に効率的な最初の実装に変換することができませんでした。時期尚早のAdaコンパイラの最適化の欠如に加えて、これはかなり遅いが高価なコンピューターシステムに寄与し、同じクロック周波数（1982年初期）で新しい80286チップの約1/4の速度で典型的なベンチマークを実行しました。

かなり低プロファイルで低価格の8086ラインとの最初のパフォーマンスギャップが、おそらく後者（x86として知られる）をiAPX 432に置き換えるインテルの計画が失敗した主な理由です。エンジニアは次世代の設計を改善する方法を見つけましたが、iAPX 432 機能アーキテクチャは、単純化されたサポートではなく、実装のオーバーヘッドと見なされるようになりました。

iAPX 432プロジェクトは、Intelにとって商業的な失敗でした...

68000にはMOVEMがあり、これは複数のレジスタを1つの命令でスタックにプッシュするのに最も適していました。

コード全体でJSR（Jump SubRoutine）の前にMOVEM（MOVE Multiple）が表示されている場合、Cに準拠したコードを扱っていることを一般的に知っています。

MOVEMでは、デスティネーションレジスタの自動インクリメントが許可されており、各ユーザーはデスティネーションでのスタックを続行でき、自動デクリメントの場合はスタックから削除できます。

http://68k.hax.com/MOVEM

AtmelのAVRアーキテクチャは、完全にCでのプログラミングに適した設計になっています。たとえば、このアプリケーションノートはさらに詳しく説明します。

IMOこれはrockets4kidsの優れた回答と密接に関連しており、初期のPIC16-sは直接アセンブラープログラミング用に開発され（合計40命令）、後のファミリーはCをターゲットにしています。

8087数値コプロセッサーが設計されたとき、言語ではすべての浮動小数点演算を最高精度の型を使用して実行し、結果を低精度の変数に割り当てるときに結果を低精度にのみ丸めることがかなり一般的でした。たとえば、元のC標準では、シーケンスは次のとおりです。

float a = 16777216, b = 0.125, c = -16777216;
float d = a+b+c;

昇格aとbをdouble追加し、追加し、昇格cしdouble、追加し、結果をに丸めて保存しfloatます。多くの場合、コンパイラがtype floatで直接操作を実行するコードを生成する方が高速でしたが、type doubleでのみ動作する一連の浮動小数点ルーチンと、に変換するルーチンを持っている方が簡単でした以下からfloatの操作を処理するためのルーチンの別のセットを持っているよりも、floatとdouble。8087は算術へのアプローチを中心に設計されており、80ビット浮動小数点型を使用してすべての算術演算を実行します[80ビットが選択された理由は次のとおりです。

1. 多くの16ビットおよび32ビットプロセッサでは、仮数と指数の間でバイトを分割する値を処理するよりも、64ビットの仮数と指数を処理する方が高速です。

2. 使用している数値型の完全な精度まで正確な計算を実行することは非常に困難です。たとえばlog10（x）のようなものを計算しようとする場合、64ビットの1ulp以内の正確な結果を計算するよりも、80ビット型の100ulp以内の正確な結果を計算する方が簡単かつ高速です。タイプし、前者の結果を64ビット精度に丸めると、後者よりも正確な64ビット値が生成されます。

残念ながら、この言語の将来のバージョンでは、浮動小数点型の動作方法のセマンティクスが変更されました。言語が一貫してそれらをサポートしていれば8087セマンティクスは非常に素晴らしかったでしょうが、関数f1（）、f2（）などがtypeを返すfloat場合、多くのコンパイラ作成者はそれを引き受けてlong double64ビットdouble型のエイリアスを作成しますコンパイラの80ビット型ではなく（80ビット変数を作成する他の手段を提供しません）、次のような任意の評価を行います。

double f = f1()*f2() - f3()*f4();

次のいずれかの方法で：

double f = (float)(f1()*f2()) - (extended_double)f3()*f4();
double f = (extended_double)f1()*f2() - (float)(f3()*f4());
double f = (float)(f1()*f2()) - (float)(f3()*f4());
double f = (extended_double)f1()*f2() - (extended_double)f3()*f4();

f3とf4がそれぞれf1とf2と同じ値を返す場合、元の式は明らかにゼロを返すはずですが、後者の式の多くはそうではないことに注意してください。これにより、最後の定式化は一般に3番目の定式化よりも優れていたとしても、拡張ダブルタイプを適切に使用したコードでは8087の「余分な精度」を非難することになりました。

その間、Intelは言語の（残念ながら）中間の結果をオペランドの精度に丸める傾向にある（IMHOの不幸な）傾向に対応しました。中間計算の精度。