バローズ・ラージ・システムズ

Burroughs Large Systems Group は、高密度シラブルのスタックマシン命令セットを使用する48 ビットの大型 メインフレームファミリを製造しました。^{[NB 1]}このファミリの最初のマシンは 1961 年の B5000 で、シングルパス コンパイラを使用してALGOL 60プログラムを非常にうまくコンパイルできるように最適化されていました。B5000 は、B5500 (ドラムではなくディスク) と B5700 (最大 4 つのシステムをクラスターとして実行) に進化しました。その後の主要な再設計には、B6500/B6700 ラインとその後継製品、および独立した B8500 ラインが含まれます。

1970 年代、Burroughs Corporation は、ハイエンド、ミッドレンジ、およびエントリーレベルのビジネス コンピュータ システム向けに、非常に異なる製品ライン アーキテクチャを持つ 3 つの部門に組織されました。各部門の製品ラインは、特定のプログラミング言語用にコンピュータの命令セットを最適化する方法に関する異なるコンセプトから生まれました。「Burroughs 大規模システム」は、COBOLに最適化された中規模システム(B2000、B3000、および B4000) や柔軟なアーキテクチャの小規模システム(B1000) とは対照的に、これらすべての大規模システム製品ラインをまとめて指していました。

1880年代に設立されたバローズ社は、コンピュータ業界で継続して事業を行っている最古の企業でした（バローズ社より前に設立されたエリオット・ブラザーズは、19世紀にはコンピュータ機器を製造していませんでした）。1950年代後半になっても、同社のコンピュータ機器は、センシマティックなどの電気機械式会計機に限られていました。大規模なコンピュータの製造を開始していた従来のライバルであるIBMやNCR 、あるいは設立されたばかりのユニバックと競合できるものは何もありませんでした。1956年に、同社はエレクトロデータ社を買収し、その設計をB205としてブランド変更しました。

バローズの最初の社内開発マシンであるB5000は1961年に設計され、バローズは当時利用可能な最も先進的なコンピューティングのアイデアに基づいた完全に異なる設計の戦略で、市場への参入が遅れたことに対処しようとしました。B5000アーキテクチャは廃止されましたが、B6500（および後続のB6700とB7700）に影響を与えました。そのアーキテクチャを使用したコンピューターは、^{B6700で最初に導入された}MCPオペレーティングシステムの進化型で互換性のあるバージョンを実行するUnisys ClearPath Libraサーバーとして^[要出典]まだ生産されていました。3番目で最大のラインであるB8500 ^{[1] [2] は商業的に成功しませんでした。独自の}CMOSプロセッサ設計に加えて、UnisysはIntel Xeonプロセッサも使用し、LibraサーバーでMCP、Microsoft Windows、Linuxオペレーティングシステムを実行します。カスタムチップの使用は徐々に排除され、2018年までにLibraサーバーは数年間完全にコモディティIntelになりました。

最初のシリーズの最初のメンバーであるB5000 ^{[3]は、1961年に}ロバート（ボブ）バートン率いるチームによって設計が開始されました。これは珍しいアーキテクチャでした。コンピュータ科学者のジョン・マシーは、これを最も賞賛するアーキテクチャの1つとして挙げています。「私はいつも、これが私が見た中で最も革新的なハードウェア/ソフトウェア設計の例の1つであり、時代をはるかに先取りしていると思っていました。」 ^[4] B5000の後継機は、ドラムストレージではなくディスクを使用したB5500 ^[5]と、共有ディスクの周りに複数のCPUをクラスター化できるB5700でした。B5700の後継機はありませんでしたが、B5000シリーズはB6500の設計に大きな影響を与え、バロウズはマスターコントロールプログラム（MCP）をそのマシンに移植しました。

• ハードウェアはソフトウェア要件をサポートするように設計されている
• 高級プログラミング言語専用に設計されたハードウェア
• 簡素化された命令セット
• アセンブリ言語やアセンブラはありません。すべてのシステム ソフトウェアは、 ESPOLと呼ばれるALGOL 60の拡張版で記述されています。ただし、ESPOL には、アーキテクチャ内の各音節に対するステートメントがありました。
• 部分的にデータ駆動型のタグ付きおよび記述子ベースの設計
• プログラマがアクセス可能なレジスタが少ない
• すべての操作が明示的なオペランドではなくスタックを使用するスタック マシン。このアプローチは、現在では好まれなくなっています。
• すべての割り込みとプロシージャ呼び出しはスタックを使用する
• COBOLなどの他の言語のサポート
• 強力な文字列操作
• すべてのコードは自動的に再入可能: プログラマーは、示されている 2 つの単純なプリミティブを使用するだけで、任意の言語のコードを複数のプロセッサに分散させることができます。
• オペレーティング システム(MCP、マスター コントロール プログラム)のサポート
• 非対称（マスター/スレーブ）マルチプロセッシングのサポート
• データへの不正アクセスや業務の中断を禁止する安全なアーキテクチャの試み^{[NB 2]}
• ソフトウェアの開発とテストをサポートする早期エラー検出
• 商用実装の仮想メモリ。これより先行しているのはFerranti Atlasだけです。
• 最初のセグメント化メモリモデル

B5000 は、アーキテクチャと命令セットがソフトウェアのニーズを考慮して設計されたという点で、当時としては珍しいものでした。これは、プロセッサとその命令セットが設計されてからソフトウェア担当者に引き渡されるという当時のコンピュータ システム設計からの大きな逸脱でした。

ワード モードの B5000、B5500、および B5700 には、メイン プログラム (SALF オフ) を実行しているか、サブルーチン (SALF オン) を実行しているかに応じて、2 つの異なるアドレッシング モードがあります。メイン プログラムの場合、オペランド コールまたは記述子コール シラブルの T フィールドは、プログラム参照テーブル (PRT) に相対的です。サブルーチンの場合、アドレッシングのタイプは、B5x00 相対アドレッシングに示すように、T の上位 3 ビットとマーク スタック フリップフロップ (MSFF) に依存します。

B5000 は高級言語のみをサポートするように設計されました。これは、そのような言語がFORTRAN、次いでCOBOLで注目され始めた頃でした。FORTRAN と COBOL は、現代のソフトウェア技術に関しては弱い言語であると考える人もいたため、より新しく、ほとんど試されていない言語であるALGOL-60が採用されました。B5000 に選ばれた ALGOL 方言はElliott ALGOLで、 CAR HoareがElliott 503で最初に設計および実装しました。これは、I/O 命令 (ALGOL では無視されていた) と強力な文字列処理命令を備えた ALGOL の実用的な拡張でした。Hoare の有名なチューリング賞講演はこの主題でした。

このように、B5000 は非常に強力な言語に基づいていました。ドナルド・クヌースは、夏休みの 3 か月間に、以前の Burroughs マシンにALGOL 58 を実装しており、コンサルタントとして B5000 の設計に間接的に関わっていました。多くの人は、高級言語はアセンブラと同じパワーを持つことはできないと誤解し、ALGOL を軽視していたため、システム プログラミング言語としての ALGOL の可能性を認識していませんでした。

Burroughs ALGOL コンパイラは非常に高速でした。これは、オランダの科学者Edsger Dijkstraが B5000 Pasadena 工場でコンパイルされるプログラムを提出したときに感銘を受けました。彼のトランプはほとんど即座にコンパイルされ、彼はすぐにオランダのアイントホーフェン工科大学で数台のマシンが欲しくなりました。コンパイラが高速だった理由はいくつかありますが、主な理由はワンパス コンパイラだったことです。初期のコンピュータにはソース コードを格納するための十分なメモリがなかったため、コンパイラ (さらにはアセンブラ) は通常、ソース コードを複数回読み取る必要がありました。Burroughs ALGOL 構文では、公式言語とは異なり、各変数 (またはその他のオブジェクト) は使用前に宣言する必要があるため、データを 1 回だけ読み取る ALGOL コンパイラを作成できます。この概念には深い理論的意味合いがありますが、非常に高速なコンパイルも可能になります。Burroughs の大規模システムは、パンチ カードからソース コードを読み取るのと同じ速さでコンパイルでき、業界で最速のカード リーダーを持っていました。

強力な Burroughs COBOL コンパイラもワンパス コンパイラであり、同様に高速でした。4,000 枚のカードの COBOL プログラムは、1 分あたり 1,000 枚のカードを処理するリーダーがコードを読み取るのと同じ速さでコンパイルされました。カードがリーダーを通過するとすぐに、プログラムが使用できるようになりました。

B6500 ^[7]（1969年に納品^{[8] [9]}）とB7500 ^[要出典]は、今日まで生き残っている唯一のバローズシステムラインの最初のコンピュータでした。これらはB5000に触発されていましたが、完全に新しいアーキテクチャを持っていました。最も重要な違いは、

• B6500 には、12 ビット シラブルの固定長命令ではなく、8 ビット シラブルの可変長命令がありました。
• B6500は48ビットワードではなく51ビット^{[NB 3]}を持ち、3ビットをタグとして使用した^[10]
• B6500には対称型マルチプロセッシング（SMP）が搭載されていた。
• B6500にはサグアロスタックが搭載されていた
• B6500にはページアレイがあった
• B6500 には、ネストされたサブルーチンが外部ブロック内の変数にアクセスできるようにするディスプレイ レジスタ (D1 ～ D32)がありました。
• B6500は、磁性薄膜メモリを備えたモノリシック集積回路を使用していました。^[8]

1971年には、B6700とB7700の他の顧客にはニュージーランドの5つの大学が含まれていた。^[11]

B8500 ^{[1] [2]}シリーズは、 B5000にインスピレーションを得た軍用コンピュータである D825 ^{[12]から派生したものです。}

B8500は1960年代にB5500とD825の設計を統合する試みとして設計された。このシステムは、磁気薄膜メモリを備えたモノリシック集積回路を使用した。アーキテクチャはB5500と同様に48ビットワード、スタック、および記述子を採用したが、上位互換性があるとは宣伝されていなかった。^[1] B8500は確実に動作させることができず、プロジェクトは1970年以降キャンセルされ、完成したシステムは提供されなかった。^[2]

仮想記憶の中心概念はフェランティ・アトラスとライス研究所コンピュータの設計に現れ、記述子とタグ付きアーキテクチャの中心概念は1950年代後半のライス研究所コンピュータ^[13]の設計に現れた。しかし、たとえそれらの設計がバロウズに直接影響を与えたとしても、B5000、B6500、B8500のアーキテクチャはアトラスやライスマシンのものとは非常に異なっており、それらは互いにも大きく異なっている。

Burroughs の最初の大型システムは B5000 でした。1961 年に設計されたこのシステムは、個別のトランジスタロジックと磁気コア メモリを使用した第 2 世代のコンピュータであり、その後に B5500 と B5700 が続きました。B5000 アーキテクチャを置き換えた最初のマシンは、B6500 と B7500 でした。B6500 と B7500 の後継マシンは、ハードウェア開発のトレンドに従い、次の 25 年間で新しいロジックでアーキテクチャを再実装し、B6500、B7500、B6700、B7700、B6800、B7800、B5900、^{[NB 4]} B7900、そして最終的に Burroughs A シリーズになりました。Burroughs がSperry Corporation を買収してUnisysに社名を変更した後も、同社はMCP CMOS ASICに基づく新しいマシンの開発を続けました。これらのマシンはLibra 100からLibra 500までで、Libra 590は2005年に発表されました。590を含むそれ以降のLibraにはIntel Xeonプロセッサも組み込まれており、エミュレーションとMCP CMOSプロセッサの両方でBurroughs大規模システムアーキテクチャを実行できます。Unisysが新しいMCP CMOS ASICの開発を継続するかどうかは不明です。

ハードウェアとソフトウェアの設計、開発、製造は、カリフォルニア州オレンジ郡とフィラデルフィア郊外の 2 つの主要拠点に分かれて行われていました。B5000 と B5500 を開発した当初の大型システム工場はカリフォルニア州パサデナにありましたが、カリフォルニア州シティ オブ インダストリーに移転し、そこで B6500 を開発したのです。カリフォルニア州ミッション ビエホの工場を拠点としていましたが、時には近くのアーバインやレイクフォレストにも施設を置いていたオレンジ郡の拠点では、小型の B6x00 ラインを担当し、ペンシルベニア州トレディフリンを拠点とする東海岸の事業所では、大型の B7x00 ラインを担当していました。両方のラインのすべてのマシンは完全にオブジェクト互換であり、一方のマシンでコンパイルされたプログラムは、もう一方のマシンでも実行できました。新しい大型モデルには、古い低速モデルではサポートされていない命令がありましたが、ハードウェアは、認識できない命令に遭遇すると、それを解釈するオペレーティング システム関数を呼び出しました。その他の違いとしては、プロセス切り替えと I/O の処理方法、メンテナンスとコールド スタート機能などがあります。より大規模なシステムには、ハードウェア プロセス スケジューリング、より高性能な入出力モジュール、より高機能なメンテナンス プロセッサが含まれています。Bxx00 モデルが A シリーズ モデルに置き換えられたとき、違いは保持されましたが、モデル番号で簡単に識別できなくなりました。

バロウズ ALGOL

パラダイム	マルチパラダイム：手続き型、命令型、構造化型
家族	アルゴル
デザイン：	ジョン・マクリントック、他
開発者	バローズコーポレーション
初登場	1962年; 62年前 （1962年）
プラットフォーム	バローズの大規模システム
OS	バロウズMCP
影響を受けた
アルゴル60
影響を受けた
ESPOL、MCP、NEWP

Burroughs の大規模システムは、ALGOL 由来のスタック アーキテクチャを実装しています。B5000 は、最初のスタック ベースのシステムでした。

B5000 は ALGOL をサポートするために特別に設計されましたが、これは出発点にすぎませんでした。COBOL などの他のビジネス指向言語も十分にサポートされており、特に高速コンパイラの開発用に組み込まれた強力な文字列演算子によってサポートされていました。

B5000 で使用される ALGOL は、拡張された ALGOL サブセットです。強力な文字列操作命令が含まれていますが、特定の ALGOL 構造、特に未指定の形式パラメータは除外されています。DEFINE メカニズムは、 C の#defineと同様の目的を果たしますが、プリプロセッサではなく言語に完全に統合されています。EVENT データ型はプロセス間の調整を容易にし、ON FAULT ブロックはプログラム障害の処理を可能にします。

ALGOL のユーザー レベルには、オペレーティング システムやその他のシステム ソフトウェアに必要な安全でない構成要素の多くが含まれていません。2 つのレベルの言語拡張によって追加の構成要素が提供されます。MCP および密接に関連するソフトウェアを作成するための ESPOL と NEWP、および特定の種類のシステム ソフトウェアにさらに具体的な拡張機能を提供するための DCALGOL と DMALGOL です。

もともと、B5000 MCP オペレーティング システムは、拡張 ALGOL の拡張であるESPOL (Executive Systems Programming Oriented Language) で記述されていました。これは 70 年代半ばから後半にかけてNEWPという言語に置き換えられました。NEWP はおそらく単に「新しいプログラミング言語」を意味していたのでしょうが、その名前には伝説があります。当時 Burroughs 内でよく語られていた (おそらく作り話の) 話では、この名前は「No Executive Washroom Privileges」に由来していると言われています。別の話では、1976 年頃、Burroughs の John McClintock (NEWP を開発していたソフトウェア エンジニア) が、再び「まだ名前は決まっているのか」と尋ねられた後、その言語を「NEWP」と名付けました。「にゃーーー」と答えたので、それを名前として採用しました。NEWP も ALGOL 拡張のサブセットでしたが、ESPOL よりも安全で、ALGOL のあまり使用されていない複雑さがいくつか取り除かれていました。実際、ブロックがそれらの命令を許可するように明示的にマークされていない限り、すべての安全でない構造は NEWP コンパイラによって拒否されます。このようなブロックのマークにより、マルチレベルの保護メカニズムが提供されます。

安全でない構造を含む NEWP プログラムは、最初は実行できません。システムのセキュリティ管理者は、そのようなプログラムを「承認」して実行可能にすることができますが、一般ユーザーはこれを行うことができません。(通常、基本的にルート権限を持つ「特権ユーザー」でさえ、サイトが選択した構成によってはこれを行うことができない場合があります。) NEWP は一般的なプログラムの作成に使用でき、大規模なソフトウェア プロジェクト向けに設計された多数の機能を備えていますが、ALGOL のすべての機能をサポートしているわけではありません。

NEWP には、名前付きインターフェイス (関数とデータ)、インターフェイスのグループ、モジュール、スーパーモジュールなど、オペレーティング システムなどの大規模なソフトウェア プロジェクトを可能にする機能が多数あります。モジュールはデータと関数をグループ化し、モジュール内でグローバルとしてデータに簡単にアクセスできるようにします。インターフェイスにより、モジュールは関数とデータをインポートおよびエクスポートできます。スーパーモジュールにより、モジュールをグループ化できます。

オリジナルの実装では、システムは接続された専用データ通信プロセッサ (DCP) を使用して、リモート デバイスとの間のメッセージの入出力を処理していました。これは、従来のレジスタ アーキテクチャとハードウェア I/O 機能を備えた 24 ビット ミニコンピュータで、数千のリモート ターミナルを処理できます。DCP と B6500 は、メモリ内のメッセージ (今日の用語で言えばパケット) によって通信し、MCS はそれらのメッセージの B6500 側での処理を行いました。初期の DCP には、アセンブラ (Dacoma)、B6500 ALGOL で記述された DCPProgen というアプリケーション プログラムがありました。後に、NDL (ネットワーク定義言語) コンパイラによって DCP コードと NDF (ネットワーク定義ファイル) が生成されました。最終的には、さらに更新が行われ、モデル 4 および 5 の DCP と組み合わせて使用​​される NDLII 言語とコンパイラが開発されました。DCP 命令の種類ごとに 1 つの ALGOL 関数があり、その関数を呼び出すと、対応する DCP 命令ビットが出力に出力されます。 DCP プログラムは、アセンブリ言語ステートメントごとに 1 つずつ、これらの関数の呼び出しの長いリストのみで構成される ALGOL プログラムでした。基本的に、ALGOL はマクロ アセンブラのマクロ パスのように動作しました。最初のパスは ALGOL コンパイラでした。2 番目のパスは結果のプログラム (B6500 上) を実行し、DCP のバイナリを出力しました。

1980 年代初頭から、DCP テクノロジは、メインフレーム システムに LAN ベースの接続を提供する ICP (Integrated Communications Processor) に置き換えられました。リモート デバイスおよびリモート サーバー/メインフレームは、CP2000 と呼ばれる独立型デバイスを介してネットワークに接続されました。CP2000 は、BNAV2 (Burroughs Network Architecture Version 2) ネットワーキング テクノロジを使用してノードが接続された分散ネットワークでネットワーク ノード サポートを提供するように設計されました。BNAV2 は、IBM SNA 製品と同等の機能を持つ Burroughs 製品であり、PUT2 および PUT5 トランスポート モードの両方で IBM 環境との相互運用をサポートしていました。外部データ通信ハードウェアの変更によって、既存の MCS (Message Control System (後述)) ソフトウェアを変更する必要はありませんでした。

入力時には、メッセージは DCP から内部バスを介して関連する MCP Datacom Control (DCC) DCP プロセス スタックに渡されます。システムで構成されている各 DCP に対して 1 つの DCC プロセスが開始されます。次に、DCP プロセス スタックは、特定のソース デバイスからのトラフィックを処理するために識別された MCS に配信するために着信メッセージがキューに入れられ、宛先デバイスに配信するために DCP に応答が返されるようにします。処理の観点からは、5 種類の DCP のいずれであっても、ICP または ICP/CP2000 の組み合わせであっても、異なるタイプのゲートウェイ ハードウェアを処理するために MCS ソフトウェアを変更する必要はありませんでした。

メッセージ配信サービスであることに加え、MCS はオペレーティング システム コード (NEWP) とユーザー プログラム (ALGOL、または COBOL、FORTRAN、後期の JAVA などの他のアプリケーション言語) の間の中間レベルのセキュリティです。MCS はミドルウェアプログラムとみなされ、DCALGOL (Data Communications ALGOL) で記述されます。前述のように、MCS は Datacom Control Stack (DCC) によって管理されているキューからメッセージを受信し、これらのメッセージを適切なアプリケーション/機能に転送して処理します。オリジナルの MCS の 1 つは、オンライン プログラム開発環境として開発された CANDE (Command AND Edit) です。ニュージーランドのオタゴ大学は、IBM が IBM 360 シリーズ システムで実行される CALL/360 と呼ばれるリモート タイム シェアリング/プログラム開発サービスを提供していたのと同時期に、CANDE と同等の SCREAM/6700 と呼ばれる簡易プログラム開発環境を開発しました。COMS という別の MCS は 1984 年頃に導入され、高性能トランザクション処理制御システムとして開発されました。 GEMCOS (GEneralized Message COntrol System) を含む先行のトランザクション処理環境があり、オーストラリアの Burroughs の子会社が TPMCS (Transaction Processing MCS) と呼ばれる MCS を開発しました。トランザクション処理 MCS は、オンラインの運用環境へのアプリケーション データの配信と、リモート ユーザー/デバイス/システムへの応答の返信をサポートしていました。

MCS は注目すべきソフトウェアです。MCS はユーザー セッションを制御し、ユーザー状態を追跡します。単一の MCS スタックを多くのユーザーが共有できるため、ユーザーごとのプロセスを実行する必要はありません。負荷分散も MCS レベルで実現できます。たとえば、スタックごとに 30 人のユーザーを処理するとします。この場合、ユーザーが 31 ～ 60 人であればスタックは 2 つ、61 ～ 90 人であればスタックは 3 つになります。これにより、ユーザーがシステムに接続するたびに別のユーザー プロセスを起動して新しいスタックを作成する必要がないため、B5000 マシンはサーバーで大きなパフォーマンス上の利点を得られます。したがって、MCS を使用すると、ユーザーに (状態が必要かどうかに関係なく) 効率的にサービスを提供できます。MCS は、大規模なトランザクション処理のバックボーンも提供します。

1988 年頃、TCP/IP の実装は主に米国政府顧客向けに開発され、CP2000 分散通信プロセッサをプロトコル ホストとして使用しました。2 ～ 3 年後、TCP/IP 実装はホスト/サーバー ベースに書き直され、パフォーマンスと機能が大幅に向上しました。ほぼ同じ時期に、OSI プロトコル スタックの実装が主に CP2000 上で行われましたが、大規模なサポート インフラストラクチャはメイン システムに実装されました。X.400 メール ホスティングや X.500 ディレクトリ サービスなど、OSI 標準で定義されたすべてのアプリケーションが実装されました。

ALGOL の別のバリエーションは、DMALGOL (データ管理 ALGOL) です。DMALGOL は、DASDL (データ アクセスおよび構造定義言語) コンパイラによって作成されたデータベース記述ファイルから DMSII データベース ソフトウェアをコンパイルするために拡張された ALGOL です。データベース設計者と管理者は、データベース記述をコンパイルして、指定されたテーブルとインデックスに合わせて調整された DMALGOL コードを生成します。管理者が自分で DMALGOL を書く必要はありません。通常のユーザー レベル プログラムは、データベース命令とトランザクション処理ディレクティブで拡張された、主に ALGOL と COBOL のアプリケーション言語で記述されたコードを使用してデータベースにアクセスします。DMALGOL の最も注目すべき機能は、テーブルとインデックスを処理するためのコードを生成する前処理メカニズムです。

DMALGOL プリプロセスには変数とループが含まれており、コンパイル時の変数に基づいて名前を生成できます。これにより、ループのないプリプロセス機能で実行できる以上のカスタマイズが可能になります。

DMALGOL は、DMSIIデータベース用にカスタマイズされたアクセス ルーチンを提供するために使用されます。DASDL (Data Access and Structure Definition Language) を使用してデータベースが定義された後、スキーマはプリプロセッサによってカスタマイズされた DMALGOL アクセス ルーチンに変換され、コンパイルされます。つまり、他の DBMS 実装とは異なり、実行時にデータベース固有の if/then/else コードが不要になることがよくあります。1970 年代には、この「カスタマイズ」は、コード フットプリントと実行時間を削減するために非常に広範に使用されていました。後年は、メモリと速度の低レベルの微調整がそれほど重要ではなくなったことと、プリプロセスを排除することでコーディングが簡素化され、より重要な最適化が可能になったことなどから、あまり使用されなくなりました。

アプリケーション プログラムからデータベースへのアクセスをサポートする ALGOL のアプリケーション バージョンは BDMSALGOL と呼ばれ、データベース アクセスとレコード操作用の「FIND」、「LOCK」、「STORE」、「GET」、「PUT」などの動詞が含まれています。さらに、複数のプロセスが同じ構造にアクセスして更新する場合のデッドロック状況を解決するために、「BEGINTRANSACTION」および「ENDTRANSACTION」動詞も実装されました。

Burroughs の Roy Guck はDMSIIの主要な開発者の 1 人でした。

後年、コンパイラ コードのサイズがそれほど問題ではなくなったため、ほとんどのプリプロセス構造が ALGOL のユーザー レベルで利用できるようになりました。安全でない構造とデータベース記述ファイルの直接処理のみが DMALGOL に制限されたままになっています。

初期のシステムや言語の多くでは、ルーチンをあまり小さくしすぎないようにとプログラマーによく言われていました。スタックを維持するために多数の操作を実行する必要があったため、プロシージャの呼び出しと戻りはコストがかかりました。B5000 はスタック マシンとして設計されました。配列 (文字列とオブジェクトを含む) を除くすべてのプログラム データはスタック上に保持されました。つまり、スタック操作は効率化のために最適化されていました。スタック指向のマシンであるため、プログラマーがアドレス指定できるレジスタはありません。

B5000 および B6500 ラインでは、 マルチタスクも非常に効率的です。プロセス切り替えを実行するための特定の命令があります。

B5000、B5500、B5700

イニシエートP1（IP1）とイニシエートP2（IP2）^{[5] ：6–30}

B6500、B7500および後継機

MVST（スタック移動）^{[7] ：8–19  [23]}

各スタックとそれに関連付けられた^{[NB 5]}プログラム参照テーブル (PRT) はプロセス (タスクまたはスレッド) を表し、タスクはリソース要求を待機してブロックされることがあります (プリエンプティブ マルチタスクによってタスクが割り込まれた場合にプロセッサが実行されるのを待機することも含まれます)。ユーザー プログラムは IP1 ^{[NB 5]} IP2 ^{[NB 5]}または MVST ^{[NB 6]}を発行できず、これが実行されるオペレーティング システムの場所は 1 か所のみです。

したがって、プロセス スイッチは次のように進行します。プロセスが、すぐには利用できないリソースを要求します。たとえば、現在メモリにないブロックからファイルのレコードを読み取る場合や、システム タイマーが割り込みをトリガーした場合などです。オペレーティング システム コードが入力され、ユーザー スタックの先頭で実行されます。これにより、ユーザー プロセス タイマーがオフになります。現在のプロセスは、要求されているリソースの適切なキューに配置されるか、プリエンプティブ コンテキスト スイッチの場合は、プロセッサを待機する準備完了キューに配置されます。オペレーティング システムは、準備完了キューの最初のプロセスを決定し、move_stack 命令を呼び出します。これにより、準備完了キューの先頭にあるプロセスがアクティブになります。

スタックのパフォーマンスは、レジスタベースのアーキテクチャに比べて遅いと考えられていました。たとえば、そのようなアーキテクチャは System /360で検討されたが却下されました。^[24]システム速度を上げる方法の 1 つは、データをプロセッサにできるだけ近づけることです。B5000 スタックでは、スタックの上位 2 つの位置を 2 つのレジスタ A と B に割り当てることでこれを実現しました。ほとんどの操作は、スタックの上位 2 つの位置で実行されます。B5000 より高速なマシンでは、スタックのより多くの部分がプロセッサ近くのレジスタまたはキャッシュに保持される場合があります。

したがって、B5000 システムの現在の後継機の設計者は、最新の技術で最適化することができ、プログラマーはコードをより高速に実行するために調整する必要がありません。再コンパイルする必要さえないので、ソフトウェアへの投資が保護されます。一部のプログラムは、プロセッサを何度もアップグレードしても何年も実行できることが知られています。このような高速化は、レジスタベースのマシンでは制限されます。^[要出典]

RISC 設計者が主張した速度に関するもう 1 つのポイントは、すべてが 1 つのチップに収まるとプロセッサ速度が大幅に速くなるという点です。これは、B5000 などのより複雑なアーキテクチャでは 1 つのチップに収まるにはトランジスタが多すぎた 1970 年代には妥当なポイントでした。しかし、今日ではそうではなく、B5000 の後継マシンはすべて 1 つのチップに収まり、キャッシュや命令パイプラインなどのパフォーマンス サポート技術も搭載されています。

実際、B5000 の後継製品である A シリーズ ラインには、1980 年代後半の最初のシングル チップ メインフレームである Micro-A が含まれていました。この「メインフレーム」チップ (シングル チップ A シリーズ メインフレーム プロセッサの略称 SCAMP) は、Intel ベースのプラグイン PC ボード上に搭載されていました。

これはプログラムがスタック構造にどのようにマップされるかの例です

始める
   — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
   — これは語彙レベル 2 です (レベル 0 はオペレーティング システム用に予約されており、レベル 1 はコード セグメント用に予約されています)。
   — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
   
   — レベル 2 では、プログラムのグローバル変数を配置します。
   
   整数 i、j、k ;
   実数 f、g ;
   配列 a [0:9];
   
   手順 p (実数 p1、p2 );
      値 p1 ; — p1 は値渡しされ、 p2 は暗黙的に参照渡しされます
      。
         — — — — — — — — — — — — — — — — — —
         — このブロックは語彙レベル3です
         — — — — — — — — — — — — — — — — — —
         real  r1 , r2 ; 

         r2  := p1 * 5 ;
          p2  := r2 ; — これはg をr2
         の値に設定しますp1  := r2 ; — これはp1 をr2に設定しますが、fには設定しません —これはp1のf
         の元の値を上書きするので、
         — コーディングミス。ALGOLの後継者の中には、
         — 値パラメータは読み取り専用ですが、ほとんどはそうではありません。
         
          r2 > 10 の場合、
            開始
               — — — — — — — — — — — — — — — — — — — — — — — — — — — —
               — ここで宣言された変数は、この語彙レベルを4にします
               — — — — — — — — — — — — — — — — — — — — — — — — — — — —
               整数 n ;

               — 変数の宣言はブロックとなり、いくつかの
               — スタック構築コード。通常、ここで変数を宣言することはなく、
               — この場合、これはブロックではなく複合文になります。
               
               ... <== サンプル スタックはここのどこかで実行されています。
            終わり;
      終わり;
      
   .....
   
   p ( f , g );
終了。

各スタック フレームは、現在の実行環境の語彙レベルに対応します。ご覧のとおり、語彙レベルはプログラムの静的テキスト ネストであり、動的呼び出しネストではありません。シングル パス コンパイラ用に設計された言語である ALGOL の可視性ルールでは、現在の位置より前に宣言された変数のみがコードのその部分で可視であるため、前方宣言が必要です。囲んでいるブロックで宣言されたすべての変数が可視です。別のケースでは、同じ名前の変数が内部ブロックで宣言され、これにより外部の変数が効果的に隠され、アクセスできなくなります。

語彙のネストは静的であり、再帰などによる実行のネストとは無関係です。そのため、5 レベルを超える深さのネストされたプロシージャを見つけることは非常にまれであり、そのようなプログラムは構造化されていないと言えます。B5000 マシンでは、最大 32 レベルのネストが可能です。生成方法がプロシージャ内にプロシージャを頻繁にネストする場合、出力として Algol ソース (特別な問題を解決するように調整) を生成する一部のシステムでは、これが問題になる可能性があります。

プロシージャは、通常、呼び出し、処理、実行の 4 つの方法で呼び出すことができます。

通常の呼び出しでは、呼び出されたプロシージャが返されるまで呼び出しルーチンを中断することにより、任意の言語がルーチンを呼び出す通常の方法でプロシージャを呼び出します。

呼び出しメカニズムは、プロシージャをコルーチンとして呼び出します。コルーチンは、開始プロセスと同じ語彙レベルで独自のスタック内で動作する同期エンティティとして確立されたパートナー タスクです。制御は、 CONTINUE命令によって開始プロセスとコルーチンの間で明示的に渡されます。

プロセスメカニズムは、処理されるプロシージャの語彙レベルから始まる別のスタックがセットアップされた非同期タスクとしてプロシージャを呼び出します。非同期タスクであるため、コルーチンとは異なり、タスク間で制御が渡される正確なタイミングを制御することはできません。処理されるプロシージャは、引き続き囲む環境にアクセスでき、これは非常に効率的な IPC (プロセス間通信) メカニズムです。2 つ以上のタスクが共通の変数にアクセスできるようになるため、競合状態を防ぐためにタスクを同期する必要があります。競合状態は EVENT データ型によって処理されます。この場合、プロセスは、別の連携プロセスによって発生するまで、1 つ以上のイベントで待機できます。EVENT では、PROCURE 関数と LIBERATE 関数による相互排他同期も可能になります。何らかの理由で子タスクが終了した場合、呼び出し元のタスクは続行できますが、親プロセスが終了した場合は、すべての子プロセスが自動的に終了します。複数のプロセッサを備えたマシンでは、プロセスが同時に実行される場合があります。この EVENT メカニズムは、マルチタスクに加えてマルチプロセスの基本イネーブラーです。

最後の呼び出しタイプはrunです。これは、元のプロセスが終了した後も続行できる独立したタスクとしてプロシージャを実行します。このため、子プロセスは親の環境内の変数にアクセスできず、呼び出されたプロシージャに渡されるすべてのパラメータは値渡しでなければなりません。

そのため、Burroughs Extended ALGOL には、 Adaなどの後の言語のマルチプロセス機能と同期機能がいくつか備わっていました。ハードウェアに組み込まれた非同期プロセスのサポートを活用しました。

最後の可能性は、NEWP でプロシージャをINLINE として宣言することです。つまり、コンパイラがプロシージャへの参照を見つけると、プロシージャのコードがインラインで生成され、プロシージャ呼び出しのオーバーヘッドが節約されます。これは、小さなコードに対して行うのが最適です。インライン関数は、マクロで発生する可能性のあるパラメータの問題がないことを除いて、 C #defineなどのパラメータ化されたマクロに似ています。

サンプル プログラムでは通常の呼び出しのみが使用されるため、すべての情報は単一のスタック上にあります。非同期呼び出しの場合、プロセスはデータを共有しますが非同期で実行されるように、非同期プロセスごとに個別のスタックが開始されます。

スタック ハードウェアの最適化は、D (または「ディスプレイ」) レジスタの提供です。これらは、呼び出された各スタック フレームの開始を指すレジスタです。これらのレジスタは、プロシージャの開始時と終了時に自動的に更新され、MCP 以外のソフトウェアからはアクセスできません。32 個の D レジスタがあり、これによって操作が 32 レベルの語彙ネストに制限されます。

語彙レベル 5 (D[5]) から語彙レベル 2 (D[2]) のグローバル変数にアクセスする方法を考えてみましょう。変数が語彙レベル 2 のベースから 6 ワード離れているとします。したがって、これはアドレス カップル (2、6) で表されます。D レジスタがない場合は、D[5] フレームのベースにある制御ワードを調べる必要があります。この制御ワードは、D[4] 環境を含むフレームを指します。次に、この環境のベースにある制御ワードを調べて D[3] 環境を見つけ、必要な語彙レベルまですべてのリンクをたどるまでこの方法を続けます。これは、このポイントに到達するために呼び出されたプロシージャをたどる戻りパスと同じパスではありません。(アーキテクチャは、データ スタックと呼び出しスタックの両方を同じ構造に保持しますが、制御ワードを使用してそれらを区別します。)

ご覧のとおり、これは変数にアクセスするだけなら非常に非効率的です。D レジスタでは、D[2] レジスタはレキシカル レベル 2 環境のベースを指し、変数のアドレスを生成するために必要なことは、スタック フレーム ベースからのオフセットを D レジスタのフレーム ベース アドレスに追加することだけです。(効率的なリンク リスト検索演算子 LLLU があり、上記の方法でスタックを検索できますが、それでも D レジスタ アプローチの方が高速です。) D レジスタでは、外部環境およびグローバル環境のエンティティへのアクセスは、ローカル変数アクセスと同じくらい効率的です。

D タグデータ - アドレスペア、コメント
登録する

| 0 | n           | (4, 1) 整数n（手続きではなくブロックの入り口で宣言される）
|-----------------------|
| D[4]==>3 | MSCW        | (4, 0) D[3]へのリンクを含むマークスタック制御ワード。
|==========================|
| 0 | r2          | (3, 5) 実数r2
|-----------------------|
| 0 | r1          | (3, 4) 実数r1
|-----------------------|
| 1 | p2 | (3, 3) (2,6)のg         へのSIRW参照
|-----------------------|
| 0 | p1 | (3, 2) fの値からの         パラメータp1 
|-----------------------|
| 3 | RCW         | (3, 1) 戻り制御ワード
|-----------------------|
| D[3]==>3 | MSCW        | (3, 0) D[2]へのリンクを含むマークスタック制御ワード。
|==========================|
| 1 | a           | (2, 7) 配列a   ======>[10ワードのメモリブロック]
|-----------------------|
| 0 | g           | (2, 6) 実数g 
|-----------------------|
| 0 | f           | (2, 5) 実数f 
|-----------------------|
| 0 | k           | (2, 4) 整数k 
|-----------------------|
| 0 | j           | (2, 3) 整数j 
|-----------------------|
| 0 | i           | (2, 2) 整数i
|-----------------------|
| 3 | RCW         | (2, 1) 戻り制御ワード
|-----------------------|
| D[2]==>3 | MSCW        | (2, 0) 前のスタックフレームへのリンクを含むマークスタック制御ワード。
|=========================| — スタックの下部

手順 p をコルーチンまたはプロセス命令として呼び出した場合、D[3] 環境は別の D[3] ベースのスタックになります。つまり、非同期プロセスは、ALGOL プログラム コードで暗示されているように、引き続き D[2] 環境にアクセスできます。これをさらに 1 歩進めると、まったく異なるプログラムが別のプログラムのコードを呼び出し、独自のプロセス スタックの上に別のプロセスの D[2] 環境を指す D[3] スタック フレームを作成できます。コードの実行環境からのアドレス空間全体が一瞬で変更され、独自のプロセス スタック上の D[2] 環境は直接アドレス指定できなくなり、代わりに別のプロセス スタック内の D[2] 環境が直接アドレス指定できるようになります。これがライブラリ呼び出しの実装方法です。このようなクロス スタック呼び出しでは、呼び出しコードと呼び出し先コードが異なるソース言語で記述されたプログラムに由来し、異なるコンパイラでコンパイルされている可能性もあります。

D[1] および D[0] 環境は、現在のプロセスのスタックには存在しません。D[1] 環境は、同じコードを実行するすべてのプロセスによって共有されるコード セグメント ディクショナリです。D[0] 環境は、オペレーティング システムによってエクスポートされたエンティティを表します。

スタック フレームは、実際にはプロセス スタック内に存在する必要さえありません。この機能は、ファイル I/O の最適化のために初期に使用されており、FIB (ファイル情報ブロック) は、I/O 操作中に D[1] のディスプレイ レジスタにリンクされていました。90 年代初頭、この機能は言語機能として STRUCTURE BLOCKS として実装され、ライブラリ テクノロジと組み合わせて CONNECTION BLOCKS として実装されました。データ構造をディスプレイ レジスタ アドレス スコープにリンクする機能により、オブジェクト指向が実装されました。したがって、B6500 は、この用語が使用されるずっと前から、実際にオブジェクト指向の形式を使用していました。

他のシステムでは、コンパイラが同様の方法でシンボル テーブルを作成する場合もありますが、最終的にはストレージ要件が照合され、マシン コードは 16 ビット、32 ビット、または 64 ビットのフラット メモリ アドレスを使用するように記述されます。これらのアドレスには何でも含まれる可能性があるため、間違ったアドレスに書き込むと何かが損傷する可能性があります。代わりに、2 部構成のアドレス スキームがハードウェアによって実装されました。各レキシカル レベルでは、変数はレベルのスタックのベースから上方に変位して配置され、通常は 1 ワードを占めます。倍精度または複素数の変数は 2 ワードを占めます。配列はこの領域に格納されず、配列の 1 ワード記述子のみが格納されます。したがって、各レキシカル レベルでの総ストレージ要件はそれほど大きくなく、数十、数百、極端な場合は数千で、32 ビット以上を必要とする数ではありません。実際、これはスタックにオペランドをロードする VALC 命令 (値呼び出し) の形式で反映されています。このオペコードは 2 ビット長で、バイトの残りのビットは次のバイトと連結されて 14 ビットのアドレス指定フィールドになります。実行されるコードは、たとえば 6 などの何らかの語彙レベルになります。つまり、語彙レベル 0 から 6 のみが有効であり、必要な語彙レベルを指定するのに必要なのは 3 ビットだけです。VALC 操作のアドレス部分は、この目的のために 3 ビットだけを予約し、残りはそのレベルおよびそれ以下のレベルのエンティティを参照するために使用できます。深くネストされたプロシージャ (つまり高い語彙レベル) では、エンティティを識別するために使用できるビットが少なくなります。レベル 16 以上では、レベル 0 から 31 の選択を指定するのに 5 ビット必要になるため、どの語彙レベルでも最初の 512 個のエンティティのみを識別するために 9 ビットが残ります。これは、32 ビットのアドレス指定空間でエンティティをリテラル メモリ アドレスでアドレス指定するよりもはるかにコンパクトです。さらに、VALC オペコードのみがデータをロードしました。ADD、MULT などのオペコードはアドレス指定を行わず、スタックの最上位要素のみを処理します。

さらに重要なのは、この方法により、フラット アドレッシングを採用しているシステムで起こり得る多くのエラーが、マシン コード レベルでも単純に説明できないため、発生しなくなるということです。タスクは、アドレスを開発する方法がないため、別のタスクが使用しているメモリを破損することはできません。指定された D レジスタからのオフセットは、スタック フレーム境界に対してハードウェアによってチェックされ、不正な値はトラップされます。同様に、タスク内では、配列記述子に配列の境界に関する情報が含まれているため、インデックス操作はすべてハードウェアによってチェックされます。言い換えると、各配列は独自のアドレス空間を形成します。いずれにせよ、すべてのメモリ ワードにタグを付けることで、2 段階の保護が提供されます。つまり、値の誤った割り当ては、データを保持する場所にのみ割り当てられ、ポインタや配列記述子などを保持する場所には割り当てられず、マシン コードを保持する場所には割り当てられません。

配列はメモリ内で他の変数と連続して格納されず、それぞれに独自のアドレス空間が与えられ、記述子を介して配置されます。アクセス メカニズムは、スタック上でインデックス変数 (したがって、14 ビットだけではなく、完全な整数範囲の可能性を持つ) を計算し、ハードウェアによって境界チェックが提供され、それを配列のアドレス空間へのオフセットとして使用します。デフォルトでは、配列の長さが 1,024 ワードを超えると、配列はセグメント化され、インデックスはセグメント インデックスとインデックス付きセグメントへのオフセットに変換されます。ただし、宣言で配列を LONG として指定することで、セグメント化を防ぐオプションがありました。ALGOL の場合、多次元配列では、このようなアドレス指定が複数レベルで使用されます。A[i,j] への参照の場合、最初のインデックスは記述子の配列になり、A の各行に 1 つの記述子があり、その行は 1 次元配列の場合と同様に j でインデックス付けされ、高次元でも同様になります。すべての配列のインデックスの既知の境界をハードウェアでチェックすることで、誤ったインデックス作成を防ぐことができます。

しかし、FORTRAN では、すべての多次元配列が同じサイズの 1 次元配列と同等であるとみなされ、多次元配列の場合、要素 A[i,j,k] がその単一のシーケンス内で見つかるオフセットを計算するために単純な整数演算が使用されます。十分な大きさであればセグメント化される可能性のある 1 次元の同等の配列は、ALGOL の 1 次元配列と同じ方法でアクセスされます。この配列の外部へのアクセスは防止されますが、1 つのインデックスの誤った値と別のインデックスの適切に誤った値を組み合わせても、単一のシーケンス配列の境界違反にはならない可能性があります。つまり、インデックスは個別にチェックされません。

配列のストレージは、各辺が他の項目のストレージによって制限されていないため、システムで配列を「サイズ変更」するのは簡単です。ただし、コンパイラーはすべての参照が同じ次元数を持つことを要求したため、次元数の変更は不可能でした。ALGOL の場合、これにより、通常の固定長方形 (またはより高次元) 配列ではなく、「不規則な」配列の開発が可能になりました。したがって、2 次元では、不規則な配列には異なるサイズの行が含まれます。たとえば、ほとんどがゼロの値である大きな配列 A[100,100] がある場合、SA[100,0] として宣言されたスパース配列表現では、各行のサイズを変更して、その行に沿って A の非ゼロ値のみを保持するのに十分な要素を持つようにすることができます。

1024 ワードを超える配列は一般にセグメント化されますが、それより小さい配列はセグメント化されません。そのため、実メモリが不足しているシステムでは、スクラッチパッド配列のコレクションの宣言サイズを 1,000 から 1,050 に増やすと、使用中の小さい個々のセグメントのみがメモリ内で必要になるため、プログラムの実行時の「スラッシング」が大幅に減少する可能性があります。配列セグメントの実際のストレージは、そのセグメント内の要素がアクセスされた場合にのみ実行時に割り当てられ、作成されたセグメントのすべての要素はゼロに初期化されます。そのため、開始時に配列をゼロに初期化しないことが推奨されましたが、これは通常、賢明ではない省略です。

配列の等価化もサポートされています。ARRAY 宣言は、任意のビット パターンを格納するために使用できる 48 ビット データ ワードの割り当てを要求しましたが、一般的な運用方法では、割り当てられた各ワードは REAL オペランドと見なされます。次の宣言:

  配列A [0:99]

メモリ内に 100 ワードの REAL 型データ空間を割り当てるように要求しました。プログラマーは、次の等価宣言によって、メモリが文字指向データとして参照されることも指定できます。

  EBCDIC配列 EA [0] = A [*];

または、等価宣言を介して 16 進データとして:

  16進配列 HA [0] = A [*];

または、等価宣言を介して ASCII データとして:

  ASCII配列AA [0] = A[*];

等価化せずにデータ型固有の配列を要求する機能もサポートされています。例:

  EBCDIC配列 MY_EA [0:99]

システムに 100 文字の配列を割り当てるように要求しました。アーキテクチャがワード ベースであることを考えると、割り当てられる実際のスペースは、要求された文字数を次のワード境界全体に切り上げた数になります。

コンパイル時に生成されたデータ記述子は、配列が意図されているデータ型の使用法を示していました。配列の等価宣言が行われた場合、特定の使用法タイプを示すコピー記述子が生成されましたが、元の記述子、つまり MOM 記述子を指していました。したがって、メモリ内の正しい場所のインデックス付けは常に保証されていました。

BOOLEAN 配列もサポートされており、ビット ベクターとして使用できます。INTEGER 配列も要求される場合があります。

直前の説明では、ARRAY 宣言を記述するために ALGOL 構文実装を使用していますが、同じ機能が COBOL および FORTRAN でもサポートされています。

スタック構造の優れた点の 1 つは、プログラムが失敗した場合にスタック ダンプが取得され、実行中のプログラムの状態がどのようなものであったかをプログラマーが正確に把握することが非常に簡単になることです。これを他のシステムのコア ダンプや交換パッケージと比較してください。

スタック構造に関するもう 1 つの点は、プログラムが暗黙的に再帰的であることです。FORTRAN は再帰をサポートするとは想定されておらず、ALGOL の実装方法を理解する上での障害の 1 つは、再帰の実装方法だったかもしれません。B5000 では、これは問題ではありませんでした。実際、プログラムの再帰を阻止する方法という逆の問題がありました。結局、彼らは気にしませんでした。Burroughs FORTRAN コンパイラは、他のすべての FORTRAN コンパイラと同様に再帰呼び出しを許可しましたが、他の多くのコンピュータとは異なり、スタックベースのシステムでは、そのような呼び出しからの戻りも成功しました。これは、数式の正式な操作のためのシステムで、中心となるサブルーチンが互いに繰り返し呼び出しても決して戻らない場合など、奇妙な効果をもたらす可能性があり、大規模なジョブがスタック オーバーフローによって終了しました。

そのため、Burroughs FORTRAN は、当時の他の FORTRAN 実装よりも優れたエラー チェック機能を備えていました。^[要出典]たとえば、サブルーチンや関数については、ALGOL スタイルのコンパイラーでは標準的であるように、正しい数のパラメーターで呼び出されているかどうかがチェックされました。他のコンピューターでは、このような不一致がクラッシュの一般的な原因でした。配列境界チェックについても同様で、他のシステムで何年も使用されてきたプログラムが、Burroughs システムで実行すると、恥ずかしいほど頻繁に失敗しました。実際、Burroughs は、オブジェクト指向のSimula (ALGOL のスーパーセット) を含む優れたコンパイラーと言語の実装で知られるようになり、APLの設計者であるIverson は、 Burroughs の APL 実装がこれまで見た中で最高のものであると宣言しました。^{[引用が必要]} LISPの言語設計者であるJohn McCarthy は、LISP は変更可能なコード^{[引用が必要]}に基づいているため、B5000 ^{[引用が必要]}の変更不可能なコードが気に入らなかったため、これに反対しましたが、ほとんどの LISP 実装はいずれにしても解釈環境で実行されます。

複数のプロセスに必要なストレージは、必要に応じてシステムのメモリ プールから取得されました。競合システムのように、タスクを実行する メモリ パーティションを事前に構成するために、Burroughs システムで SYSGEN を実行する必要はありませんでした。

B5000 の最も特徴的な点は、上で説明したようにスタック マシンであることです。ただし、このアーキテクチャのその他の 2 つの非常に重要な特徴は、タグ ベースと記述子ベースであることです。

^{オリジナルの B5000 では、各制御ワードまたは数値ワード[NB 7]}にフラグ ビットが設定され、そのワードが制御ワードか数値ワードかを識別するために使用されていました。これは、プログラムがスタック上の制御ワードを破損するのを防ぐためのセキュリティ メカニズムの一部でした。

その後、B6500 が設計されたとき、1 ビットの制御ワード/数値の区別が強力なアイデアであることが認識され、これは 48 ビット ワードの外側の 3 ビットに拡張され、タグになりました。データ ビットはビット 0 ～ 47 で、タグはビット 48 ～ 50 にあります。ビット 48 は読み取り専用ビットであるため、奇数のタグはユーザー レベルのプログラムでは書き込めない制御ワードを示します。コード ワードにはタグ 3 が割り当てられました。以下はタグとその機能の一覧です。

内部的には、一部のマシンには 60 ビットのワードがあり、余分なビットはハミング コードのエラー訂正フィールドなどのエンジニアリング目的で使用されていましたが、プログラマーがこれらを見ることはありませんでした。

これらのマシンの現在のバージョンである Unisys ClearPath では、タグがさらに 4 ビット タグに拡張されています。4 ビット タグを指定するマイクロコード レベルは、レベル ガンマと呼ばれていました。

偶数タグ付きワードは、ユーザー プログラムによってユーザー状態として変更できるユーザー データです。奇数タグ付きワードはハードウェアによって直接作成および使用され、プログラムの実行状態を表します。これらのワードは特定の命令またはハードウェアによって作成および使用されるため、これらのワードの正確な形式はハードウェア実装間で変わる可能性があり、システム ワード形式が変更された場合でも、同じコード ストリームで同じ結果が生成されるため、ユーザー プログラムを再コンパイルする必要はありません。

タグ 1 ワードは、スタック上のデータ アドレスを表します。通常の IRW は、現在のスタック上のデータにアドレス カップルを単に保存します。SIRW は、アドレスにスタック番号を含めることで、任意のスタック上のデータを参照します。特に、SIRW は、CALLおよびPROCESSステートメントに応答して生成されるスタックなどの個別のプロセス スタック間のアドレス指定に使用されます。

タグ 5 ワードは記述子であり、次のセクションで詳しく説明します。タグ 5 ワードは、スタック外のデータ アドレスを表します。

タグ 7 は、プロシージャのエントリ ポイントを記述するプログラム制御ワードです。ハードウェア演算子が PCW にヒットすると、プロシージャに入ります。ENTR 演算子は、明示的にプロシージャ (値を返さないルーチン) に入ります。関数 (値を返すルーチン) は、値呼び出し (VALC) などの演算子によって暗黙的に入ります。グローバル ルーチンは、D[1] 環境のコード セグメント ディクショナリに格納されている PCW を指す SIRW として D[2] 環境に格納されます。D[1] 環境は、このコードを共有するすべてのプロセスによって参照できるため、現在のスタックには格納されません。したがって、コードは再入可能で共有可能です。

タグ 3 は、スタック上に出現しないコード ワード自体を表します。タグ 3 は、スタック制御ワード MSCW、RCW、TOSCW にも使用されます。

左の図は、Burroughs Large System アーキテクチャが基本的にオブジェクト指向プログラミングのためのハードウェア アーキテクチャであったことを示しています。これは、従来のアーキテクチャにはまだ存在しないものです。

Burroughs の大規模システムには、3 つの異なる命令セットがあります。3 つとも、単語に均等に収まる 短い音節に基づいています。

B5000、B5500、B5700 のプログラムは、12 ビットの音節 (1ワードあたり 4 ビット) で構成されています。アーキテクチャには、ワード モードと文字モードの 2 つのモードがあり、それぞれに異なる音節のレパートリーがあります。プロセッサは制御状態または通常状態のいずれかになりますが、特定の音節は制御状態でのみ許可されます。アーキテクチャでは、レジスタまたはストレージを直接アドレス指定することはできません。すべての参照は、1024 ワードのプログラム参照テーブル、現在のコード セグメント、スタック内のマークされた場所、またはスタックの上位 2 つの場所を保持する A および B レジスタを介して行われます。Burroughs は、音節内のビットを 0 (上位ビット) から 11 (下位ビット) まで番号付けします。

プログラムは8 ビットのシラブルで構成され、名前呼び出し、値呼び出し、または 1 から 12 のシラブルの長さの演算子を形成します。演算子は200 未満で、すべて 8 ビットのシラブルに収まります。これらの演算子の多くは、タグによって指定された操作対象のデータの種類に応じて多態的です。強力な文字列スキャン、転送、および編集演算子を無視すると、基本セットは約 120 の演算子のみです。MVST や HALT など、オペレーティング システム用に予約されている演算子を除くと、ユーザー レベルのプログラムで一般的に使用される演算子のセットは 100 未満です。名前呼び出しシラブルと値呼び出しシラブルにはアドレス カップルが含まれます。演算子シラブルは、アドレスを使用しないか、スタック上の制御ワードと記述子を使用します。

B5000 ラインは、2 つのプロセッサをマスターとスレーブとして高速バスに接続する先駆者でもありました。B6000、B7000、B8000 ラインでは、プロセッサは対称的でした。B7000 ラインは、少なくとも 1 つが I/O モジュールであれば、最大 8 つのプロセッサを持つことができました。RDLK (ReaD with LocK)は、プロセッサ間の同期をとる非常に低レベルの方法です。RDLKは1 サイクルで動作します。ユーザー プログラムで一般的に使用される高レベルのメカニズムは、EVENTデータ型です。EVENTデータ型には、ある程度のシステム オーバーヘッドがありました。このオーバーヘッドを回避するには、Dahm ロック (Burroughs のソフトウェアの第一人者である Dave Dahm にちなんで名付けられました) と呼ばれる特別なロック手法を使用できます。Dahm ロックは、コード レベルで RDLK演算子を生成するREADLOCK ALGOL 言語ステートメントを使用しました。

注目すべきオペレーターは次のとおりです。

HEYU — 別のプロセッサに割り込みを送信します
。RDLK — 低レベル セマフォ演算子: A レジスタに A レジスタで指定されたメモリ位置をロードし、1 つの割り込み不可能なサイクルでそのメモリ位置に B レジスタの値を配置します。Algol コンパイラは、明示的な一時値なしで 1 ワード データに対して「スワップ」操作を可能にする特別な関数を介してこの演算子を呼び出すコードを生成しました。WHOI x:=RDLK(x,y);
—プロセッサ識別
IDLE — 割り込みを受信するまでアイドル状態

まれに、2 つのプロセッサが同時に「HEYU」コマンドを送信し、「デッドリー エンブレム」と呼ばれるロックアップが発生することがあります。

B5000 の直接的な影響は、B6500 の直接の後継機である現在の Unisys ClearPath メインフレーム シリーズに見ることができます。B6500 は B5000 の影響を受けており、40 年間の一貫した開発を経ても MCP オペレーティング システムを採用しています。このアーキテクチャは現在、emode (エミュレーション モード) と呼ばれています。これは、B6500 アーキテクチャが、ネイティブ命令セットとしてx86命令セットを実行するIntel Xeonプロセッサで構築されたマシンに実装され、それらのプロセッサで実行されるコードが B5000 命令セットをエミュレートしているためです。これらのマシンでは、nmode (ネイティブ モード) も予定されていましたが、これは廃止されました^{[引用が必要]}。そのため、B6500 の後継マシンが「emode マシン」と呼ばれることがよくあります。

B5000 マシンは高級言語のみでプログラムされており、アセンブラはありません。

B5000 スタック アーキテクチャは、プログラミング言語Forthの設計者で、MIT 在学中に B5500 に出会ったChuck Mooreにインスピレーションを与えました。Moore は著書『Forth - The Early Years』で、その影響について述べ、Forth の DUP、DROP、SWAP は対応する B5500 命令 (DUPL、DLET、EXCH) から派生したものであると述べています。

スタックベースのアーキテクチャとタグ付きメモリを備えた B5000 マシンは、ソ連のElbrusシリーズのメインフレームとスーパーコンピュータにも大きな影響を与えました。このシリーズの最初の 2 世代は、タグ付きメモリとスタックベースの CPU を備え、高級言語でのみプログラムされていました。El-76 と呼ばれる一種のアセンブリ言語が存在しましたが、これはALGOL 68の修正版であり、構造化プログラミングとファーストクラスのプロシージャをサポートしていました。ただし、シリーズの後の世代では、このアーキテクチャからEPICのようなVLIW CPUに切り替えられました。

HP 3000ビジネス システムの Hewlett-Packard 設計者はB5500を使用していて、そのハードウェアとソフトウェアに非常に感銘を受け、同様のソフトウェアを搭載した 16 ビット ミニコンピュータの構築を目指しました。HP の他のいくつかの部門でも、同様のミニコンピュータまたはマイクロプロセッサ スタック マシンを作成しました。Bob Barton の逆ポーランド記法(RPN) に関する研究も、9100A 以降のHP 計算機、特にHP-35およびそれ以降の計算機に採用されました。

1970 年代後半から 1980 年代前半にかけてTandem Computersが設計した NonStop システムも 16 ビット スタック マシンであり、初期の Tandem エンジニアの何人かが以前 HP にいたため、HP 3000 とのつながりを通じて間接的に B5000 の影響を受けていました。1990 年頃、これらのシステムは MIPS RISC アーキテクチャに移行しましたが、オブジェクト コード変換または直接エミュレーションによるスタック マシン バイナリの実行は引き続きサポートされていました。2000 年以降、これらのシステムはItaniumアーキテクチャに移行し、従来のスタック マシン バイナリの実行を継続しました。

ボブ・バートンもアラン・ケイに大きな影響を与えました。ケイも B5000 のデータ駆動型タグ付きアーキテクチャに感銘を受け、これがオブジェクト指向プログラミングとSmalltalkの開発における彼の考え方に影響を与えました。^[要出典]

B5000 アーキテクチャのもう 1 つの側面は、ハードウェア上で直接実行される安全なアーキテクチャであることです。この技術は、安全な環境を提供するという試みにおいて、今日の仮想マシンに受け継がれています^{[引用が必要]}。そのような製品の 1 つとして注目すべきものが、アプリケーションが実行される安全なサンドボックスを提供する Java JVM です。

emode 以前に存在したハードウェアとアーキテクチャの結合の価値は、 MCP が唯一の制御プログラムである限り、 x86ベースのマシンでも実質的に保持されますが、それらのマシンが提供するサポートは、B6500 命令セットがネイティブ命令セットであるマシンで提供されるサポートよりも劣っています。 x86 命令セットの 32 ビット実装に実際に先行した、あまり知られていない Intel プロセッサ アーキテクチャであるIntel iAPX 432 は、本質的にオブジェクト指向アーキテクチャであったため、同等の物理基盤を提供していたでしょう。

• バローズミディアムシステム
• バローズスモールシステムズ
• キャンデ
• ネットワーク定義言語(NDL)
• ワークフロー言語(WFL)
• 8進浮動小数点

• 拡張 ALGOL 入門(全 3 巻)、Donald J. Gregory。
• コンピュータアーキテクチャ：構造化アプローチ、 R. Doran、Academic Press (1979)。
• スタックコンピュータ：新しい波、フィリップJ.クープマン、入手可能：[1]
• B5500、B6500、B6700、B6800、B6900、B7700 のマニュアルは、bitsavers.org でご覧いただけます。

• バートン、ロバート S. (1961)。「デジタル コンピュータの機能設計への新しいアプローチ」 。Western Joint Computer Conference の議事録。ACM。doi : 10.1145/1460690.1460736。
• Waychoff, Richard; Turner, Lloyd; Rosin, Robert F.; Pearson, Ralph W.; Oliphint, G. Clark; MacKenzie, F. Brad; MacDonald, Ray W.; MacDonald, Duncan N.; Lonergan, William D.; Kreuder, Norman L.; King, Paul D.; Hootman, Joseph T.; Hauck, Erwin A.; Hale, John E.; Galler, Bernard A.; Ford, James; Eppert, Ray R.; Dent, Benjamin A.; Dahm, David M.; Creech, Bobby A.; Collins, George A.; Berce, Henri; Barton, Robert S. (1985 年 9 月 6 日)。「バロウズ B 5000 カンファレンス」。ミネソタ大学チャールズ バベッジ研究所。Burroughs 5000 コンピュータ シリーズについては、 AFIPSとBurroughs Corporationが主催した 1985 年の会議で、1957 年から 1960 年代にかけてその開発とマーケティングを担当した人々によって議論されました。
• Gray, George (1999年3月). 「Some Burroughs Transistor Computers」. Unisys History Newsletter . 3 (1). 2016年10月1日時点のオリジナルよりアーカイブ。
• Gray, George (1999年10月). 「Burroughs 第三世代コンピュータ」. Unisys History Newsletter . 3 (5). 2017年9月26日時点のオリジナルよりアーカイブ。
• Hauck, EA; Dent, Ben A. (1968). Burroughs B6500/B7500 スタックメカニズム. Spring Joint Computer Conference. pp. 245–251. doi : 10.1145/1468075.1468111 .
• McKeeman, William M. (1967).言語指向コンピュータ設計. Fall Joint Computer Conference. pp. 413–417. doi : 10.1145/1465611.1465665 .
• Organick, Elliot I. (1973). コンピュータシステムの構成 B5700/B6700 シリーズ(PDF)。Academic Press。
• ウェイコフ、リチャード (1979 年 9 月 27 日)。「B5000 とそこにいた人々の物語」(PDF)。2016 年 3 月 4 日時点のオリジナル(PDF)からアーカイブ。[2]
• Allweiss、Jack。「Burroughs B5900 と E-Mode 21 世紀のコンピューティングへの架け橋 2018 年改訂版」
• マーティン、イアン。「『時代を先取りしすぎた』：1960 年代の英国、バロウズ、リアルタイム バンキング」、技術史学会年次総会、2010 年 9 月 20 日～10 月 3 日、米国タコマ。

• イアン・ジョイナーのバロウズのページ
• Burroughs B5900 と E-Mode: 21 世紀のコンピューティングへの架け橋 - Jack Allweiss
• (ウェブアーカイブ:) モナッシュ大学の B7800 に関する Ralph Klimek 氏
• 「初期のバローズマシン」、バージニア大学コンピュータ博物館。
• 「コンピュータ システムの構成」、ACM モノグラフ シリーズ。
• B8500 マニュアルのインデックス
• B5500 エミュレーション プロジェクト Burroughs B5500 コンピュータ システム用の機能的なエミュレータを作成するプロジェクト。
• 「バロウズ B6500 フィルムとトランスクリプト」