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

バローズ・ラージ・システムズ・グループは、高密度シラブルのスタックマシン命令セットを使用した、大型48ビットメインフレームのファミリーを製造しました。[注1 ]このファミリーの最初のマシンは1961年のB5000で、シングルパスコンパイラを使用してALGOL 60プログラムを非常に良好にコンパイルできるように最適化されていました。B5000は、B5500（ドラムではなくディスク）とB5700（最大4つのシステムをクラスタとして動作）へと進化しました。その後の主要な再設計には、B6500/B6700シリーズとその後継機、および独立したB8500シリーズが含まれます

1970年代、バローズ社はハイエンド、ミッドレンジ、エントリーレベルのビジネスコンピュータシステム向けに、それぞれ大きく異なる製品ラインアーキテクチャを持つ3つの事業部に組織されました。各事業部の製品ラインは、コンピュータの命令セットを特定のプログラミング言語向けに最適化するという、それぞれ異なるコンセプトから発展しました。「バローズ・ラージシステム」とは、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プロセッサも使用し、MCP、Microsoft Windows、LinuxオペレーティングシステムをLibraサーバーで実行している。カスタムチップの使用は徐々に廃止され、2018年までにLibraサーバーは数年間完全にIntelのコモディティチップになった。

B5000、B5500、およびB5700

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

特徴

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

システム設計

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

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

B5x00相対アドレス指定[ 6 ]
SALF [ a ]ターミナル0 A38 ターミナル1 A39 ターミナル2 A40 MSFF [ b ]ベース コンテンツ インデックス符号 インデックスビット[ c ]最大インデックス
オフ — — — — R PRTのアドレス ＋ T 0-9 A 38-47 1023
オン オフ — — — R PRTのアドレス ＋ T 1-9 A 39-47 511
オン オン オフ — オフ F スタック上の 最後のRCW [ d ]またはMSCW [ e ]のアドレス＋ T 2-9 A 40-47 255
オン オン オフ — オン (R+7) [ f ]PRT+7の MSCW [ e ]からのFレジスタ＋ T 2-9 A 40-47 255
オン オン オン オフ — C [ g ]現在の命令ワードのアドレス ＋ T 3-9 A 41-47 127
オン オン オン オン オフ F スタック上の 最後のRCW [ d ]またはMSCW [ e ]のアドレス— T 3-9 A 41-47 127
オン オン オン オン オン (R+7) [ f ]PRT+7の MSCW [ e ]からのFレジスタ— T 3-9 A 41-47 127
注記：
  1. ^ SALFサブルーチンレベルフリップフロップ
  2. ^ MSFFマークスタックフリップフロップ
  3. ^オペランド呼び出し（OPDC）および記述子呼び出し（DESC）シラブルの場合、相対アドレスはシラブルのビット0～9（Tレジスタ）です。ストア演算子（CID、CND、ISD、ISN、STD、STN）の場合、Aレジスタ（スタックの先頭）には、フラグビットがセットされている場合は絶対アドレスが、フラグビットがオフの場合は相対アドレスが格納されます。
  4. ^ a b RCW  リターン制御ワード
  5. ^ a b c d MSCWマークスタック制御ワード
  6. ^ a b PRT+7のMSCWからのFレジスタ
  7. ^ストア、プログラム、および I/O リリース演算子の場合、 C (現在の命令語) 相対が R (PRT) 相対に強制される

言語サポート

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

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

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

強力なBurroughs COBOLコンパイラもワンパスコンパイラで、同様に高速でした。4000枚のカードからなるCOBOLプログラムは、毎分1000枚のカードを処理するリーダーがコードを読み取れる速度と同等の速度でコンパイルされました。カードがリーダーを通過するとすぐにプログラムが使用可能になりました。

図4.5 参考文献のACMモノグラフより。Elliot Organick 1973。

B6500、B6700/B7700、および後継機種

B6500 [ 7 ]（1969年納入[ 8 ] [ 9 ]）とB7500は、バローズシステムの中で唯一今日まで生き残っている最初のコンピュータである。B5000にヒントを得ていたが、全く新しいアーキテクチャを採用していた。最も重要な違いは、

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

ILLIAC IVスーパーコンピュータはB6500を「I/O制御コンピュータ」として使用し、ILLIAC IVの監視機能を実行し、ILLIAC IVメモリとの間のI/O操作の設定と開始を行った。[ 12 ]

B8500

B8500 [ 1 ] [ 2 ]シリーズは、B5000 にヒントを得た軍用コンピュータ である D825 [ 13 ]から派生したものです

B8500は、B5500とD825の設計を統合する試みとして1960年代に設計された。このシステムは、磁性薄膜メモリを備えたモノリシック集積回路を採用していた。アーキテクチャはB5500と同様に48ビットワード、スタック、およびディスクリプタを採用していたが、上位互換性は謳われていなかった。[ 1 ] B8500は最終的に安定動作させることができず、プロジェクトは1970年以降、完成システムを提供することなく中止された。[ 2 ]

歴史

仮想記憶の中心概念は、フェランティ・アトラスとライス研究所コンピュータの設計に登場し、記述子とタグ付きアーキテクチャの中心概念は、1950年代後半のライス研究所コンピュータ[ 14 ]の設計に登場しました。しかし、これらの設計がバローズに直接影響を与えたとしても、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の開発を継続するかどうかは不明です。

バローズ（1961～1986年）
B50001961初期システム、第2世代（トランジスタ）コンピュータ
B550019643倍の速度向上[ 2 ] [ 15 ]
B65001969第3世代コンピュータ（集積回路）、最大4プロセッサ
B57001971B5500の新名称
B67001971B6500の新名称／バグ修正
B77001972より高速なプロセッサ、スタック用キャッシュ、1つまたは2つのパーティションに最大8つのリクエスター（I/Oまたは中央プロセッサ）。
B68001977年頃半導体メモリ、NUMAアーキテクチャ
B78001977年頃半導体メモリ、高速、1つまたは2つのパーティションに最大8つのリクエスタ（I/Oまたは中央プロセッサ）。
B69001979年頃半導体メモリ、NUMAアーキテクチャ。最大4つのB6900 CPUがローカルメモリと共通のグローバルメモリにバインドされています
B59001981半導体メモリ、NUMAアーキテクチャ。最大4つのB5900 CPUがローカルメモリと共通のグローバルメモリIIにバインドされています
B79001982年頃半導体メモリ、高速化、コードおよびデータキャッシュ、NUMAアーキテクチャ

1 ～ 2 個の HDU (I/O)、1 ～ 2 個の AP、1 ～ 4 個の CPU、NUMA メモリのソフト実装により、CPU はメモリ空間からメモリ空間へと浮動できるようになりました。

A9/A101984B6000クラス、ミッドレンジ初のパイプライン型プロセッサ、シングルCPU（A10ではデュアルCPU）、eModeベータ（拡張メモリアドレッシング）を初めてサポート
A12/A151985B7000クラス、カスタム設計のモトローラECL MCA1、その後MCA2ゲートアレイに再実装、シングルCPU、シングルHDU（A12）、1～4CPU、1～2HDU（A15）
ユニシス（1986年～現在）
マイクロA1989シングルチップSCAMP [ 16 ] [ 17 ] [ 18 ]プロセッサを搭載したデスクトップ「メインフレーム」。
クリアパス HMP NX 40001996年？？[ 19 ] [ 20 ]
クリアパス HMP NX 50001996年？？[ 19 ] [ 20 ]
クリアパス HMP LX 50001998Burroughs Largeシステムをエミュレーションのみで実装（Xeonプロセッサ）[ 21 ]
リブラ1002002年？？？
リブラ200200？？？
リブラ300200？？？
リブラ400200？？？
リブラ5002005年？例：リブラ595 [ 22 ]
リブラ6002006年？？？
リブラ7002010例：リブラ750 [ 23 ]

主なハードウェアライン

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

アルゴル

バローズ・アルゴル
パラダイムマルチパラダイム：手続き型、命令型、構造化
ファミリーアルゴル
設計：ジョン・マクリントック他
開発者バローズ・コーポレーション
初登場1962年 （1962年）
プラットフォームバローズ大規模システム
OSバローズMCP
影響を受けた
ALGOL 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です。

ESPOLとNEWP

実行システム問題指向言語（ESPOL）
パラダイムマルチパラダイム：手続き型、命令型、構造化
ファミリーアルゴル
開発者バローズ・コーポレーション
初登場1966年 （1966年）
最終リリース
バロウズ B6700 B7700 / 1972年6月27日 （1972年6月27日）
タイピングの規律静的、強力
スコープ語彙（静的）
プラットフォームバローズ大規模システム
OSバローズMCP
影響を受けた
ALGOL 60
影響を受けた
NEWP

当初、B5000 MCPオペレーティングシステムは、ESPOL（Executive Systems Programming Oriented Language）と呼ばれる拡張ALGOLの拡張機能で記述されていました。このALGOL 60のスーパーセットは、マルチプロセッシングシステム（バローズの大規模システムはマルチプロセッサシステムでした）上のプロセッサへの割り込みなど、後にシステムプログラミング言語[ 24 ]またはマシン指向高階言語（mohol）と呼ばれる機能を提供しました。ESPOLは、B5000からB6700までのバローズコンピュータシステムでマスターコントロールプログラム（MCP）を作成するために使用されました。[ 25 ] [ 26 ] [ 27 ] ESPOLのシングルパスコンパイラは、1秒あたり250行以上をコンパイルできました

これは1970年代半ばから後半にかけて、NEWPと呼ばれる言語に置き換えられました。NEWPはおそらく「新しいプログラミング言語」を意味していたのでしょうが、その名前には様々な伝説が残っています。当時、バロウズ社内でよく語られていた（おそらくは作り話ですが）話によると、これは「No Executive Washroom Privileges（役員用トイレ特権なし）」に由来しているとのこと。また、1976年頃、バロウズのジョン・マクリントック（NEWPの開発ソフトウェアエンジニア）が、再び「まだ名前は決まっているのか？」と尋ねられた際に「にゃーーー」と答え、それをそのまま名前として採用したという説もあります。NEWPもALGOL拡張のサブセットでしたが、ESPOLよりも安全で、ALGOLのあまり使われていない複雑な部分を削除しました。実際、ブロックがそれらの命令を許可するように明示的にマークされていない限り、すべての安全でない構文はNEWPコンパイラによって拒否されます。このようなブロックのマーク付けは、多層的な保護メカニズムを提供します。

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

NEWPには、オペレーティングシステムなどの大規模ソフトウェアプロジェクトを実現するための様々な機能が搭載されており、名前付きインターフェース（関数とデータ）、インターフェースのグループ、モジュール、スーパーモジュールなどが含まれます。モジュールはデータと関数をグループ化し、モジュール内でグローバルにデータへのアクセスを容易にします。インターフェースは、モジュールが関数とデータをインポートおよびエクスポートすることを可能にします。スーパーモジュールは、モジュールをグループ化することを可能にします。

DCALGOL とメッセージ制御システム (MCS)

当初の実装では、システムは接続された専用のデータ通信プロセッサ（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技術はICP（統合通信プロセッサ）に置き換えられ、メインフレームシステムにLANベースの接続を提供しました。リモートデバイスとリモートサーバー/メインフレームは、CP2000と呼ばれる独立型デバイスを介してネットワークに接続されました。CP2000は、BNAV2（Burroughs Network Architecture Version 2）ネットワーク技術を使用してノードが接続された分散ネットワークにおいて、ネットワークノードのサポートを提供するために設計されました。BNAV2は、IBM SNA製品の機能的に同等のBurroughs製品であり、PUT2およびPUT5トランスポートモードの両方でIBM環境との相互運用性をサポートしていました。外部データ通信ハードウェアの変更により、既存のMCS（メッセージ制御システム（後述））ソフトウェアに変更は必要ありませんでした。

入力時には、メッセージはDCPから内部バスを介して関連するMCPデータコムコントロール（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はデータ通信制御スタック（DCC）によって管理されるキューからメッセージを受信し、適切なアプリケーション/関数に転送して処理します。初期のMCSの一つは、オンラインプログラム開発環境として開発されたCANDE（Command AND Edit）でした。ニュージーランドのオタゴ大学は、IBMがIBM 360シリーズシステム上で動作するCALL/360として知られるリモートタイムシェアリング/プログラム開発サービスを提供していたのと同時期に、CANDEと同等のSCREAM/6700と呼ばれる簡易プログラム開発環境を開発しました。COMSと呼ばれる別のMCSは、1984年頃に導入され、高性能トランザクション処理制御システムとして開発されました。 GEMCOS（一般化メッセージ制御システム）をはじめとする先行のトランザクション処理環境があり、オーストラリアのBurroughs社の子会社がTPMCS（トランザクション処理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標準で定義されたすべてのアプリケーションが実装されました。

DMALGOLとデータベース

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

DMALGOLの前処理には変数とループが含まれており、コンパイル時の変数に基づいて名前を生成できます。これにより、ループのない前処理機能では実現できないほどのカスタマイズが可能になります。

DMALGOLは、 DMSIIデータベース向けにカスタマイズされたアクセスルーチンを提供するために使用されます。DASDL（データアクセスおよび構造定義言語）を使用してデータベースが定義された後、スキーマはプリプロセッサによってカスタマイズされた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 [ 28 ]

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

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

スタックの速度とパフォーマンス

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

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

RISC設計者が主張した速度向上のもう一つの論点は、すべてがシングルチップに集積されていればプロセッサ速度が大幅に向上するというものでした。これは、B5000のようなより複雑なアーキテクチャでは、シングルチップに収めるにはあまりにも多くのトランジスタを必要としていた1970年代には妥当な主張でした。しかし、今日では状況は変わり、B5000の後継機はすべて、キャッシュや命令パイプラインといったパフォーマンス向上技術と同様に、シングルチップに収まっています。

実際、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 は暗黙的に参照渡しされます 。begin ―――――――――――――――――――――――――――― — このブロックは語彙レベル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データ型によって処理されます。EVENTデータ型では、プロセスは1つ以上のイベントを待機し、別の連携プロセスによってイベントが発生するまで待機することができます。EVENTは、PROCURE関数とLIBERATE関数を介して相互排他同期も可能にします。何らかの理由で子タスクが終了した場合、呼び出しタスクは処理を続行できます。ただし、親プロセスが終了した場合は、すべての子プロセスが自動的に終了します。複数のプロセッサを搭載したマシンでは、プロセスが同時に実行される場合があります。このEVENTメカニズムは、マルチタスクに加えて、マルチプロセッシングを実現するための基本的な要素です。

実行呼び出しタイプ

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

そのため、Burroughs Extended ALGOLは、 Adaなどの後期言語に見られるような多重処理と同期機能の一部を備えていました。ハードウェアに組み込まれた非同期処理のサポートを活用していました。

インラインプロシージャ

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

非同期呼び出し

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

ディスプレイレジスタ

スタックハードウェア最適化とは、Dレジスタ（または「ディスプレイレジスタ」）を提供することです。Dレジスタはソースプログラム内のスコープ、つまりソースコード内のネストに対応します。これらのレジスタは、呼び出される各スタックフレームの先頭を指します。これらのレジスタは、プロシージャの開始と終了時に自動的に更新され、MCP以外のソフトウェアからはアクセスできません。Dレジスタは32個あり、これにより操作は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]のディスプレイレジスタにリンクされていました。1990年代初頭には、この機能は言語機能として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では、すべての多次元配列を同じサイズの単次元配列と同等とみなし、多次元配列の場合、要素A[i,j,k]が単一の配列内で見つかるオフセットを計算するために、単純な整数演算が使用されます。この単次元の同等配列は、十分な大きさであればセグメント化される可能性があり、ALGOLの単次元配列と同じ方法でアクセスされます。この配列外へのアクセスは防止されますが、あるインデックスの誤った値と別のインデックスの適切な誤った値の組み合わせが、単一の配列配列の境界違反に至らない可能性があります。つまり、インデックスは個別にチェックされません。

配列の記憶域は、各辺が他の項目の記憶域によって制限されていないため、システムは配列の「サイズ変更」を容易に行うことができました。ただし、コンパイラはすべての参照が同じ次元数を持つことを要求していたため、次元数の変更は不可能でした。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配列もリクエストできます。

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

スタック構造の利点

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

スタック構造に関するもう 1 つの特徴は、プログラムが暗黙的に再帰的であることです。FORTRAN は再帰をサポートすることが想定されておらず、ALGOL の実装方法を理解する上で障害となったのは、おそらく再帰の実装方法でした。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が割り当てられました。以下はタグとその機能の一覧です。

タグ単語の種類説明
0データあらゆる種類のユーザーデータとシステムデータ（テキストデータと単精度数値）
2倍精度倍精度データ
4SIWステップインデックスワード（ループで使用）
6初期化されていないデータ
SCWソフトウェア制御ワード（スタックを削減するために使用）
1IRW間接参照語
SIRW詰め物入り間接参照語
3コードプログラムコードワード
MSCWマークスタック制御ワード
RCWリターン制御ワード
TOSCWスタックトップ制御ワード
SDセグメント記述子
5記述子データブロック記述子
7PCWプログラム制御ワード

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

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

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

タグ1ワードはスタック上のデータアドレスを表します。通常のIRWは、現在のスタック上のデータに対応するアドレスを単純に格納します。SIRWは、アドレスにスタック番号を含めることで、任意のスタック上のデータを参照します。SIRWは、CALL文やPROCESS文への応答として生成されるスタックなど、個別のプロセススタック間のアドレス指定に使用されます。

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

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

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

図9.2 参考文献のACMモノグラフより。Elliot Organick 1973。

記述子ベースアーキテクチャ

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

命令セット

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

B5000、B5500、B5700

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

B6500および後継機種

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

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

B5000の影響

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

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

B5000スタックアーキテクチャは、プログラミング言語Forthの設計者チャック・ムーアにインスピレーションを与えました。彼はMIT在学中にB5500に出会いました。『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ビジネスシステムの設計者たちはB5500を使用し、そのハードウェアとソフトウェアに非常に感銘を受け、同様のソフトウェアを搭載した16ビットミニコンピュータの開発を目指しました。HPの他のいくつかの部門も同様のミニコンピュータやマイクロプロセッサスタックマシンを開発しました。ボブ・バートンによる逆ポーランド記法（RPN）の研究は、9100A以降のHP製電卓にも取り入れられ、特にHP-35以降の電卓に顕著でした。

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

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

B5000アーキテクチャのもう一つの特徴は、ハードウェア上で直接実行されるセキュアなアーキテクチャであったことです。この技術は、セキュアな環境を提供するための今日の仮想マシンにも受け継がれています。注目すべき製品の一つに、アプリケーションが実行されるセキュアなサンドボックスを提供するJava JVMがあります。

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

こちらもご覧ください

注記

  1. ^例：B5000の場合は12ビット音節、 B6500の場合は8ビット音節
  2. ^セキュリティ上の問題があった
  3. ^エラー制御はカウントしない
  4. ^モデル番号にもかかわらず、B5900 は B5000 アーキテクチャではなく B6500 アーキテクチャを採用していました。
  5. ^ a b c B5000、B5500、B5700のみ
  6. ^ B6500、B7500および後継機のみ
  7. ^文字データやコードを含むワードにはフラグビットがなかった

参考文献

  • 拡張 ALGOL 入門(全 3 巻)、Donald J. Gregory。
  • コンピュータアーキテクチャ：構造化アプローチ、 R. Doran、Academic Press (1979)。
  • スタックコンピュータ：ニューウェーブ、フィリップ・J・クープマン、入手可能：[1]
  • B5500、B6500、B6700、B6800、B6900、B7700 のマニュアルは、bitsavers.orgでご覧いただけます。
  1. ^ a b cジョン・T・リンチ（1965年8月）「バロウズB8500」（PDF）、データメーション：49～ 50
  2. ^ a b c d George Gray (1999年10月)、「Burroughs Third-Generation Computers」、Unisys History Newsletter、3 (5)、2017年9月26日時点のオリジナルよりアーカイブ。
  3. ^ Burroughs (1963)、Burroughs B5000プロセッサの動作特性(PDF)、改訂A、5000-21005
  4. ^ John Mashey (2006年8月15日). 「称賛すべきデザイン／研究すべきデザイン」 .ニュースグループ:  comp.arch . Usenet: [email protected] . 2007年12月15日閲覧。 
  5. ^ a b Burroughs（1967年5月）、Burroughs B5500情報処理システムリファレンスマニュアル（PDF）、1021326
  6. ^「表5-1 相対アドレス表」より。Burroughs B5500 情報処理システム リファレンスマニュアル(PDF)。システムドキュメント。Burroughs Corporation。1967年5月。p. 5-4。1021326。
  7. ^ a b Burroughs B6500 情報処理システム リファレンスマニュアル(PDF)、Burroughs、1969年9月、1043676
  8. ^ a b「1960年代の歴史的物語：米国対IBM、証拠物件14971、パート2」。ed -thelen.org。米国政府。1980年7月22日。648頁（409頁） 。 2019年2月21日閲覧。代替URL
  9. ^ GhostarchiveとWayback Machineにアーカイブ： Burroughs Corporation（1969年）、Burroughs B6500 Status Report（映画）、Nigel Williams（2015年8月8日公開）、タイムコード：1969 ステータス - 0:00～0:52、6:04～7:01、8:14、日付 - 3:40、4:21 、 2019年3月4日取得
  10. ^ヘイズ、ジョン・P. (1978).コンピュータアーキテクチャと組織. pp.  148– 149. ISBN 0-07-027363-4。
  11. ^ 「コンピューティングの歴史展示：4階」オークランド大学。2020年5月18日閲覧
  12. ^ ILLIAC IV 技術概要(PDF) 1968年4月22日 B-176-B。
  13. ^アンダーソン, ジェームズ・P.; ホフマン, サミュエル・A.; シフマン, ジョセフ; ウィリアムズ, ロバート・J. (1962)、「D825 - コマンド＆コントロールのための複数コンピュータシステム」、1962年12月4～6日開催の秋季合同コンピュータ会議議事録、AFIPS会議議事録、第24巻、pp.  86～ 96、doi : 10.1145/1461518.1461527、ISBN 9781450378796、S2CID  1186864{{cite book}}：ISBN / 日付の非互換性（ヘルプ）
  14. ^ Henry M. Levy、「第2章 初期の記述子アーキテクチャ」(PDF)、Capability-Based Computer Systems、Digital Press
  15. ^ 「B5500発表」(PDF) . バロウズ. 1964年8月11日.
  16. ^ 「Daves Old Computers - Other Machines」 . Unisys A7-311 . 2023年3月30日閲覧。
  17. ^ 「SCAMPの写真、Dave's Old Computersにて」 。 2023年3月30日閲覧。
  18. ^ Reitman, Valerie (1989年1月18日)、「Unisys Ready To Offer A Desktop Mainframe」、The Philadelphia Inquirer、2012年4月26日時点のオリジナルよりアーカイブ、 2011年4月16日閲覧。
  19. ^ a b「会社沿革」 2021年7月9日. 2021年8月28日閲覧。
  20. ^ a b「Unisys、A&OS 2200シリーズの顧客への道筋を明確に」2021年8月28日閲覧。
  21. ^ 「Unisys、新しいClearPathエンタープライズサーバーと積極的な新価格設定でメインフレームの再生を加速 - Business Wire - HighBeam Research」 （プレスリリース）。1998年6月8日。2011年5月16日時点のオリジナルよりアーカイブ。
  22. ^ 「Libra 595」。ユニシス。
  23. ^ “Libra 750” . Unisys. 2021年6月24日. 2020年3月11日時点のオリジナルよりアーカイブ。2018年5月16日閲覧。
  24. ^ Bergeron, RD; et al. (1972年12月15日). 「システム開発のための言語」. Rubinoff, Morris (編). Advances in Computers . 第12巻. ニューヨーク; ロンドン: Academic Press . p. 282. ISBN 978-0080566443。
  25. ^スタッフ(1966). B5500 ESPOLリファレンスマニュアル(PDF) .デトロイト、ミシガン州: Burroughs Corporation –コンピュータ歴史博物館経由
  26. ^スタッフ（1970年1月）。B6500 ESPOLリファレンスマニュアル（PDF）。ミシガン州デトロイト：Burroughs Corporation –コンピュータ歴史博物館経由。
  27. ^スタッフ (1972年6月27日). B6700/B7700 エグゼクティブ・システム・プログラミング言語 (ESPOL) 情報マニュアル(PDF) .デトロイト、ミシガン州: Burroughs Corporation –コンピュータ歴史博物館経由.
  28. ^オーガニック、エリオット(1973).コンピュータシステムの構成. ACM . pp.  115– 117. ISBN 0-12-528250-8。
  29. ^ GM Amdahl、 GA Blaauw、FP Brooks（1964年4月）。「IBM System/360のアーキテクチャ」。IBM Journal of Research and Development。8 ( 2): 87–101。doi : 10.1147/rd.82.0087 。 2021年9月10日閲覧– ResearchGate経由

さらに詳しい情報

「 https://en.wikipedia.org/w/index.php?title=Burroughs_Large_Systems&oldid=1335542103#B5700」より取得