Loading article…
高水準言語コンピュータアーキテクチャ( HLLCA ) は、ハードウェアの考慮によって決定されるアーキテクチャではなく、特定の高水準プログラミング言語(HLL) を対象とするように設計されたコンピュータアーキテクチャです。したがって、言語指向コンピュータ設計とも呼ばれ、McKeeman (1967) によって造られ、主に 1960 年代と 1970 年代に使用されました。HLLCA は 1960 年代と 1970 年代に人気がありましたが、1980 年代にはほとんど姿を消しました。これは、Intel 432 (1981) の劇的な失敗、最適化コンパイラ、縮小命令セットコンピュータ(RISC) アーキテクチャ、RISC のような複雑命令セットコンピュータ(CISC) アーキテクチャの出現、および HLL 用のジャストインタイムコンパイル(JIT) のその後の開発を受けて起こりました。詳細な調査と批評は、Ditzel と Patterson (1980) にあります。
HLLCA は、HLL の始まりとほぼ同時期に登場した、最初の HLL の 1 つであるALGOL 60 (1960)用に設計されたBurroughs 大規模システム(1961) に遡ります。最もよく知られている HLLCA は、 Lisp言語 (1959) 用の 1970 年代および 1980 年代のLisp マシンでしょう。現在最も人気のある HLLCA は、 Java言語 (1995) 用のJava プロセッサであり、これは一定の成功を収めており、特定のアプリケーションで使用されています。この流れに沿った最近のアーキテクチャはHeterogeneous System Architecture (2012) で、HSA Intermediate Layer (HSAIL) が例外や仮想関数などの HLL 機能の命令セット サポートを提供し、JIT を使用してパフォーマンスを確保しています。
意味
この見出しの下には多種多様なシステムがあります。最も極端な例は直接実行言語 (DEL) です。これは、コンピュータの命令セットアーキテクチャ(ISA) が HLL の命令に等しく、ソースコードは最小限の処理で直接実行できます。極端な場合、必要なコンパイルはソースコードをトークン化し、トークンを直接プロセッサに渡すことだけです。これは、スタックマシンで実行されるスタック指向プログラミング言語に見られます。より一般的な言語の場合、HLL ステートメントは命令 +引数にグループ化され、インフィックス順序はプレフィックス順序またはポストフィックス順序に変換されます。DEL は通常、仮説に過ぎませんが、1970 年代に提唱されました。[1]
それほど極端ではない例では、ソース コードは最初にバイトコードに解析され、それがマシン コードとしてプロセッサに渡されます。これらの場合、コンパイラで十分であると見なされるため、システムにはアセンブラが存在しないのが一般的ですが、場合によっては (Java など)、アセンブラを使用して、コンパイラでは出力されない正当なバイトコードを生成します。このアプローチはPascal MicroEngine (1979) で発見され、現在は Java プロセッサで使用されています。
もっと大まかに言えば、HLLCA は、特定の HLL または複数の HLL をサポートするために特別に設計された機能を備えた汎用コンピュータ アーキテクチャにすぎません。これは、Lisp をサポートするために特別に設計された操作で汎用プロセッサを拡張した 1970 年代以降の Lisp マシンに見られました。
例
Burroughs Large Systems (1961) は、最も初期の HLL の 1 つである ALGOL (1959) をサポートするように設計された最初の HLLCA でした。これは当時、「言語指向設計」と呼ばれていました。Burroughs Medium Systems (1966)は、ビジネス アプリケーション用のCOBOL をサポートするように設計されました。Burroughs Small Systems (1970 年代半ば、1960 年代後半から設計) は、書き込み可能なコントロール ストアによって複数の HLL をサポートするように設計されました。これらはすべてメインフレームでした。
Wang 2200 (1973) シリーズは、マイクロコードの BASICインタープリターを使用して設計されました。
Pascal MicroEngine (1979) は、 UCSD Pascal形式のPascal用に設計され、マシン コードとしてp コード(Pascal コンパイラ バイトコード) を使用しました。これは、その後の Java および Java マシンの開発に影響を与えました。
Lisp マシン(1970 年代と 1980 年代) は、よく知られた影響力のある HLLCA のグループでした。
Intel iAPX 432 (1981) は Ada をサポートするように設計されました。これは Intel 初の 32 ビット プロセッサ設計であり、1980 年代の Intel のメイン プロセッサ ファミリとなる予定でしたが、商業的には失敗しました。
Rekursiv (1980 年代半ば) は、オブジェクト指向プログラミングとLingoプログラミング言語をハードウェアでサポートするように設計されたマイナー システムで、命令セット レベルで再帰をサポートしていたため、この名前が付けられました。
1980 年代後半から 1990 年代前半にかけて、Berkeley VLSI-PLM、その後継 (PLUM)、関連するマイクロコード実装など、 Prolog をより直接的に実装することを目的としたプロセッサとコプロセッサが数多く設計されました。ハードウェアとして製造されなかったシミュレーション設計も数多くありました。Prolog プロセッサを設計するための VHDL ベースの方法論、超伝導体用の Prolog コプロセッサ。Lisp と同様に、Prolog の基本的な計算モデルは標準的な命令型設計とは根本的に異なり、コンピュータ科学者や電気技術者は、基礎となるモデルをエミュレートすることによって生じるボトルネックから逃れようと熱心に取り組んでいました。
ニクラウス・ヴィルトのLilithプロジェクトには、 Modula-2言語向けのカスタムCPUが含まれていました。[2]
INMOS Transputer は、 occam を使用して並行プログラミングをサポートするように設計されています。
AT &T Hobbitプロセッサは、CRISP (C 言語縮小命令セット プロセッサ) と呼ばれる設計から派生し、Cコードを実行するように最適化されました。
1990 年代後半には、Sun Microsystemsやその他の企業によって、スタックベースのJava 仮想マシンを直接 (またはそれに近い形で) 実装した CPU を構築する計画がありました。その結果、いくつかのJava プロセッサが構築され、使用されるようになりました。
エリクソンはErlangを実行するために設計されたプロセッサであるECOMPを開発した。[3]これは商業的に生産されることはなかった。
異種システム アーキテクチャ(2012)の HSA 中間層 (HSAIL)は、基盤となる ISA から抽象化するための仮想命令セットを提供し、例外や仮想関数などの HLL 機能をサポートし、デバッグ サポートも備えています。
実装
HLLCA はスタック マシンを介して実装されることが多く(Burroughs Large Systems や Intel 432 など)、HLL はプロセッサ内のマイクロコードを介して実装されます (Burroughs Small Systems や Pascal MicroEngine など)。タグ付きアーキテクチャは、型をサポートするためによく使用されます (Burroughs Large Systems や Lisp マシンなど)。より過激な例では、非フォン ノイマン アーキテクチャが使用されますが、これらは通常、仮説的な提案にすぎず、実際の実装ではありません。
応用
一部の HLLC は、高速コンパイルと高水準言語によるシステムの低水準制御により、開発者マシン (ワークステーション) として特に人気があります。Pascal MicroEngine マシンと Lisp マシンはその良い例です。
HLLCA は、HLL が命令型プログラミング (一般的なプロセッサに比較的適合) とは根本的に異なる計算モデルを持つ場合に推奨されることが多く、特に関数型プログラミング (Lisp) や論理型プログラミング (Prolog) の場合に推奨されます。
モチベーション
推定される利点の詳細なリストは、Ditzel & Patterson (1980) に記載されています。
HLLCA は直感的に魅力的です。コンピューターは原理的に言語に合わせてカスタマイズできるため、言語を最適にサポートでき、コンパイラの作成が簡単になります。さらに、マイクロコードを変更するだけで複数の言語をネイティブにサポートできます。開発者にとっての主な利点は、マシンからの 高速コンパイルと詳細なシンボリック デバッグです。
さらなる利点は、システム全体を再コンパイルすることなく、マイクロコード (ファームウェア)を更新することで言語実装を更新できることです。これは、インタープリタ型言語のインタープリタを更新することに似ています。
2000 年以降に再び現れている利点は、安全性またはセキュリティです。主流の IT は、ほとんどのアプリケーションで、型やメモリの安全性を備えた言語に大きく移行しました。[要出典] OS から仮想マシンまで、それらが依存するソフトウェアは、保護のないネイティブ コードを活用します。このようなコードには多くの脆弱性が見つかっています。1 つの解決策は、安全な高水準言語を実行するか、少なくとも型を理解するようにカスタム ビルドされたプロセッサを使用することです。プロセッサ ワード レベルでの保護により、スカラー データ、配列、ポインタ、またはコードを区別しない低水準マシンと比較して、攻撃者の仕事が困難になります。学術界では、将来的に高水準プロセッサと統合される可能性のある同様の特性を持つ言語も開発されています。これら 2 つの傾向の例は、SAFE [4]プロジェクトです。言語ベースのシステムと比較すると、ソフトウェア (特にオペレーティング システム) は安全な高水準言語に基づいていますが、ハードウェアはそうである必要はありません。「信頼できるベース」は、依然として低水準言語である可能性があります。
デメリット
詳細な批評はDitzel & Patterson (1980)に掲載されています。
HLLCA が成功しなかった最も単純な理由は、1980 年以降、コンパイラを最適化するとコードがはるかに高速になり、マイクロコードで言語を実装するよりも開発が容易になったことです。多くのコンパイラ最適化ではコードの複雑な分析と再配置が必要なため、マシン コードは元のソース コードとは大きく異なります。これらの最適化は、複雑さとオーバーヘッドのため、マイクロコードで実装することは不可能または非実用的です。類似のパフォーマンス問題は、インタープリタ言語で長い歴史があり (Lisp (1958) にまで遡ります)、Selfで先駆けられ、 HotSpot Java 仮想マシン(1999)で商用化されたジャストインタイム コンパイルによってのみ、実用的に十分に解決されました。
根本的な問題は、HLLCA はコンパイラのコード生成ステップのみを簡素化することです。これは通常、コンパイルの比較的小さな部分であり、計算能力 (トランジスタとマイクロコード) の使用には疑問が残ります。最低限、トークン化が必要であり、通常は構文解析と基本的なセマンティック チェック (未バインド変数) が引き続き実行されるため、フロント エンドにはメリットがなく、最適化には事前の解析が必要なため、ミドル エンドにはメリットがありません。
2014年現在でも開発が活発に行われているより深刻な問題[5]は[アップデート]、機械語からHLLデバッグ情報を提供することが非常に難しいことです。これは基本的にデバッグ情報のオーバーヘッドが原因で、より微妙な問題としては、コンパイル（特に最適化）によって機械語命令の元のソースの特定が非常に複雑になるためです。したがって、HLLCAの重要な部分として提供されるデバッグ情報は、実装を厳しく制限するか、通常の使用で大幅なオーバーヘッドを追加します。
さらに、HLLCA は通常 1 つの言語に最適化されており、他の言語のサポートは劣っています。同様の問題は、他の言語が二級市民であり、セマンティクスにおいてメイン言語に厳密に従わなければならない場合が多い、Java 仮想マシン (Java 用に設計) や .NET共通言語ランタイム( C#用に設計) などの多言語仮想マシンでも発生します。このため、コンパイラ サポートがあれば、低レベルの ISA で複数の言語を十分にサポートできます。ただし、言語に中立であるように見える多くのプロセッサでも同様の問題が発生します。これらのプロセッサはC言語で十分にサポートされており、(ハードウェアを直接ターゲットにするのではなく) C にトランスパイルすると、効率的なプログラムとシンプルなコンパイラが生成されます。
HLLCA の利点は、主にコンパイラやインタープリタを介して、HLL コンピュータシステム(言語ベースのシステム) でも別の方法で実現できます。システムは依然として HLL で記述されますが、より低レベルのアーキテクチャで実行されるソフトウェアに信頼できるベースがあります。これは、1980 年頃から採用されているアプローチです。たとえば、ランタイム環境自体は C で記述されているが、オペレーティング システムとアプリケーションは Java で記述されている Java システムなどです。
代替案
1980 年代以降、汎用コンピュータ アーキテクチャの研究と実装の焦点は主に RISC のようなアーキテクチャに置かれており、通常は内部的にレジスタが豊富なロード ストア アーキテクチャで、言語固有の ISA ではなく、複数のレジスタ、パイプライン、最近ではマルチコア システムを備えた、比較的安定した言語固有ではない ISA を備えています。言語サポートは、コンパイラとそのランタイム、およびインタープリタとその仮想マシン (特に JIT のもの) に重点を置いており、直接的なハードウェア サポートはほとんどありません。たとえば、iOS の現在のObjective-Cランタイムは、ハードウェアがタグ付きアーキテクチャではないにもかかわらず、型チェックとガベージ コレクションに使用するタグ付きポインタを実装しています。
コンピュータ アーキテクチャでは、RISC アプローチが非常に人気があり成功していることが証明されています。これは HLLCA とは対照的で、非常に単純な命令セット アーキテクチャを重視しています。ただし、1980 年代の RISC コンピュータの速度上の利点は、 RISC の本質的な利点ではなく、オンチップ キャッシュと大きなレジスタ用のスペースの早期導入によるところが大きかったです。[引用が必要]。
参照
参考文献
- ^ Yaohan Chuの参考文献を参照。
- ^ 「小型マシン向け Pascal – Lilith の歴史」 Pascal.hansotten.com. 2010 年 9 月 28 日。2012 年 3 月 20 日時点のオリジナルよりアーカイブ。2011年11 月 12 日閲覧。
- ^ 「ECOMP - Erlangプロセッサ」。2021年4月24日時点のオリジナルよりアーカイブ。2022年12月1日閲覧。
- ^ “SAFEプロジェクト”。2019年10月22日時点のオリジナルよりアーカイブ。2022年7月9日閲覧。
- ^ LLVMと Clang コンパイラを参照してください。
- McKeeman, William M. (1967 年 11 月 14 ～ 16 日)。言語指向のコンピュータ設計(PDF)。AFIPS '67 (秋) 1967 年 11 月 14 ～ 16 日秋季合同コンピュータ会議の議事録。第 31 巻。
- Keirstead, Ralph E. (1968 年 3 月)。「R68-8 言語指向コンピュータ設計」(PDF)。IEEE Transactions on Computers。17 ( 3): 298。doi :10.1109/TC.1968.229106。S2CID 41983403 。- レビュー
- Ditzel, David R.; Patterson, David A. (1980)。「高水準言語コンピュータアーキテクチャの回顧」(PDF)。第7 回コンピュータアーキテクチャ年次シンポジウム議事録 - ISCA '80。ISCA '80 第 7 回コンピュータアーキテクチャ年次シンポジウム議事録。ACM。pp. 97–104。doi :10.1145/800053.801914。2014年 11 月 18 日に閲覧。
- パン職人の 13 の教訓: プロセッサ設計における誤解と落とし穴Grant Martin と Steve Leibson、Tensilica (2000 年代初頭)、スライド 6 ～ 9
さらに読む
- ウォートマン、デイビッド・バークレー (1972)。言語指向コンピュータ設計の研究(PhD)。スタンフォード大学コンピュータサイエンス学部。
- Hoevel, LW (1974年8 月)。「「理想的な」直接実行言語: エミュレーションの分析的議論」(PDF)。IEEE Transactions on Computers。23 ( 8)。IEEE: 759–767。doi : 10.1109 /TC.1974.224032。S2CID 29921112 。
- Chu, Yaohan (1975年12 月)。「高水準言語コンピュータ アーキテクチャの概念」。ACM SIGMICRO ニュースレター。6 (4): 9–16。doi :10.1145/ 1217196.1217197。S2CID 9545539 。
- Chu, Yaohan (1975)。 「高水準言語コンピュータ アーキテクチャの概念」。1975年 ACM 75 年次会議議事録。ACM '75 1975 年 ACM 年次会議議事録。pp. 6–13。doi :10.1145/800181.810257。
- Chu , Yaohan; Cannon, R. (1976 年 6 月)。「対話型高水準言語直接実行マイクロプロセッサ システム」。IEEE Transactions on Software Engineering。2 (2): 126–134。doi : 10.1109 /TSE.1976.233802。S2CID 9076898。
- Chu , Yaohan (1977 年 12 月) 。「直接実行コンピュータ アーキテクチャ」。ACM SIGARCH Computer Architecture News。6 (5): 18–23。doi : 10.1145/859412.859415。S2CID 10241380。
- Chu, Yaohan (1978)。「高レベル コンピュータ アーキテクチャにおける直接実行」。1978年 ACM 78 年次会議議事録。ACM '78 1978 年 ACM 年次会議議事録。pp. 289–300。doi : 10.1145 /800127.804116。ISBN 0897910001。
- Chu, Yaohan; Abrams, M. (1981 年 7 月)。「プログラミング言語と直接実行コンピュータ アーキテクチャ」。コンピュータ14 ( 7 ) : 22–32。doi :10.1109/CM.1981.220525。S2CID 3373193 。