TOPS-20 was first announced as a
DEC
product and shipped in January, 1976.
Development had started in 1973 based on TENEX[1], an operating system for
the
PDP-10
then in use at a number of research installations around the country.
Many factors were involved in the decision to start TOPS-20 development,
but primarily, DEC wanted a new virtual memory operating system
for the KL10 processor then in the early stages of development.
Although much was added and changed
as TENEX became TOPS-20 from 1973 to 1976,
most of its architecture remained
as it was designed in 1969 at Bolt Beranek _& Newman Inc.
(BBN) in Cambridge.
TOPS-20 が
DEC
の製品として発表され、出荷が開始されたのは 1976 年 1 月のことでした。
その開発は 1973 年に
その当時、国内の多くの研究所に導入されていた
PDP-10
のオペレーティングシステムだった
TENEX [1]
をベースにして始まりました。
TOPS-20 の開発に着手する決定には多くの要因が関係していましたが、
本質的に、DEC は
開発の初期段階にあった
KL10
プロセッサのための
仮想記憶をサポートした新しいオペレーティングシステムを
必要としていました。
1973年から1976年にかけて、
TENEX を TOPS-20 に変えるための、
多くの追加／修正が施されましたが、
そのアーキテクチャーほとんどのは
1969 年に Cambridge の
Bolt Beranek _& Newman Inc
(BBN)
で行なわれた設計のまま残りました。
Hence, to understand the factors which influenced the design of TOPS-20,
we have to look back to the late 1960s and the environment
in which TENEX was created.
Some of the ideas that went into TENEX,
and the process which ultimately brought it into DEC,
had roots going back to the early 1960's.
In this section, we will trace these aspects of TOPS-20's history.
したがって、
TOPS-20 の設計に影響を及ぼした要因を理解するためには、
私たちは
TENEX
が開発された
1960
年代後半の環境を
振り返らなければなりません。
TENEX に取り入れられた幾つかのアイデアと
最終的にそれが DEC にもたらされた経緯には
1960年代初めまで遡る起源がありました。
このセクションでは、
これらの TOPS-20 の歴史の状況について辿ります。
I was an undergraduate at
MIT
from 1961 to 1965.
After receiving my degree in 1965,
I went to work for BBN doing various system programming activities
and, in particular,
supporting the LISP system then in use for AI research.
I was involved in the design of TENEX
and implemented a number of its kernel modules from 1968 to 1972 and
then came to DEC along with TENEX in 1973.
1961 年から 1965 年まで、私は
MIT
の学部生でした。
1965 年に学位を取得した後、
私は BNN に就職し、さまざまなシステムプログラミングの活動、
特にその当時 AI の研究に使われていた LISP システムのサポートを行ないました。
1968 年から 1972 年まで、
私は TENEX の設計に関わり
いくつかのカーネルモジュールを実装しました。
その後 1973 年に、
TENEX と一緒に DEC に来ました。
DEC bought TENEX in 1973,
believing that it represented a good base for a new,
state-of-the-art commercial system.
However, as with other "overnight sensations",
this was just the final step
in a flirtation between DEC and BBN that had gone on over many years.
In 1961,
BBN was one of the first sites external to DEC to install and use a PDP-1
(DEC's first computer),
and did some early experiments in timesharing using this machine
and some locally designed modifications.
This is generally recognized as the first practical timesharing system.
During the subsequent years,
many discussion took place between the two companies
about the best way to design and build computers.
1973 年に DEC は最先端技術を用いた全く新しい商業システムの
ベースになると信じて TENEX を購入しました。
しかしながら、これは
"overnight sensations" のような、
DEC と BBN との間で長年に渡って続けられた密月の最終ステップでした。
1961 年、
BBN は PDP-1 (DEC 初のコンピュータ)
を導入し使用していた DEC の社外の初期サイトの１つで、
このマシンに部分的に手直しをしたものを使って、
初期のタイムシェアリングに関する幾つかの実験を行ないました。
続く数年は、
コンピュータの設計と製造に関する最良の方法について、
この２つの会社の間で多くの議論が発生しました。
One such area of discussion was paging and memory management.
BBN was pursuing a number of AI research projects in LISP,
and these typically required a large amount of random access memory.
Few computers of that day
(and none that BBN could afford)
had the size of memory that was required,
so various alternative techniques had been sought
to work around the limitation [2].
Paging and "virtual memory" was one
in which there was a great deal of interest.
There was a LISP system running on the PDP-1 at BBN,
and I had converted it to use a software paging system
that I had developed earlier at MIT.
議論した領域の１つにページングとメモリ管理がありました。
BBN は LISP による AI (人工知能) の研究プロジェクトを推進しており、
これは大量のランダム・アクセス・メモリーを必要としました。
(BBN には調達するだけの余裕はなかったのですが)
その当時は必要とされる容量のメモリが搭載されているコンピュータは限られており、
そのため、その制限に対処できるさまざまな代替技術が模索されていました。
ページングと「仮想記憶」は多くの関心を集めるものでした。
BBN には PDP-1 の上で稼働する LISP システムがあり、
私が以前 MIT で開発したソフトウェアによるページングシステムを移植しました。
This system used a high speed drum as backing store for main memory,
and divided both main memory and the drum into fixed size units (pages)
that could be copied back and forth as necessary.
The LISP system itself used 18-bit pointers
and was built as if there were an 18-bit (262 kword) memory on the machine.
However, with software paging,
each reference to the target of one of these pointers
was changed to a subroutine call (or in-line sequence).
The subroutine would take the high order few bits of the pointer
as an index into an array (the page table)
which would contain the actual current location of the page.
If the page were then in main memory,
the page number bits from the table would replace those
which had been used as the index into the table,
and the reference would be completed.
If the desired page were not in main memory,
a call would be made to a "page manager" routine
to rearrange things as necessary.
That meant selecting a page in main memory
to be moved (copied) back to the drum,
and then reading into this page the desired page from the drum.
Finally, the table would be adjusted to reflect these changes,
and the reference sequence begun again.
このシステムはメインメモリのための backing store として高速ドラムを使用し、
メインメモリ、ドラムの両方を固定サイズのユニット (ページ) に分割していたので、
必要なときには相互にコピーすることができました。
LISP システム自体は 18 ビットのポインターを使用して、
あたかもマシン上に 18ビット (262 kword) のメモリがあるかのように
構成されていました。
しかしながら、ソフトウェア・ページングでは、
これらの任意のポインターのターゲットの個別の参照は
サブルーチンの呼び出し (あるいはインラインのシーケンス) に置き換えられました。
サブルーチンはポインタの上位の数ビットを
ページの実際の現在位置を含んでいる配列 (ページテーブル) への
インデックスとします。
ページがメインメモリに存在すれば、
テーブルのインデックスとして使用されたものは
テーブルのページ番号ビットに置き換えられ、
参照は完了します。
必要なページがメインメモリになければ、
"page manager"
ルーチンを呼び出し、
必要な再調整を行います。
それはメインメモリ中のページを選択しドラムに移動させた (コピーする) のちに、
このページにドラムから必要ページを読むことを意味します。
最後にテーブルにこの変更を反映した調整を行い、
もう一度参照の参照のシーケンスを始めます。
In actual use, this system was fairly effective.
The reference patterns of the typical LISP programs
that we were running were such
that the system was not dominated by waits for drum IO.
That is, most pointer references were to pages then in main memory,
and only a small fraction were to pages which had to be read in from the disk*.
実際の使用では、
このシステムがかなり有効でした。
私たちが実行していた LISP プログラムの典型的な参照パターンでは、
システムはドラム入出力待ちの影響は受けませんでした。
すなわち、
ほとんどのポインター参照はメインメモリ上のページへのもので、
ディスクから読み込まれたページはごく小数でした。*
[* -
Several studies, some by us at BBN,
had been done
to investigate memory reference behaviour
and gather statistics from various programs
[3].]
BBN に所属する私たちの誰かのいくつかの研究では、
メモリ参照の振る舞いとが調査され、
様々なプログラムから統計を集められました。
However,
the actual number of references was sufficiently high
that a great deal of time was spent
in the software address translation sequence,
and we realized that, ultimately,
this translation must be done in hardware
if a truly effective paged virtual memory system were to be built.
しかしながら、
実際の参照回数は十分に高く、
ソフトウェアによるアドレス変換シーケンスで
多くの時間が費やされたました。
結局、
もし本当に効果的なページングによる仮想記憶システムを構築しようするなら、
この変換はハードウェアで行わなければならないことを悟りました。
The PDP-6 had been announced in 1964
and was immediately the machine of choice for LISP programming.
A single word holding two addresses (a CAR and CDR in LISP terms)
seemed designed especially for LISP (this wasn't mere coincidence).
The big (for the time) address space of 2_^18 words offered
the promise of fast, efficient execution of large LISP programs.
Although the basic instruction set didn't include a CONS instruction
(the LISP primitive that builds lists),
one early PDP-6 had a special modification installed to provide
that operation.
This was the machine that was installed
at the AI Lab of Stanford University,
headed by one of the inventors of LISP, John McCarthy.
PDP-6 は 1964 年の発表直後より、
LISP プログラミングのために選択すべきマシンになりました。
２つのアドレス
(LISP 用語の CAR および CDR)
を保持する単一のワードは、
特に LISP のために設計されたように見えました。
(これは単なる一致ではありませんでした)
(その時点で) 2＾18 ワードの大きなアドレス空間は、
大規模な LISP プログラムの速く効率的な実行の見込みを提示しました。
基本的な命令セットは CONS 命令
(リストを構築する LISP の原始関数)
を含んでいませんでしたが、
初期の PDP-6 の１台には、
そのオペレーションを提供する特別の修正がインストールされていました。
これは LISP の発明者の１人である
John McCarthy
が率いる
Stanford University
の
AI Lab
に設置されたマシンでした。
The group at BBN had every intention of acquiring a PDP-6
to improve our LISP capabilities,
but of course, we wanted it to have hardware paging
so that we could carry over the paging techniques from our PDP-1 LISP.
Several discussions were held between BBN and DEC,
including Win Hindle and Alan Kotok on the DEC side.
BBN was lobbying for paging
to be included in a subsequent PDP-6 model,
or possibly as an add-on,
but these discussion came to an end
when DEC announced that there would be no further PDP-6 models
--
that is, that DEC was going out of the 36-bit business.
This (1966) was the first of several such occasions.
BBN のグループは、
私たちの LISP の能力を改善するため
PDP-6 の調達を固く決意していましたが、
しかし、もちろん、
それにはハードウェアによるページングを行ってほしかった。
私たちの PDP-1 LISP からページングの技術を持ち越すことができたからです。
BBN と DEC の間でいくつかの議論が持たれました。
DEC 側からは
Win Hindle
と
Alan Kotok
も参加していました。
BBN は
後の PDP-6 のモデルに含まれたか、おそらくアドオン製品になった、
ページング機能のためのロビー活動をしていました。
しかし、これ以上の PDP-6 のモデルはないことを DEC が発表した時、
これらの議論は終りました。
--
すなわち DEC は 36-bit のビジネスから撤退しました。
(1966 年に起きた)
この出来事は
(この後)
幾つも起きたこの種の出来事の最初でした。
Taking DEC at its word,
BBN turned its attention to selecting another machine,
hopefully one with an expanding future,
that we could use to support our various research projects.
The result of this selection process was the purchase of an SDS-940.
SDS was Scientific Data Systems in El Segundo, California,
later acquired by Xerox and known as XDS.
The SDS-940 was a 24-bit word machine with a modest virtual address space,
but it did have hardware paging capabilities.
Also, SDS was touting as a follow-on,
the Sigma-7 then under development,
which would be larger, faster, and do all the things
we could ever possibly want.
If it did, we never found out because by the time it came out,
the DEC KA-10 had been announced (or at least leaked),
and we happily switched back to the architecture we really wanted.
DEC の撤退は、
BBN を
将来の発展が期待でき、
様々な研究プロジェクトをサポートするために利用できるであろう
別の機械の選択に向かわせました。
この選択作業の結論は SDS-940 の購入でした。
SDS とは後に Xerox によって買収され XDS として知られた、
California の El Segundo にある Scientific Data Systems のことでした。
SDS-940 はささやかな仮想アドレス空間を持つ 24-bit のワードマシンでしたが、
ハードウェアによるページング機能を備えていました。
さらに SDS はその後続として、
その時開発中だった Sigma-7 を売り込んでいました。
それはより大きく、より早く、そしておそらく
私たちがこれまで望んできた全てのことができるものでした。
(もっとも)もしそれが実現されたとしても、
採用されることはなかったでしょう。
それが出荷されるまでに、
DEC の KA-10 が発表され (少なくとも漏れた)、
幸運にも我々が本当に望んだアーキテクチャーに変わっていたからです。
It was also a factor that the Sigma-7 suffered a bit of schedule slippage.
Yes, this actually happened despite firm assurances from SDS
that no such thing was possible.
SDS had even published several ads in trade magazines
touting their forthcoming system
as "the best timesharing system not yet available".
Another memorable ad read
"they said we must be crazy to publish a firm software development schedule,
but here it is."
Apparently, "they" were right
because that firm schedule went the way of most "firm"
software development schedules of the period.
さらに Sigma-7 は少々スケジュールが遅れているという要因もありました。
そう、
SDS からの「そのようなことは起こり得ない」という固い保証にもかかわらず、
これは現実に起こりました。
SDS は
「これまでにない最高のタイムシェアリング・システム」として
業界誌に近々発表されるシステムを宣伝する様々な広告を掲載していました。
その時読んだ別の記憶すべき広告では
「堅固なソフトウェアの開発スケジュールを公表することはバカげたことですが、
それはこれです。」
と彼らは語っていました。
明らかに、
その堅いスケジュールは
期間内の「最も堅い」ソフトウェア開発スケジュールでしたので、
「それら」は正しかったといえます。
The former ad also inspired someone at DEC to create a counter ad for
TOPS-10
which read "announcing the best timesharing system very much available."
前述の広告は DEC の誰かをを刺激し、
それに対抗する
「既に存在する最良のタイムシェアリング・システムの発表」という
TOPS-10
の広告を作成しました。
BBN did use the SDS-940 for a couple of years however,
and we ran on it an operating system developed by a group at U.C. Berkeley.
That was significant
because a number of features in the Berkeley timesharing system
were later modified and adopted into TENEX.
しかしながら、
BBN は数年間 SDS-940 を使用し、
その上で U.C. Berkeley のグループが
開発したオペレーティングシステムを稼働させました。
Berkeley timesharing system の多くの機能が
後に修正され、TENEX に導入されたことは特筆すべきことでした。
When BBN found out the DEC had secretly gone back into the 36-bit business
(or at least was developing a new machine of that architecture),
we once again lobbied for the inclusion of a hardware paging system.
And once again, this was to no avail.
One advancement in the KA-10 was the dual protection and relocation registers
(the PDP-6 had only a single pair).
This allowed programs to be divided into two segments:
a reentrant, read-only portion, and a read-write data area.
That, however, was as far as DEC was willing to go at that time
in advancing the state of the art of operating system memory managment support.
DEC が秘密裏に 36-Bit のビジネスへ戻ったことを BBN が知った時
(少なくともそのアーキテクチャーの新しいマシンの開発は進められてました)、
私たちは再びハードウェアによるページングシステムのサポートさせるために
ロビー活動をしましたが、これもまた無駄に終りました。
KA-10 の１つの進歩は２重の保護と再配置レジスタでした。
(PDP-6 では１組しか持っていませんでした)
これはリエントラントな読み出し専用の部分と読出し書込みデータ・エリアの、
２つのセグメントに分割されるプログラムを可能にしました。
しかしながら、
あの当時の DEC がオペレーティングシステムでのメモリ管理の
最先端技術のサポートを自ら着手するのは遠い将来のことでした。
Another factor was DEC's firm intent
to keep down the price of this new large machine.
DEC was doing well with small machines
(PDP-5 and PDP-8 in particular),
but the PDP-6 had suffered numerous engineering and reliability problems,
was hard to sell, and, some say,
almost wrecked the company.
The KA-10 had a design constraint
that a minimal machine could be configured and sold for under $100,000.
This configuration was limited to 16 kwords of main memory
and had no solid-state registers for the 16 accumulators
(all AC references went to main memory at considerable cost in speed).
To support this, a "tiny" build of TOPS-10 was designed
which would fit in 8 kwords,
and various utilities were similarly squeezed: the 1K PIP, etc.
Whether the $99,999 entry price was a good marketing ploy is hard to say.
In any case, none of that configuration were ever sold.
もう一つの要因は
この新しい大きなマシンの価格を抑えようとする DEC の強い意志でした。
DEC は小さなマシン
(具体的には PDP-5 や PDP-8)
ではうまくやっていました。
しかし PDP-6 では多くの技術的および信頼性に関する問題を経験したため、
それを販売することは難しく、誰かは会社を破滅させると語っていました。
KA-10 は最小構成のマシンで、かつ 100,000 ドル未満で販売できるという、
設計上の制約を持っていました。
この構成ではメインメモリは 16K ワードに制限されており、
１６本のアキュームレータも半導体によるレジスタではありませんでした。
(これにより、全ての AC 参照はメインメモリに集中し、
動作速度に考慮すべき損失をもたらしました）
これをサポートするため、
TOPS-10 の「小さな」ビルドは 8K ワードにフィットし、
1K の PIP など様々なユーティリティも同様に圧縮されて設計されました。
99,999ドルのエントリー価格がよいマーケティング策略だったかどうかは
答えることが難しいでしょう。どんな場合も、
その構成で販売されることはなかったからです。
Then too,
paging and "virtual memory" were still rather new concepts at that time.
Significant commercial systems had yet to adopt these techniques,
and the idea of pretending to have more memory
that you really had was viewed very skeptically in many quarters.
その当時でもまだページングや「仮想記憶」はいささか新しい概念でした。
重要な商用システムではまだこれらの技術を採用していませんでしたし、
実際よりも多くのメモリを持っているように見せかけるアイデアは、
各方面から大変懐疑的に見られていました。
Undaunted by DEC's refusal to see the wisdom of our approach,
BBN nonetheless planned the purchase of several KA10's
and set about figuring out how to turn them into the system we really wanted.
In addition to the 36-bit architecture we favored,
the KA10 system had retained much of the hardware modularity of the PDP-6
including in particular the memory bus with independent memory units.
This led us to conceive of the idea of putting a mapping device
between the processor and the memories
which would perform the address translation as we wanted it done.
私たちのアプローチの知恵を知ることを拒絶する DEC にもにひるまず、
それにもかかわらず BBN はいくつかの KA10 の購入を計画し、
それを私たちの望むものへの変更方法を明らかにすること着手しました。
私たちが支持した 36-bit のアーキテクチャーに加えて、
KA10 システムは特にメモリユニットに依存しないメモリバスなど、
PDP-6 のハードウェアのモジュラリティ以上のものを持っていました。
これが私たちにプロセッサとメモリの間にマッピングデバイスを置く
アイデアを思いつかせました。
Another decision we had to make was
whether or not to attempt to modify TOPS-10 to support demand paging.
The alternative was to build a new system from scratch,
an ambitious undertaking even in those days.
Obviously, we decided to build a new system
--
the system which was later named TENEX.
This decision was justified largely on the grounds
that major surgery would be required to adopt TOPS-10 as we desired,
and even then we probably wouldn't be able to solve all the problems.
In retrospect, this view was probably justified since,
although TOPS-10 development continued for nearly 20 years
after we started TENEX,
TOPS-10 was never modified
to have all of the virtual memory features of TENEX/TOPS-20.
TOPS-10 did ultimately support paging and virtual memory,
but not the various other features.
私たちがしなければならなかったもう一つの決断は、
デマンド・ページングをサポートするために
TOPS-10 の修正を試みるべきか、否かでした。
その代案はスクラッチから新しいシステムを開発することで、
それはその当時としても野心的な取り組みでした。
当然、私たちは新しいシステムを開発することを決定しました
--
これが後に TENEX と名付けられたシステムです。
この決定は主に我々が望むものを TOPS-10 に追加するためには大手術が必要で、
仮にその作業を行ってもおそらく全ての問題は解決できないと
思われることを根拠に正当だとされました。
思い返せば、
TENEX が始まった後 TOPS-10 の開発が 20 年近く継続されたましたが、
おそらくこの見方は正しかったでしょう。
TOPS-10 は TENEX/TOPS-20 の仮想記憶の機能の全てを
サポートするために修正されることはありませんでした。
結局 TOPS-10 もページングと仮想記憶はサポートしましたが、
その他の数々の機能はサポートされませんでした。
Beyond that,
there were a number of other features not related to paging
that we wanted in an operating system.
This further tilted the decision toward implementation of a new system.
On the other hand, we had no desire or ability
to implement new versions of the many language compilers and utilities
then available under TOPS-10,
so a method of running these images "as is" was needed.
We decided it would be possible
to emulate the operating system calls of TOPS-10 with a separate module
which would translate the requests into equivalent native services.
This is described in more detail later.
The plan then, would be to implement a new system
from the operating system interface level down
plus particular major systems such as LISP
that were key to our research work.
そのほかに、
我々がオペレーティングシステムに望む、
ページングに関係のない多くのその他の機能がありました。
これがより一層新しいシステムを実装する決定に傾けました。
一方、私たちには
その時の TOPS-10 で利用可能だった、
欲しい、あるいは使える
多くの言語コンパイラやユーティリティの
新しいバージョンの実装がありませんでした。
したがって、これらの "as is" の状態のイメージを稼働させる方法が必要でした。
我々は、独立したモジュールとして
要求を等価なネーティブサービスに変換する TOPS-10 のオペレーティング
システム呼び出しのエミュレーションを実装することは可能だと決断しました。
これについては詳細を後述します。
その時の計画は
オペレーティングシステムのインタフェース以下の新しいシステムに加え、
我々の研究の鍵となる LISP などの特定の大きなシステムを実装することでした。
Virtual memory through paging was the fundamental need
that led to the decision to build TENEX.
Had TOPS-10 or another system been available
which supported only that requirement,
we probably would have used it
and not undertaken the construction of a new kernel.
The other desires we had for our system would not have been sufficient
to warrant such an effort, and of course,
we did not foresee all of the capabilities that it would eventually have.
ページングによる仮想記憶が
TENEX を開発する決定させる基本的なニーズでした。
その要求だけを満たすのなら TOPS-10 や その他のシステムでも利用可能でした。
おそらく我々はそれが使い、
新しいカーネルの構築に着手することは避けたかったのです。
我々がシステムに望んだその他の要求は
そのような努力を保証するためには十分ではなかったでしょう。
そしてもちろん、
我々はそれが最終的に獲得した能力全てを予測することはできませんでした。
TENEX development was motivated largely
by the needs of various research programs at BBN,
Artificial Intelligence in particular.
These needs were shared by a number of other labs
supported by the Advanced Research Projects Agency (ARPA) of the DOD,
and in the period from 1970 to 72,
a number of them installed TENEX
and made it the base for their research programs.
As noted before,
a large virtual memory was foremost among these needs
because of the popularity and size of the LISP programs
for speech recognition,
image processing,
natural language processing,
and other AI projects.
TENEX の開発の大部分は
BBN での様々な研究プログラム
(特に人工知能)
でのニーズによって動機づけられました。
これらのニーズは
DOD の高等研究計画局 (ARPA) が支援する、
その他の多くの研究室とも共有していました。
そして 1970 年から 72 年までの期間に、
彼らの多くは TENEX をインストールし、
研究プログラムのベースとしました。
先に述べたように、
音声認識、
イメージプロセシング、
自然言語処理、
あるいはその他の AI プロジェクトに使われる
LISP プログラムの人気とその大きさのため、
広大な仮想記憶はこれらのニーズに共通した最も重要なものでした。
During this same period,
the ARPA network was being developed and came on line.
TENEX was one of the first systems to be connected to the ARPANET
and to have OS support for the network as a general system capability.
This further increased its popularity.
同じ期間に、ARPA ネットワークが開発されており、立ち上がりました。
TENEX は
ARPANET に接続され、
一般的なシステムの機能として、
ネットワークが OS でサポートされた
最初のシステムのうちの１つでした。
これはさらにその人気を増加させました。
Like most other software systems,
TENEX was an amalgam of ideas from a number of sources.
Most of the features which came to be prized in TOPS-20
had roots in other systems.
Some were taken largely unchanged,
some were modified in ways that proved to be critical,
and others served merely
as the germ of an idea hardly recognizable in the final system.
Among those that we can trace to one or more previous systems are:
"escape recognition",
virtual memory structure,
process structure and its uses,
and timesharing process scheduling techniques.
多くの他のソフトウェア・システムと同じように、
TENEX は多くのソースからのアイデアの融合体でした。
TOPS-20 の中で重視されるほとんどの機能は他のシステムにルーツを持っていました。
あるものはその大半を手直しすることなく使用し、
致命的だと判定されたものは修正され、
その他のものは単に
最終のシステムにはとても残りそうにないアイデアの種として提供されました。
私たちが前身の、あるいはその祖先のシステムまで辿ることのできるものは
"escape recognition"、
仮想記憶の構造、
プロセス構造およびその用途、
タイムシェアリングのプロセスをスケジュールする技術
が上げられます。
Three system most directly affected the design of TENEX
--
the MULTICS system at MIT,
the DEC TOPS-10 system,
and the Berkeley timesharing system for the SDS 940 computer.
MULTICS was the newest and most "state of the art" system of that time,
and it incorporated the latest ideas in operating system structure.
In fact, it was popular in some circles to say that,
with the implementation of MULTICS,
"the operating system problem had been solved".
Several members of the MIT faculty and staff who had worked on MULTICS
provided valuable review and comment on the emerging TENEX design.
最も直接的に TENEX の設計に影響を与えたのは、
MIT の MULTICS システム、
DEC TOPS-10 システム、
および SDS 940 コンピューター用の Berkeley timesharing system
の３システムです。
MULTICS は最も新しく、その時点での「最先端技術」によるシステムで、
オペレーティングシステムの構造に関する
最も新しいアイデアを具体化したものでした。
実際、MULTICS の実装によって
「オペレーティングシステムの問題は解決された」と述べる集団の中では
人気がありました。
MULTICS に関わる多くの MIT の教員やスタッフが
新たに開発される TENEX の設計について
価値のある論評およびコメントを提供してくれました。
Many of the paging concepts came from our own previous work,
the PDP-1 LISP system in particular.
Other ideas had recently appeared in the operating system literature,
including the "working set" model of program behaviour by Peter J. Denning[4].
MULTICS had developed the concept of segmentation and of file-process mapping,
that is, using the virtual address space
as a "window" on data which permanently resides in a file.
ページングに関する概念の多くは我々自身のこれまでの仕事、
特に PDP-1 LISP システムから来ました。
その他のアイデアは
Peter J. Denning による
プログラムの立ち振舞いの "working set" モデル [4] を含む、
近年のオペレーティングシステムに関する文献から引用されました。
MULTICS はセグメンテーションの概念と
ファイル−プロセス・マッピングの概念により開発されました。
ファイル−プロセス・マッピングの概念とは
ファイルの中に定常的に存在するデータの「ウィンドウ」として
仮想アドレス空間を使用するものです。
The Berkeley 940 system had a multi-process structure,
with processes that were relatively inexpensive to create.
That in turn allowed such things
as a system command language interpreter which ran in unprivileged mode
and a debugger which did not share address space with the program under test
and therefore was not subject to being destroyed by a runaway program.
Berkeley 940 system は生成のコストが比較的軽いプロセスによる
マルチプロセス構造を持っていました。言い換えると、
それは特権のないモードで実行するシステム・コマンド言語インタープリターや、
対象となっているプログラムとアドレス空間を共有しない、
故に暴走プログラムによって破壊される被害のないデバッガを許しました。
These two concepts, virtual memory and multiple processes,
were fundamental to the design of TENEX,
and ultimately were key to the power and flexibility of TOPS-20.
The two abstractions also worked well together.
The concept of a process included a virtual address space of 262 kwords
(18-bit addresses)
--
the maximum then possible under the 36-bit instruction set design.
Extended addressing was still many years away,
and the possibility that more than 262k
might ever be needed rarely occurred to anyone.
仮想記憶とマルチプロセスという、
これら２つの概念は TENEX の設計の基本であり、
結局 TOPS-20 の能力と柔軟性の鍵となりました。
２つの抽象化された概念の併用は功を奏しました。
プロセスの概念には 262K word の仮想アドレス空間
(18-Bit のアドレス空間) を含んでいました
--
その後、最大 36-Bit のインストラクションセットによる設計が可能になりましたが。
アドレッシングの拡張はまだ何年も先のことでしたし、
262K word 以上必要となる可能性は滅多にないと誰もが考えました。
We merely wanted the full virtual address space
to be available to every process,
with no need for the program itself
to be aware of demand paging or to "go virtual".
We believed that
mechanisms could be built into the paging hardware
and operating system to track and determine process working sets,
and it would do as good a job at managing memory efficiently
as if the program explicitly provided information (which might be wrong).
It might happen, of course, that
a particular program had too large a working set
to run efficiently in the available physical memory,
but the system would still do the best it could
and the program would make some progress
at the cost of considerable drum thrashing.
In any event, the implementation of virtual memory was
to be transparent to user programs.
私たちは稼働中の全てのプロセスに
プログラム自体がデマンドページングや仮想への移行を意識する必要のない
十分な仮想アドレス空間のみを望みました。
私たちはページングを行うハードウェアとオペレーティング・システムに
プロセス・ワーキングセットを追跡し決定するメカニズムを組み込むことができ、
それはあたかもプログラムが明示的に情報を提供したかのように
メモリを効率良く管理する仕事を行うと信じました。
(それは間違いだったかもしれません)
もちろん、利用可能な物理メモリーの中で効率よく実行するため、
特定のプログラムが大き過ぎるワーキングセットを持つことは起こるかもしれません。
しかし、それでもシステムはでき得る最善を尽くすでしょうし、
そのプログラムによって相当なドラムのスラッシングという
代償を払うことになるでしょう。
どんな場合でも、
仮想記憶の実装はユーザのプログラムには気付かれないものでした。
To support transparent demand-paged virtual memory, we had learned that
we had to maintain history information about the behaviour of programs
and the use of pages. This led to the design and inclusion of the "core
status table" in the hardware paging interface. Other tables (i.e.
page tables) would hold information that provided the virtual-to-physical
address translation; the core status table was specified to hold
information related to the dynamic use and movement of pages. For each
physical page in use for paging, the core status table would record:
(1) a time-stamp of the last reference, and (2) an identification of
the processes that had referenced the page. The latter was included
because we expected that there would often be many processes sharing
use of a given page. The need for sharing was represented in several
other aspects of the paging design as well[5].
透明なページが要求につけられた仮想記憶を支??ｷるために、私たちは、プログラムの振る舞いおよびページの使用に関する歴史情報を維持しなければならないことを知りました。これはハードウェアにページをつけるインターフェースで、「中核ステータス・テーブル?vのデザインおよび包含に結びつきました。他のテーブル(つまりページ・テーブル)は、物理アドレスに仮想翻訳を提供した情報を保持するでしょう;中核ステータス・テーブルは、ページの動的な使用および移動と関係する情報を保持すると明示されました。ページングのための使用での個々の物理的なページについては、中核ステータス・テーブルが記録するでしょう:(1) 最後の参照のタイムスタンプ、および(2)ページに参照を付けたプロセスの識別。多くのプロセスが与えられたページの使用をしばしば共有するだろうと私たちが期待したので、後者が含まれていました。共有の必要は、ページをつける設計の他のいくつかの様相の中で同様に表わされました[5].
The perceived need for sharing pages of
memory and the segmentation ideas we had seen in Multics
led to the design of the file-to-process mapping capabilities.
In the paging hardware,
this was supported by two types of page table entries,
"shared" and "indirect", in addition to the "private" type
that would contain a direct virtual-to-physical mapping.
These allowed the physical address of a shared page
to be kept in one place even though the page was used in many places,
including in the address space of processes that were swapped out.
The "indirect" pointer eventually allowed another capability
that we didn't initially foresee
--
the ability to make two or more process address spaces equivalent,
not only with regard to the data contained therein,
but with regard to the mapping as well*.
Multics に見られるメモリのページ共有とセグメンテーションの
必要性を認めるアイデアは
file-to-process マッピングの機能を設計に結び付きました。
ページングハードウェアでは、これは
直接の仮想−物理マッピングを意味する
"private"
に加えて、
"shared"
と
"indirect"
の２種類のページテーブルエントリによってサポートされます。
これらはスワップアウトされているプロセスのアドレス空間を含めて、
ページが多くの場所の中で使用されたとしても、
共有されるページの物理アドレスを１つの場所に維持されることを可能にしました。
また
"indirect"
ポインターは私たちが最初に予知しなかった別の能力
--
そこに含まれているデータだけでなくマッピングに関しても
２つ以上のプロセスのアドレス空間を同様に等価にする能力
も可能にしました
[* -
This allows, for example, a Unix-type "fork" operation to
create the child address space very cheaply
whether or not it is later replaced by an EXEC.
例えばこれは
後に EXEC によって置き換えられるか否かに関わらず、
大変安く子プロセスのアドレス空間を生成する
Unix の "fork" 操作のようなことを可能にします。
]
In software,
we wanted to achieve some of the benefits of Multics "segmentation",
but the PDP-10 address space wasn't large enough
to use the Multics approach directly.
Consequently,
we decided to extend the idea of named memory down
to the page level and to allow mapping
to be done on a page-by-page basis.
The result of this was
the fundamental design of the TENEX/TOPS-20 virtual memory architecture,
specifically:
ソフトウェアでは、私たちは、Multics「区分化」の利点のうちのいくつかを達成したかったが、PDP-10アドレス空間が十分に大きくなかったので、Multicsアプローチを直接使用しました。従って、私たちは、その考えを拡張することを決定しました、ページ・レベルまでメモリと命名された、また写像がページごとの基礎上で終わることを可能にすることこの結果はそうでした。特にTENEX/TOPS-20仮想記憶アーキテクチャーの基本のデザイン:
We knew that most sharing would be of read-only data, especially of
program text and constant data, but that any program might contain
initialized variables which would eventually be written. Beyond that,
almost any normally read-only data might be modified under some
circumstances, e.g. insertion of a break point for debugging. In the
LISP system, vast amounts of program were represented as LISP structures,
and these structures could be edited and modified by the user.
私たちは、ほとんどの共有が特にプログラム・テキストおよび一定のデータに、読み出し専用のデータであるが、どんなプログラムも、結局書かれる初期化された変数を含んでいるかもしれない、と知っていました。それを越えて、ほとんどどんな通常読み出し専用のデータも、いくつかの状況(例えばデバッギングのためのブレークポイントの挿入)の下で修正されるかもしれません。リスプ・システムでは、莫大な量のプログラムがリスプ構造として表わされ、ユーザによってこれらの構造を編集し、修正することができるかもしれません。
Hence, it wasn't acceptable to enforce read-only references on the bulk of
this storage, nor would it be efficient to copy it each time a process used
or referenced it. That would defeat much of the sharing objective. The
solution we devised was the "copy-on-write" page. This meant that the page
would remain shared so long as only read or execute references were made to
it, but if a process tried to write it, a copy would be made and the
process map adjusted to contain the copy. This would happen transparently
to the process. True read-only enforcement was available of course,
and the actual file contents (e.g. of a system program executable file)
were appropriately protected against modification, but the user could
map any such pages copy-on-write, and a write reference would then merely
result in a modified copy being used.
従って、この記憶装置の大部分に読み出し専用の参照を強いることは受理可能ではありませんでした。また、それもプロセスがそれを使用するか参照を付けたごとに、それをコピーするのには効率的ではないでしょう。それは、共有目的の多くを破るでしょう。私たちが考案した解決は「書き込みの上のコピー」ページでした。これは、ページが共有され続けるだろうということを意味しました、限り、参照を単に読むか実行する、それに作られた、しかし、もしプロセスがそれを書こうとすれば、コピーは作られるでしょう、またコピーを含むために調整されたプロセス地図。これは、プロセスに透明に起こるでしょう。真実の読み出し専用の施行はもちろん利用可能でした。また、実際のファイル内容(例えばシステム・プログラム実行可能なファイルの)は、修正から適切に保護されました。しかし、ユーザは、書き込みの上のどんなそのようなページ・コピーも写像することができました。また、書き込み参照は次に単に使用されている修正済のコピーに帰着するでしょう。
Multics may be said to have contributed more than just the ideas for
virtual memory organization and other specific capabilities. During
the design of TENEX, we invited some of the Multics designers and
implementors to review our progress and decisions. As is often the
case, we had fallen into the trap of trying to do too much in a number
of areas and had produced some designs that were quite convoluted and
complex. Several people from Multics beat
us up on those occasions, saying "this is too complicated -- simplify it!
Throw this out! Get rid of that!" We took much of that advice (and
could probably have taken more), and I credit these reviews with making
the core capabilities significantly easier to understand and program,
as well as to implement and debug.
Multicsは、仮想記憶構成および他の特定の能力に単なる考えを越えるものをと言われているかもしれません。TENEXのデザイン中に、私たちは、進行および決定を調査することをデザイナーおよびimplementorsのうちのいくつかに依頼しました。よくあることだが、私たちは、多くのエリアであまりに行おうとするわなに陥り、全く巻き込まれ複雑だったいくつかの設計を生産しました。Multicsからの数人の人々は「また複雑になります--それを単純化します!」と言って、それらの場合上で私たちを殴りつけます。これを投げてください!それを取り除いてください!」私たちは、その助言(そして恐らくより多くにとったことができた)の多くをとりました。また、私は中核能力をインプリメントするおよびデバッグすることと同様に理解しプログラムするのに著しくより容易にすることをこれらの調査のためであるとします。
This was one of the earliest occasions when I really began to appreciate
the fact that a complex, complicated design for some facility in a software
or hardware product is usually not an indication of great skill and
maturity on the part of the designer. Rather, it is typically evidence of
lack of maturity, lack of insight, lack of understanding of the costs of
complexity, and failure to see the problem in its larger context.
私がソフトウェアまたはハードウェアの製品中のある設備の複雑な複雑になった設計が、通常デザイナーの側の大きな技術および成熟の表示ではないという事実を実際に評価し始めた時、これは最も初期の場合のうちの1つでした。もっと正確に言えば、それは典型的に成熟の不足、洞察の不足、複雑さのコストについての理解の不足およびそのより大きな情況でその問題を見ることの失敗??ｦす証拠です。
The time from when the first word of TENEX code was written to
when the system was up and serving regular users was about six months
-- remarkable even for that era. The system was far from complete
at that point, but BBN internal users were making effective use of it.
時間、から、TENEXコードの第1の単語が、システムがいつ立上がっていたか、貢献していたかに、書かれた時、規則的なユーザ、約6か月(その時代によってさえ目立つ)でした。システムはその時点で全く完全ではありませんでした。しかし、BBN内部ユーザはそれを有効に利用していました。
One of the things that contributed to such speedy development was our
concern for debugging support. DDT was the standard symbolic debugger
on the PDP-10, and it had been evolved from predecessor
versions on the PDP-6, PDP-1, and TX-0 (an experimental machine at MIT
that preceded the PDP-1). DDT had a lot of power for its time, and
even today remains the choice of some experienced users despite the
availability of screen- and window-oriented debugging systems. DDT
ran in both exec (kernel) mode and user mode under TOPS-10, and we
supported both on TENEX as well.
そのような迅速な開発に寄与したもののうちの1つは、支援のデバッグに対する私たちの懸念でした。DDTはPDP-10の上の標準のシンボリック・デバッガーでした。また、それはPDP-6、PDP-1、およびTX-0(PDP-1に先行したMITの実験機械)の上の前任者バージョンから発展しました。DDTは、その時の多くの力を持っており、スクリーンかつウィンドウ指向のデバッギング・システムの有効性にもかかわらず今日さえ何人かの経験を積んだユーザの選択のままです。DDTは、TOPS-10の下の幹部(核)モードおよびユーザー・モードの両方で走りました。また、私たちはTENEXの上で同様に両方を支援しました。
In addition, we provided a way for DDT to run under timesharing while
looking at the system code and data structures. This allowed several
developers to be debugging system code at the same time, at least to a
limited extent. Even breakpoints could be handled, provided that no other
process would execute the code while the breakpoint was in place. In all
modes, DDT had the full set of symbols available to it, so we were able to
debug without constant referral to listings and typing of numeric values.
さらに、私たちは、DDTが、システム・コードおよびデータ構造を見る間にタイム・シェアリングの下で走る方法を提供しました。これは、数人の開発者が同時にデバッギング・システム・コードであることを少なくとも制限のある程度まで可能にしました。もしブレークポイントが適所にあった間に、他のプロセスがコードを実行しなかったならば、ブレークポイントさえ扱うことができるかもしれません。すべてのモードにおいて、DDTは、シン?{ルの十分なセットをそれに利用可能にしておきました、したがって、私たちはリストへの一定の紹介された人なしでデバッグすることができ、数値の値にタイプしていました。
In user mode, DDT could be added to any program even if it were already
running. Previous systems required that debugging be anticipated by
linking the debugger with the program. In TENEX, DDT was merely mapped
when needed at a high unused address in the address space well out of the
way of most programs. An even more powerful version of DDT, called IDDT
(for invisible) ran in a separate process from the program being debugged.
Thus, it was impervious to memory corruption by the program under test, and
it could intercept any and all illegal actions. Unfortunately, this
version of DDT diverged from the mainstream DEC DDT, and IDDT was never
brought up to date and made the normal debugger, even under TOPS-20.
Nonetheless, the easy and extensive use of DDT surely made development more
effective, both for user and system programmers.
ユーザー・モードでは、それが既に走っていたとしても、任意のプログラムにDDTを加えることができるかもしれません。前のシステムは、デバッガをプログラムとリンクすることにより、デバッギングが予想されることを必要としました。TENEXでは、ほとんどのプログラムによく特異なアドレス空間中の高い未使用のアドレスで必要だった時、DDTは単に写像されました。DDTのさらに強力なバージョン、IDDT(のための、目に見えない)と呼ばれた、デバッグされているプログラムからの個別のプロセスで走りました。したがって、それは、テストの下のプログラムによるメモリ腐敗を通しませんでした。また、それは全ての不法なアクションを遮ることができました。不運にも、DDTのこのバージョンは主流DEC DDTおよびIDDTから分岐しました、もたらされなかった、最新、またTOPS-20の下でさえ、正常なデバッガを作りました。ユーザおよびシステム・プログラマの両方のために有効な確実にもっと開発になったDDTの容易で広範囲な使用。
Another area where TENEX, and later TOPS-20, excelled was in the
user interface, described in detail below. A key reason that we were
able to extend the user interface so significantly is that the code which
implemented it ran an an ordinary user program. Hence, it wasn't
constrained by size or limited by functions which could not be performed in
kernel mode. Beyond that, debugging it was much simpler -- it didn't
require stand-alone use of the machine as did kernel debugging. All of this
allowed a great deal of experimentation and evolution
based on tuning and feedback from real use and real users.
別のエリア、どこで、TENEX、そして後のTOPS-20、凌がれた、詳細に下に記述されたユーザ・インターフェースにありました。私たちがユーザ・インターフェースを非常に著しく拡張することができたという重要な理由は、それをインプリメントしたコードが走ったということです、1つの、通常のユーザ・プログラム。従って、それはサイズによって抑制されず、核モードで実行することができなかった機能によって制限されていませんでした。それを越えて、それのデバッグははるかに単純でした--カーネル・デバッギングが行ったように、それは、マシンのスタンド・アロンの使用を必要としませんでした。これはすべて、実際の使用および実際のユーザからのチューニングおよびフィードバックに基づいた多くの実験、および発展を許可しました。
A piece of system design "philosophy" had emerged at BBN and among
some of the ARPA research sites that was to have a large impact on the
overall feel of TENEX and, ultimately, TOPS-20. At the time, we called
this "human engineering" -- we wanted the system to be easy to learn
and easy to use, and we wanted the system to take care of as many
grungy details as possible so that the programmer or user did not have
to deal with them. Beyond that, we were willing to spend real machine
cycles and real (or at least virtual) memory to make this happen.
1個のシステムデザイン「哲学」はBBNで、およびARPAのうちのいくらかの間で出現しました、サイトを研究する、それは全面的なものに大規模な影響を及ぼすことだった、TENEXおよび結局TOPS-20に触れます。その時に、私たちはこの「人間工学」を呼びました--私たちは、システムが容易なおよび使用することが容易でことを望みました。また、私たちは、プログラマかユーザがそれらに対処する必要がなかったように、システムができるだけ多くのまずい詳細を世話することを望みました?Bそれを越えて、私たちは、喜んでこれを起こらせる実際のマシン・サイクルおよび実際の(あるいは少なくとも仮想の)メモリを過ごしました。
This philosophy led initially to the human interface features of the
EXEC, including "escape recognition", the question-mark help facility,
optional subcommands, and "noise" words. Few people now argue against
the need to provide effective human interfaces, but at that time there
were many detractors who felt that it was a waste of cycles to do such
things as command recognition. These kinds of things, they said,
would "slow the system down" and prevent "useful work" from getting
done. Other contemporary systems used short, often one-letter,
commands and command arguments, provided no on-line help, and did not
give any response to the user other than the "answer" (if any) to the
command that had been entered.
この哲学は、「回避認識」を含むEXEC、疑問符支援設備、オプションのsubcommandsおよび「雑音」言葉のヒューマン・インターフェース特徴に最初に結びつきました。ほとんどの人々は、今有効なヒューマン・インターフェースを提供する必要に反対しません。しかし、その時に、コマンド認識のような物事を行うことがサイクルの浪費で???a思った多くの悪口をいう人がいました。これらの種のものが「システムを遅くし」、その種が、「有用な仕事」が行われるのを防ぐだろう、と彼らは、言いました。他の同時代のシステムは短くて、使用しました、しばしば1-文字、コマンドおよびコマンド引き数、オン・ライン支援を提供せず、入力されたコマンドに対する「答え」(もしあれば)以外にユーザにレスポンスをしなかった。
Many such systems fell into the "by experts, for experts" category.
That is, they were built by experts and intended to be used by other
experts. An "expert" would obviously not need frivolous features like
noise words or command recognition. Experts would know, not only all
the commands, but all the legal abbreviations as well. Experts may
have read the manual once, but would always remember everything
needed to interact with the system. So went the implicit assumptions
about users -- either you were an expert, or you were an inferior
being not really entitled to use the Computer anyway.
多くのそのようなシステムが落ちました、へ、その「エキスパートのために、エキスパートによって」カテゴリー?Bすなわち、それらはエキスパートによって構築され、他のエキスパートによって使用されるつもりでした。「エキスパート」は、明白に雑音言葉かコマンド認識のような軽薄な特徴を必要としようとしませんでした。エキスパートは知るでしょう、すべてのコマンドだけでなくすべての法的な略語も、同様に。エキスパートはマニュアルを以前読んだかもしれないが、すべてがシステムと対話する必要があった?ｱとを常に思い出すでしょう。したがって、行った、ユーザに関する暗黙の仮定――元あったどちらか、1つの、エキスパート、あるいは、あなたはコンピューターをとにかく使用する実際に資格がない目下の者でした。
The TENEX team took a different view. It was clear that the power of
computers was increasing every year and so one should expect the
computer to do more and more interesting things. Most people would
agree that a major purpose of computer automation is to relieve people
of boring, repetitive tasks; we believed that purpose extended to
computer system development as well, and that it was wrong to require
a person to learn some new set of boring, arcane tasks in order to use
the computer. The machine should adapt to man, not man to the
machine.
TENEXチームは異なる視界をとりました。コンピューターの力が毎年増加していたことは明らかでした。したがって、人は、コンピューターがますます面白い物事を行うことを予期するべきです。ほとんどの人々は、コンピューター・オートメーションの主な目的がボーリング、反復のタスクを人々から取り除くことであることに合意するでしょう;私たちは、目的がコンピューター・システム開発まで同様に及び、コンピューターを使用するために退屈な不可解なタスクのある新しいセットを学習することを人に要求することが悪かった、と信じました。機械は機械への人ではなく人に適合するべきです。
The view was probably reinforced by the artificial intelligence
research being done in the environment where TENEX was designed. In
such areas as speech recognition, pattern recognition, and natural
language comprehension, massive computation power was being applied to
make computers interact in ways that would be more human. These were
long-term efforts, but we wanted our computer systems to be more
human-oriented in the sort term as well.
視界は、TENEXが設計された環境の中で行われている人工知能研究によって恐らく強化されま?ｵた。音声認識、パターン認識および自然言??a自然言語のようなエリアでは、重い計算力がより人間の方法でコンピューターを対話させるために印加されていました。これらは長期的な努力でした。しかし、私たちは、コンピューター・システムがソート用語にもっと同様に人間適応させられることを望みました。
One of the ideas to come out of the AI research was that the computer
should "do what I mean", even if I didn't say it quite right or maybe made
a spelling error. Warren Teitelman implemented extensive capabilities in
LISP to correct errors automatically or with minor user intervention, and
this came to be called the DWIM package. With this kind of research effort
going on, we were sensitive to the restrictions and obtuseness of most
existing systems.
AI研究から出て来る考えのうちの1つは、私がそれを言わなかったとしても、コンピューターが「私が言いたいことを行うべき」ということでした、全く正しい、あるいは恐らく綴る間違いをしました。ウォレンTeitelmanは、エラーを自動的にあるいは小さなユーザ介在で修正するリスプ中の広範囲な能力をインプリメントしました。また、これはDWIMパッケージと呼ばれるために来ました。進んでいるこの種の研究努力で、私たちは、ほとんどの既存のシステムの制限および鈍さに敏感でした。
Hence, we took (now obvious) decisions like, (1) identifying users by
alphanumeric name rather than number; (2) allowing file names to be long
enough to represent meaningful (to the human) information; (3) typing
or displaying positive confirmation of actions requested by the user;
(4) allowing for a range of individual preferences among users in
regard to style of command input and output.
従って、私たちは決定をとりました(今明白)のように、数ではなく英?博嘯ﾌ名前によって(1)ユーザを識別すること(2)ファイル名が十分に長い(意味のある(人間に)情報を表わすように)ことを可能にすること;(3) ユーザによって要求されたアクションの積極的確認のタイプか表示;(4)コマンド入力および出力のスタイルに関するユーザの内の一連の個々の選択を考慮に入れること。
We specifically looked for ways of interaction that would seem natural
when judged in a human-to-human perspective. On that basis, many
typical computer interface behaviours are quite unfriendly. Terse,
cryptic, and/or abrupt responses; inflexible and obscure input syntax;
use of words for meanings that are counter-intuitive -- these things
are all judged as rude or worse if seen in a human-to-human
interaction.
私たちは、特に、人間対人間の展望で判断された時自然に見える相互作用の方法を捜しました。その根拠で、多くの典型的なコンピューター・インターフェース振る舞いが全く冷淡です。簡潔、隠れてかつ、または急な、レスポンス;柔軟性がなく不明瞭な入力シンタックス;直観に反した意味のための言葉の使用--もし人間対人間の相互作用で見られれば、これらのものはすべて無作法なまたはより悪いとして判断されます。
This desire to make the computer do the grunge work motivated design in
areas other as well. Demand paging and virtual memory were seen as ways to
reduce the burden and difficulty of writing large programs. With a large
virtual memory, the programmer would not have to be concerned with
segmenting and overlaying his program. Rather, he could leave memory
management to the system and concentrate on the particulars of the task at
hand. Other features such as process structure, system utility calls, and
standardized file parsing were intended to ease the job of system
programming by providing standard, powerful functions to the programmer.
コンピューターにまずいもの仕事を行わせるこの望みは、エリアの設計を動機づけました、他のもの、同様に。要求時ページングと仮想記憶は、大規模なプログラムを書く負担および困難を減らす方法と見なされていました。大きな仮想記憶で、プログラマは、彼のプログラムを分けて覆うことによく関係があります必要があった。もっと正確に言えば、彼はシステムにメモリ管理を残すことができ、タスクの詳細に近づいて専念することができました。プロセス構造、システム・ユーティリィティ呼び出しおよび標準化されたファイル解析のような他の特徴は、プログラマに標準で強力な機能を供給することによりシステム・プログラミングのジョブを緩和するように意図されました。
One of the most favored features among TOPS-20 users, and one most
identified with TOPS-20 itself, is "escape recognition". With this, the
user can often get the system to, in effect, type most of a command or
symbolic name. The feature is more easily used than described;
nonetheless, a brief description follows to aid in understanding the
development of it.
TOPS-20ユーザの間の最も恵まれた特徴のうちの1つおよび1つは、最もTOPS-20自体を一体視しました、「回避認識」です。これで、ユーザはしばしばシステムを得ることができます、に、効力の中で、ほとんどのコマンドか記号名前をタイプします。記述されたより、特徴はより容易に使用されます;それにもかかわらず、簡潔な記述はその開発を理解することを援助するために続きます。
Typing the escape key says to the system, "if you know what I mean from
what I've typed up to this point, type whatever comes next just as if I had
typed it". What is displayed on the screen or typescript looks just as if
the user typed it, but of course, the system types it much faster. For
example, if the user types DIR and escape, the system will continue the
line to make it read DIRECTORY.
回避キーのタイプ「私がこのポイントまでタイプしたものから私が何を言いたいか知っている場合は、あたかもちょうど私がそれをタイプしたかのように次に来るものすべてをタイプしてください」とシステムに言います。あたかもちょうどユーザがそれをタイプするかのように、スクリーンかタイプ原稿に表示されるものは見ます。しかし、もちろん、システムはそれをはるかに速くタイプします。例えば、ユーザがDIRと回避をタイプすれば、システムはラインを読まれたDIRECTORYに(それ)し続けるでしょう。
TOPS-20 also accepts just the abbreviation DIR (without escape), and
the expert user who wants to enter the command in abbreviated form can
do so without delay. For the novice user, typing escape serves several
purposes:
TOPS-20はさらに単なる省略DIR(回避のない)を受理します。また、略した形式にコマンドを入力したい、エキスパートのユーザはをそのように必要としません。初心者ユーザのために、回避のタイプはいくつかの目的に役立ちます:
DIRECTORY (OF FILE)
This prompts the user that files are being dealt with in this command, and
that a file may be given as the next input. In a command with several
parameters, this kind of interaction may take place several times. It has
been clearly shown in this and other environments that frequent interaction
and feedback such as this is of great benefit in giving the user confidence
that he is going down the right path and that the computer is not waiting
to spring some terrible trap if he says something wrong. While it may take
somewhat longer to enter a command this way than if it were entered by an
expert using the shortest abbreviations, that cost is small compared to
the penalty of entering a wrong command. A wrong command means at least
that the time spent typing the command line has been wasted. If it results
in some erroneous action (as opposed to no action) being taken, the cost
may be much greater.
これは、ファイルがこのコマンドの中で入力と分配されており、ファイルが次の入力として与えられるかもしれないユーザを刺激します。いくつかのパラメーターを備えたコマンドでは、この種の相互作用が数回起こるかもしれません。それは、相互作用に通うこれおよび他の環境の中で明白に示されました。また、このようなフィードバックは彼が正しいパスを下って行き、コンピューターが、彼が間違っているものを言えばある恐ろしいわなを跳ね返らせるのを待っていないというユーザ確信を与える際に大きな利益であります。コマンドを入力するのに多少より長くかかっているかもしれない一方、間違っているコマンドを入力する罰と比較して、最短の略語を使用して、それがエキスパートによって入力された場合より方法(それはコストがかかる)は小さい。間違っているコマンドは、コマンドラインをタイプして費やされた時間が浪費されたことを少なくとも意味します。それが、得られているある誤ったアクション(アクションがないことに対立するものとしての)に帰着する場合、コストははるかに大きいかもしれません。
This is a key underlying reason that the TOPS-20 interface is perceived
as friendly: it significantly reduces the number of large negative feedback
events which occur to the user, and instead provides many more small
but positive (i.e. successful) interactions. This positive reinforcement
would be considered quite obvious if viewed in human-to-human interaction
terms, but through most of the history of computers, we have ignored
the need of the human user to have the computer be a positive and
encouraging member of the dialog.
これは親しみのあるものとして、TOPS-20インターフェースが知覚されるというキーの根本的な理由です:それは、ユーザに思い浮かぶ大規模なネガティブ・フィードバック出来事の数を著しく縮小し、その代り、さらに多くの小さいが、肯定的である(つまり、成功する)相互作用を提供します。もし人間対人間の相互作用用語に見られれば、この肯定的な補強は、全く明白であると考えられるでしょう。しかし、コンピ??[ターのほとんどの歴史を通じて、私たちは、コンピューターに対話の肯定的で有望なメンバーにさせる人間のユーザの必要を無視しました。
Typing escape is only a request. If your input so far is ambiguous,
the system merely signals (with a bell or beep) and waits again for
more input. Also, the escape recognition is available for symbolic
names (e.g. files) as well as command verbs. This means that a user
may use long, descriptive file names in order to help keep track of
what the files contain, yet not have to type these long names on every
reference. For example, if my directory contains:
回避のタイプはリクエストだけです。ここまでのあなたの入力が曖昧な場合、システムは再びより多くの入力を求めて単に合図し待ちます(ベルか信号音で)。さらに、回避認識は、コマンド動詞にも記号名前(例えばファイル)にも利用可能です。これは、ユーザがフ?@イルが含んでいるものの跡をまだ追うことを支援するために長く記述的なファイル名を使用してもよいことを意味します、ない、すべての参照上にこれらの長い名前をタイプしなければならないこと例えば、私のディレクトリーが次のものを含んでいる場合:
BIG_PROGRAM_FILE_SOURCE VERY_LONG_MANUAL_TEXT
I need only type B or V to unambiguously identify one of those files.
Typing extra letters before the escape doesn't hurt, so I don't have
to think about the minimum abbreviation; I can type VER
私は、明白にそれらのファイルのうちの1つを識別するためにBまたはVを単にタイプする必要があります。回避の前に余分な文字をタイプすることは痛みません。したがって、私は最小の省略に関して考える必要がありません;私はVER
Finally, if the user still isn't sure what input comes next in a command,
he types question-mark, and the system will provide a list of choices
that are legal at that point. The list includes specific keywords (e.g.
FILE, DIRECTORY) and generic descriptions (e.g. "input file")
Most importantly, the question-mark request does not destroy
the previous command input. After the list of alternatives is displayed,
the partial command is redisplayed, and input continues from the point
just before where the user typed question mark.
最後に、どの入力がコマンドの中で次に起こるかユーザがまだ確信しなければ、彼は疑問符をタイプします。また、システムは、その時点で有効な選択のリストを提供するでしょう。リストは特定のキーワード(例えばFILE、DIRECTORY)および総括的な記述(例?ｦば「入力ファイル」)を含んでいます。重要なことには、疑問符リクエストは前のコマンド入力を破壊しません。代案のリストが表示された後、部分的なコマンドは再表示されます、また、入力はポイントから継続します、の前に(ちょうど)ユーザが疑問符をタイプしたところで。
As a result of this feature:
この特徴の結果:
As menu-oriented interfaces have become more widely used, the advantage
of having all choices visible to the user has become obvious. The
question-mark help feature can, in retrospect, be seen as a "menu on
demand" kind of approach, and it was one that worked even on terminals
too slow to support full menu-based interfaces.
より広く使用されて、メニュー指向のインターフェースがなったように、選択をすべてユーザに見えるようにしておくという利点は明白になりました。疑問符、特徴を支援する、1「メニュー・オンデマンド」種のアプローチと見なすことができる(考慮の中で)、また、十分なメニューに基づいたインターフェースを支援す??a支援遅すぎるターミナルにさえ作用したのは一つでした。
The Berkeley Timesharing system for the SDS-940 had an earlier form of
recognition. It didn't use escape however. On that system, recognition
was automatic; whenever the user had typed enough to unambigiously identify
a command or symbolic name, the system would spring to life and type the
rest of it. This made for the minimum keystrokes in the ideal case, but
had one major, and ultimately fatal, problem: if the user typed too much in
one field, i.e. more than the amount necessary for the system to recognize
that field, the input would go into the next field where it wasn't
intended. For example, the system would recognize COP as sufficient for
COPY and supply the "Y". But if you typed the whole verb, you would get:
SDS-940のためのザ・バークリー・タイムシェアリング・システムは、認識の初期の形式を持っていました。しかしながら、それは回避を使用しませんでした。そのシステムにおいては、認識が自動的でした;ユーザがunambigiouslyにコマンドか記号名前を識別するために十分にタイプした場合は常に、システムは急に活気を見せて、その残りをタイプするでしょう。これは理想的場合に最小のキーストロークに向かったが、1つを主で、結局致命的にしておきました、問題:もしユーザが、1つの分野(つまりシステムがそのフィールドを認識するのに必要な量を越えるもの)であまりにタイプすれば、入力はそれが意図されなかった次のフィールドに入るでしょう。例えば、COPYに十分なものとして、システムはCOPを認識し、「Y」を供給するでしょう。しかし、もし全体の動詞をタイプすれば、得るでしょう:
* COPY Y | |- typed by the computer
Then, you would at least have to erase the extra "Y". If you didn't
notice what happened and continued to type the remainder of the command,
what you had intended as:
その後、少なくとも余分の物「Y」を削除しなければならないでしょう。何が起こるか、コマンドの残りをタイプし続けたかあなたが気づかなかったならば、あなたが持っていたものは次のように意図しました:
* COPY OLDFIL NEWFIL
would come out as
* COPY Y OLDFIL NEWFIL
This would at least produce an error, and in pathological cases could
do major damage. [In the foregoing example, note that the old file
name winds up in the new file parameter field.]
これは少なくともエラーを生産し、病理学の場合に少佐損害を行うことができました。先の例において、[新しいファイル・パラメーター分野に古いファイル名が行き着くことに注意してください]。
With experience, users would come to know the abbreviations for the
reserved words and so would rarely fall into the trap of this example.
However, this automatic recognition also worked on files in file
directories, and there, the minimum abbreviation could change from minute
to minute as files were added and deleted. Hence, even an experienced
user would have to type carefully. Interestingly, this system favored
slow typists who benefitted from having to type the minimum amount of
input, but it was a source of maddening frustration to fast typists
who would often outrun the system. And when the system became loaded
and response decreased, it was a disaster for everybody.
経験で、ユーザは予約の単語のための略語を知るようによくなり、したがって、この例のわなにめったに陥りません。しかしながら、この自動認識は、さらにファイル・ディレクトリー中のファイルに作用しました、また、そこで、ファイルが加えられ削除されたとともに、最小の省略は分から分に変わることができました。従って、経験を積んだユーザさえよく注意深くタイプしなければならなかった。面白く、このシステムは、最小の量の入力をタイプしなければならないことから利益を得た、遅いタイピストに賛成しました。しかし、システムをしばしば超過するだろうのは速いタイピストへの発狂するフラストレーションの源でした。また、システムがロードされるようになり、レスポンスが減少した時、それは皆にとって災難でした。
This experience convinced us that we didn't want to perpetuate automatic
recognition in that form in TENEX. We spent a lot of time thinking about
ways that the "overtyping" problem might be solved, including rules like
"if there is extra input and it matches the last keyword after the point of
recognition, apply it to that", etc., but ultimately could find no method
that didn't leave open a large class of time-dependent errors. We
considered a mode which would enable or disable automatic recognition, but
decided that would not make the feature any more usable.
この経験は、私たちがTENEXの中のその形式で自動認識を永続させたくないと私たちに確信させました。私たちは、「過剰タイプする」問題が解決されるかもしれない方法に関する多くの時間思考を費やしました、規則を含んでいること、のように「場合、そこに、入力されて、余分である、また、それは認識のポイントの後に最後のキーワードと一致します、それにそれを適用する。」など、しかし去らなかった方法を結局見つけることができなかった、開いている、時間依存のエラーの大規模なクラス。私たちは、自動認識を可能にするか不能にするだろうが、それを決定したモードを考慮しました、特徴をもっとどれにしないだろう、使用可能。
Hence, we decided to make recognition happen only on explicit request, even
though an extra keystroke would be required. We selected the escape key for
this purpose.
従って、私たちは、たとえ余分なキーストロークが要求されても、認識を明示的なリクエストでのみ起こらせることを決定しました。私たちはこの目的に回避キーを選びました。
In general, it became our objective to avoid modes. We believed that
defining "expert", "novice", etc. modes would be to ignore the fact that
one person can be both novice and expert at the same time, and may have
preferences that don't fit either definition. Even an experienced user is
likely to be unfamiliar (and therefore a "novice") with some parts of the
system, some commands, etc., and would want the additional prompting when
working in those areas. Over time, we observed that some very experienced
users continue to use the prompting extensively because of the positive
feedback it provides.
一般に、それはモードを回避するために私たちの目的になりました。私たちは次のことを信じました、定義する「エキスパートの」、「初心者」など、モードは事実を無視することでしょう、それ、人は両方とも初心者でありえます、そしてエキスパート、同時に、また定義にどちらも適合しない優先権を持っているかもしれません。経験を積んだユーザさえ、システムのいくつかの部分、いくつかのコマンドなどに慣れていなく(したがって「初心者」)、それらのエリアで働く時補足に促すことを望むでしょう。時間とともに、私たちは、何人かの非常に経験を積んだユーザが使用し続け??a使用言いました、その、それが提供するポジティブ・フィードバックのために広範囲に促すこと
The circumstances under which TENEX moved to DEC and became TOPS20
seem in retrospect to have included a number of fortuitous events.
As noted above, by 1972,
TENEX had achieved a certain amount of popularity among researchers
on the ARPA Network.
The reborn 36-bit machine, newly christened the DECsystem-10
was enjoying reasonable success in a number of other markets as well.
The prestige of being the choice of leading edge researchers
was worth advertising though,
so DEC ran an ad in a number of trade publications headlined
"ARPA has a network of Supercomputers" and
pointing out what a large fraction of those were DECsystem-10s.
In fact, most of those were running TENEX.
By April, 1972, there were seven sites in addition to BBN running TENEX.
思い返せば、
TENEX が DEC に移り TOPS20 になった事情には
数々の偶発的な出来事が上げられるように見えます。
既に述べたように、1972 年には、
TENEX は ARPA ネットワークの研究者の間である程度の人気を獲得していました。
新たに DECsystem-10 と命名された、
生まれ変わった 36-Bit のマシンは
その他の多くのマーケットと同じように妥当な成功を謳歌していました。
最先端研究者が選択したという名声は広告する価値がありました。
したがって DEC は多くの業界紙誌に
「ARPA はスーパー・コンピューターのネットワークを持っている」という見出しと
それコンピュータ群の大部分が DECsystem-10 であることをを指摘した
広告を出しました。
実際、ほとんどのマシンで TENEX は稼働していました。
1972年4月の時点で BBN を含めると TENEX が稼働するサイトは７つのありました。
BBN had a modest business building the outboard paging hardware which, with
the technology of that day, required an entire tall 19-inch wide cabinet of
logic. DEC, meanwhile, had begun work on a successor machine to be known
as the KI10 (the "I" at least suggesting the integrated circuit technology
that was to be used). As early as June of 1970, meetings were held where
BBN people attempted to persuade DEC to include paging hardware similar to
the design of the BBN pager. Eventually, DEC decided to include paging in
the KI10, but it was based on a much simpler architecture. DEC engineers were
not convinced that the several forms of pointers (private, shared,
indirect) and the core status table would be worth the amount of hardware
required to support them. Nonetheless, they did choose the same page size,
512 words, which at least left open the door
to some sort of later accommodation.
BBN はその当時の技術では
背の高い１９インチ幅のキャビネット全部を必要とする
外部ページングハードウェアを組み立てるという
適度な仕事を持っていました。
一方、DEC は KI10
("I" は少なくとも集積回路技術が使用されていることを示唆しています)
として知られる後継マシンの開発を開始していました。
1970年6月初旬に、
ミーティングが開催され、
BBN の人間は BBN ページャの設計と同様の
ページングハードウェアを組み込むよう
DEC を説得することを試みました。
結局、DEC は KI10 にページング機能を含めるを決定しました。
しかし、それははるかに単純なアーキテクチャーに基づきました。
DEC のエンジニアはポインターの様々なフォーム
(プライベート、シェアード、間接)
やコアステータステーブルをサポートするために
必要なハードウェアの総量に見合うだけの価値があることを
確信していませんでした。
それにもかかわらず、
少なくとも、後の何かしらの融通への道を開く、
512 ワードの同じページ・サイズを選びました。
When the KI10 came out, DEC was disappointed (to say the least)
by the lack of interest among the research community which had helped spark
KA10 sales. The problem was that the machine would not run TENEX. It was
almost twice as fast as the KA10, but the paging was different from what
TENEX required. It was also quite evident that it would not be practical
to modify the structure of TENEX to use the more limited KI10 paging. As a
further irony, the version of TOPS-10 initially shipped with the KI10 used
the paging hardware only to simulate the protection and relocation hardware
of the KA10 and realized no benefit from it.
KI10が現われた時、DECは、スパークKA10販売を支援した研究コミュニティーに興味のある不足によって失望しました(最小が言うこと)。問題は、機械がTENEXを実行しないだろうということでした。それは、KA10よりほとんど2倍速かった。しかし、ページングは、TENEXが要?≠ｵたものとは異なっていました。さらに、もっと制限のあるKI10ページングを使用するTENEXの構造を修正することが実際的ではないだろうことは全く明白でした。一層の反語として、KI10で最初に送られたTOPS-10のバージョンは、KA10の保護および再配置ハードウェアを単にシミュレートするためにページをつけるハードウェアを使用し、それからの利益を実現しませんでした。
During the summer of 1972, I had decided to look for new opportunities
outside of BBN. Not surprisingly, one company I talked to was DEC. In
the course of those discussions, I was asked about the possibility of
putting TENEX on the KI10. This was not a desire that was widespread
within DEC in general or within DEC software engineering in particular, but
it was of great interest to Allan Titcomb who was the marketing manager
covering the scientific and research markets. Titcomb wanted very much to
sell some KI10's to the sites that were running TENEX.
1972の夏に、私は、BBNの外側の新たな機会を捜すことを決定しました。驚いたことではないが、私が話しかけた1つの会社はDECでした。それらの議論の間に、私は、KI10にTENEXを置く可能性について尋ねられました。これは一般にDECの内に、あるいは項目中のDECソフトウェア工学の内に広範囲だった要望ではありませんでした。しかし、それは、科学的な研究市場をカバーする販売責任者だったアランTitcombに大きく興味がありました。Titcombは、TENEXを実行していたサイトへあるKI10のを非常に売りたかった。
The outcome of this was that I went to work for DEC -- as a contractor. I
contracted with DEC for a fixed-time (3 months), fixed-price contract to make
TENEX run on the KI10[6]. Clearly, the DEC internal processes were not about
to create a real project around TENEX at this point, but a one-man 3-month
contract must have seemed an acceptably small risk.
この結果は、私がDECのための仕事に行ったということでした--契約者として。私は、TENEXをKI10[6]上で実行されたする定時(3か月)および固定価格契約用のDECで収縮しました。明白に、DEC内部プロセスは、この時点でTENEXのまわりの実際のプロジェクトを作成するところでありませんでした。しかし、ワンマン3か月契約は気に入られるように小さな危険に見えたに違いありません。
I also received an offer to join DEC as a regular employee after the
contract was finished. This permanent job was not initially intended to
have any continuing involvement with TENEX however. In fact, it was to
work in the TOPS-10 group.
さらに、私は、契約が終了された後正社員としてDECを連結する申し出を受け取りました。この永久の仕事は、しかしながら、TENEXを備えたどんな持続的な関与も持つようには最初に意図されませんでした。実際、それはTOPS-10グループで働くことでした。
The contract with me for KI-TENEX was negotiated through DEC's software
engineering department, led at the time by Dave Stone whom I knew
previously. During the latter part of the contract discussions, Dave asked
someone else in to consult on the technical aspects of my proposed method
for dealing with the different paging hardware on the KI10. This turned
out to be Peter Hurley, then doing special software engineering projects as
part of the marketing group headed by Allan Titcomb, and it marks the first
of Peter's long involvement with TOPS-20.
KI-TENEXのための私との契約はDECのソフトウェア工学部によって協定されました、ディヴ石によってその時にリードした、私はこの人を以前に知っていました。契約議論の後の部分中に、ディヴは、KI10の上の異なるページをつけるハードウェアに対処する、私の提案された方法の技術的な様相について相談してくれるように誰か他の人に中へ依頼しました。これは、ピーター・スティックであると判明しました、その後、アランTitcombによって率いられたマーケティング・グループの一部として特別のソフトウェア工学プロジェクトを行います。また、それは、ピーターの長い関与の1番めにTOPS-20で印をつけます。
So, as of the beginning of October, 1972, I took my leave from BBN and
settled into an office on 3-5 (building 3, floor 5) in DEC's original
buildings in Maynard. Being at the time still rather youthful in outlook,
the idea of a 3-month, fixed-price, one-man contract to port a base
operating system to a new processor in a family didn't strike me as
particularly scary.
したがって、1972年10月の始めの時点で、私はBBNから許可をとり、DECのメイナードのオリジナルの建物で3-5(3および床5を構築して)の上でオフィスに引っ越して落ち着きました。外観においてまだやや若い時にあって、私は、家族の中の新しいプロセッサーへの基礎オペレーティング・システムを運ぶ3か月、固定価格、ワンマンの?_約についての考えを特に臆病に思いませんでした。
As part of my send-off from BBN, a couple of co-workers who had previously
worked at DEC gave me some farewell presents that, I was assured, would
prove very useful at DEC: a flyswatter and a can of bug spray. DEC's
facilities at the time lacked some of the aseptic uniformity generally
expected of hi-tech offices and labs. Because of their age, history, and
proximity to a mill pond and stream, the buildings were well supplied with
various insect life and spiders, and my friends at BBN wanted to be sure I
knew what I was getting into. Ultimately, I spent only a little over a year
working in the Maynard mill buildings, but there were numerous occasions
late in the evening when the possibility of further concentration on code
was nil and I found myself watching at length as a particularly skillful
spider spun a nearly perfect circular web among the posts of my partition.
BBNからの私の壮行会の一部として、以前はDECに取り組んだ2、3人の同僚が私にいくつかの告別プレゼントを与えました、それ、私は保証されました、DECで非常に有用であると分かるだろう:蝿叩きおよび防虫スプレーの缶。DECのその時の設備は、先端技術のオフィスおよび実験室に一般に期待された無菌の等質のうちのいくらかを欠きました。それらの年齢、歴史、およびミル池および流れへの接近のために、建物に、様々な昆虫生活およびクモがよく供給されました。また、BBNの私の友達は、私が何に入っているか知っていると確信したかった。結局、私は、メイナード・ミル建物で働く年にわたってほんの少し費やしました。しかし、コード上の一層の集中の可能性が皆無で、私が、特に熟練したクモが私の分割としての地位中のほとんど完全な循環的なウェブを回したとともに、私自身が詳細に見ているのを見つけた夜に遅い多数の場合がありました。
The technique I had come up with did not involve major alterations in the
paging structure of TENEX in order to deal with the simpler pager of the
KI10. Rather, the idea was to simulate most of the logic of the BBN pager
in software and use a KI10 page table only as a software cache or
translation buffer for current virtual-to-physical page mappings.
Logically, this was much like the design used in many later
processors where the logic would be realized in microcode and the storage
in RAM.
私が追いついた技術は、KI10のより単純なページャーに対処するためにはTENEXのページをつける構造の主な変更を含んでいませんでした。もっと正確に言えば、目的は、ソフトウェア中のBBNページャーのほとんどのロジックをシミュレートし、現在の仮想のに物理的なページ写像のためにソフトウェア貯蔵所か翻訳バッファーとしてのみKI10ページ・テーブルを使用することでした。論理上、これは、ロジックがマイクロコード中で実現される場合に多くの後のプロセッサーの中で使用される設計、およびRAMの中の記憶装置に非常に似ていました。
Implementation of PDP-10 code to simulate the BBN pager was not a large or
difficult task and took probably less than half the time of the project.
In addition to paging, it was necessary to write drivers for the
file and swapping devices then being shipped by DEC, neither of which had
been used at BBN. Checkout of TENEX on the KI10 did, however, encounter
one new and rather obscure logic error in the paging hardware.
BBNページャーをシミュレートするPDP-10コードのインプリメンテーションは大規模か困難なタスクでなく、プロジェクトのその時間の半分未満で恐らくとりました。ページングに加えて、DEC(そのどちらはBBNで使用されていなかった)によって送られることは、ファイルのための書き込みドライバーおよび交換する装置にそのとき必要でした。しかしながら、KI10の上のTENEXのチェックアウトは、ページをつけるハードウェアにおける1つの新しく、やや不明瞭なロジック・エラーに遭遇しました。
Well before the end of the three month contract period, TENEX was running
well enough on the KI10 to support building new versions of itself.
During this period, the system was up and running for several hours
each day on a machine in the basement of the mill, and a few curious
employees came around to try it. One such person was Dave Braithwaite,
then in the -10 benchmark group, who brought over various benchmarks
and tests to try.
よく、3か月の契約期間の終了の前に、構築する新バージョンを自然に支援するために、TENEXは、KI10の上で十分によく走っていました。この期間に、システムは、ミルの地下室の機械上に数時間毎日活動中でした。また、数人の奇妙な従業員がそれを試みるためにやって来きました。そのような1人は、-10のベンチマーク・グループ(この人は様々なベンチマーク上にもたらし、試みるためにテストする)の中にその後ディヴBraithwaiteでした。
The contract nominally ended (successfully) when I delivered an official
set of tapes containing the TENEX sources and a bootable system at the
contractually appointed time. This was somewhat academic at that point
however, since it was not by any means the end of TENEX related activity at
DEC.
私が契約上約束の時間にTENEX出所を含んでいるテープの公式セットおよびけとばすことができるシステムを伝えた時、契約は名目上終了しました(成功裡に)。しかしながら、それがいかなる手段でもDECのTENEXに関連する活動の終了ではなかったので、これはその時点で多少学術的でした。
During the time I was working on KI-TENEX, the KL10 processor was under
active development in hardware engineering. The "L" in KL10 was originally
intended to mean "low cost", since the KI10 was perceived as being somewhat
expensive. However, technology was providing opportunities to make a
significant jump in performance, and that ultimately was to be the salient
feature of the KL10. The product line managers were seeing opportunities
to grow in the high end, so the stage was set to consider some major
changes in capabilities.
私がKI-TENEXを処理していた間、KL10プロセッサーがハードウェア工学中の活発な開発中にありました。KI10が多少高価なこととして知覚されたので、KL10の中の「L」は「低コスト」を意味するようにもとは意図されました。しかしながら、技術は、実行で重要な跳躍をする機会を提供していました。また、それは結局KL10の顕著な特徴であることでした。生産ラインマネージャーは、高額のものの中で成長する機会を?ｩていました。したがって、お膳立ては能力中のいくつかの大変化を考慮するためにされました。
Around this same time, the "Super Foonly" project was in progress in the AI
lab at Stanford. The Foonly designers were projecting a factor
of 10 speedup over the KA10, and DEC engineers were invited out to
review these plans. Certain ideas, such as the E-box and M-box functional
split, were instrumental in the ultimate design of the KL10.
この同じ時のまわりで、「最高のFoonly」プロジェクトはスタンフォードのAI実験室の進行中でした。Foonlyデザイナーは、KA10の上の10のスピードアップの要因を計画していました。また、DECエンジニアは、これらの計画を調査することを依頼されました。E-箱およびM-箱の機能的な分裂のようなある考えは、KL10の最終のデザインにおいて助けになりました。
Stanford wasn't the only other place where a PDP-10 architecture machine
was being designed and built. The newly opened Xerox PARC (Palo Alto
Research Center) included a number of people from BBN and other sites
familiar with TENEX, and they were quite interested in pursuing their work
on that system. Since Xerox was then in the computer business, PARC
couldn't quite manage to just buy a PDP-10 from DEC. Consequently, they
built their own. It was a single-processor machine compatible with the
KA10 and BBN paging and was designed and built in a relatively short time.
It ran TENEX for a number of years.
スタンフォードはPDP-10アーキテクチャー機械が設計されており構築されていた、別の唯一の場所ではありませんでした。新しく開かれたゼロックスPARC(パロアルト研究センター)は、BBN、およびTENEXに精通している他のサイトからの多くの人々を含みました。また、それらはそのシステムのそれらの研究の追求に全く興味を持っていました。ゼロックスがそのときコンピューターの仕事をしていたので、PARCはどうにかDECから全くちょうどPDP-10を買うことができませんでした。従って、それらは彼らのものを構築しました。それはKA10およびBBNページングと互換性をもつ単一のプロセッサーの機械で、設計され、構築されました、1つの、比較的操業短縮。それは、数年のTENEXを実行しました。
Quite possibly, the final fortuitous event involved in the DEC decision to
take TENEX as the base for a DEC product happened not at DEC but at IBM.
It was during this period in the latter part of 1972 that IBM announced
"virtual memory" systems for the 360 family. While this was not entirely
unexpected, it provided a major shot of "legitimacy" for the concept of
virtual memory in computer system products. I (and other TENEX proponents)
had been actively promoting the virtual memory capabilities of TENEX, but
it took the IBM announcement to prove that such capabilities could be a
significant factor in large systems markets. This is rather ironic since
the memory management architectures in TENEX/TOPS-20 and the IBM systems are
quite different.
とても恐らく、DEC製品用の基礎としてTENEXをとるDEC決定に関与する最終偶然事故は、DECでではなくIBMで起こりました。それはIBMが発表した1972の後の部分中のこの期間にありました、360組の家族のための「仮想記憶」システム。これが完全に予期しないわけではなかった間、それは、コンピューター・システム製品中の仮想記憶の概念に「合法性」の主な発射を供給しました。私(また他のTENEX提案者)は、積極的にTENEXの仮想記憶能力を促進しました。しかし、そのような能力が大きなシステム市場の重要な要因かもしれないことを証明することはIBMの発表をとりました。これは、TENEX/TOPS-20の中のメモリ管理アーキテクチャー以来やや皮肉です。また、IBMのシステムは全く異なります。
Soon, discussions were being held around the idea that the KL10 would be,
not just a new CPU for the existing DECsystem-10 but the cornerstone of a
new VM product family including both hardware and software architectures.
Hardware architecture departures were to include internal main memory (as
opposed to external bus memory as on the KA and KI), the Massbus
interconnect for tapes and disks, and the use of a PDP 11/40 as a system
console. Software would take a comparable step with the capabilities of
TENEX: virtual memory, process structure, easy-to-use command language.
すぐに、議論は、単なる既存のDECsystem-10のための新しいCPUではなくKL10がそうだろうという考えのまわりでされていました。ハードウェア・アーキテクチャー出発は内部主要なメモリ(kAおよびKIでのような外部バス・メモリに対立するものとしての)を含むことでした、Massbusはシステム・コンソールとしてテープおよびディスク、およびPDP 11/40の使用のために相互に連結します。ソフトウェアは、TENEXの能力を備えた比較可能なステップをとるでしょう:仮想記憶、プロセス構造(使いやすいコマンド言語)。
Although I was part of only a few of those discussions, I still look back
with amazement at the speed and confidence with which the decision was made
to undertake such a major departure. The key individuals included Allan
Titcomb who had initiated the KI-TENEX project, Fred Wilhelm, the
engineering manager of the KL10 project, Bill Kiesewetter, the marketing
manager of the DECsystem-10 product line, and John Leng, the product line
manager. We didn't convene task forces or study committees or waffle on
the idea for a year or two. We met, considered the issues, and decided.
それらの少数だけの議論の一部でしたが、私はまだ、そのような主な出発を試みるために決定が下された速度および確信を驚嘆したようにふり返って見ます。重要な個人は、KI-TENEXプロジェクトを始めたアランTitcomb、フレッド・ヴィルヘルム、KL10プロジェクトのエンジニアリング・マネージャー、ビルKiesewetter、DECsystem-10生産ラインの販売責任者およびジョンLeng(生産ラインマネージャー)を含みました。私たちは、1年や2年の間その考えの上の特別対策本部あるいは研究委員会か、ワッフルを召集しませんでした。私たちは会合し、問題について熟慮し、決定しました。
Thus, by the end of the three-month KI-TENEX contract, I had a second offer
from DEC: to join the KL10 group as project leader for a new operating
system for the KL10 based on TENEX. By the time I started work at DEC as
an employee on January 2, 1973, one additional engineer had been recruited
to form the nucleus of a development group: Peter Hurley. The two of
us set up offices on the fifth floor of Maynard mill building 5, in a group
with the hardware engineers, the product line marketing and management
people, and vice president Win Hindle.
したがって、3か月KI-TENEXの契約の終了までに、私は、DECからの別の提示を行っていました:TENEXに基づいたKL10のための新しいオペレーティング・システムのためにプロジェクト・リーダーとしてKL10グループを連結すること。私が1973年1月2日に従業員としてDECで仕事を始めた時までに、1人の追加のエンジニアは開発グループの核を形成するために募集されました:ピーター・スティック。私たちの2人は、ハードウェア・エンジニア、生産ラインマーケティングおよび管理人々、および副社長Win Hindleとのグループ中で、5を構築するメイナード・ミルの5階にオフィスを設立します。
There were a number of areas in which we felt that work was necessary on
TENEX to make it suitable for release as a product. Some of these were
areas in which TOPS-10 had received sigificant work during the preceding
years, and others involved general maintainability, support of hardware
reliability and service, and overall robustness. TENEX did not, at the
time, have such features as batch operation or mountable disk structures.
仕事が製品としてそれをリリースにふさわしくするTENEXの?繧ﾅ必要であると私たちが思った多くのエリアがありました。これらのうちで、あるものはTOPS-10が前年にsigificant仕事を受け取ったエリアでした。また、他のものは一般的な保全性、ハードウェア信頼度およびサービスの支援および全面的な強健さを含んでいました。TENEXは、その時に、バッチ・オペレーションあるいは上がれるディスク構造のような特徴を持っていませんでした。
We also planned to significantly increase the support for "TOPS-10
compatibility" -- the system's ability to support existing TOPS-10 programs
and media. This support took several forms: the operating system service
call interface, the command language, disk structure formats, and other
external interfaces. TENEX had implemented provisions for the OS call
interface only, and that was limited by the lack of knowledge at BBN about
the details and undocumented aspects of the TOPS-10 calls. Also, the call
interface compatibility was only as complete as needed to run the
particular set of TOPS-10 layered software that BBN needed at the time.
さらに、私たちは、「TOPS-10互換性」の支援を著しく増加させることを計画しました。―― 既存のTOPS-10がプログラムする支援およびメディアへのシステムの能力。この支援はいくつかの形式をとりました:オペレーティング・システム・サービス呼び出しインターフェース、コマンド言語、ディスク構造フォーマットおよび他の外部は接続します。TENEXは、OS呼び出しインターフェースのみに対する準備を実行しました。また、それはTOPS-10呼び出しの詳細および公文書がない様相に関するBBNで知識の不足によって制限されていました。さらに、ただ完全なように、呼び出しインターフェース互換性はそうでした、求められるような、TOPS-10の特別のセットを実行することはソフトウェアを層にしました、それ、その時に必要とされるBBN。
One of the reasons for pursuing TOPS-10 compatibility features was the
possibility of re-converging on one operating system for all 36-bit
machines. That was, and continued to be, a controversial idea however, and
the destiny of these features is largely the result of continuing
indecision around how much effort should be invested in tools to help users
move from TOPS-10 to TOPS-20.
TOPS-10互換性特徴を追求する理由のうちの1つは、すべての36ビットのマシン用の1つのオペレーティング・システム上に再度集中させる可能性でした。それはそうでした、また引き続きあった、論争の的になっている考え、しかしながら、また、これらの特徴の運命は大部分はユーザがTOPS-10からTOPS-20まで移るのを助けるツールに、どれだけの努力を投資しなければならないかのまわりの不決断を継続する結果です。
At times, it was clearly the intent that TOPS-20 would eventually become
the sole 36-bit operating system. It appeared to have the capabilities to
support any desired level of TOPS-10 compatibility, and it offered features
that many TOPS-10 customers had been requesting but which appeared unlikely
ever to be realizable in TOPS-10. Most of the time, however, TOPS-10 (and
enhancements to it) appeared to be needed in the short term to maintain
some portion of the 36-bit business, and so the product line as a whole
was never able to achieve sufficient resolve to move the business back to
one operating system.
時々、TOPS-20が結局唯一の36ビットのオペレーティング・システムになるだろうことは明らかに意図でした。それは、TOPS-10互換性のどんな希望のレベルもサポートする能力を持つように見えました。また、それは、TOPS-10顧客が要求したが?AそれはTOPS-10において実現可能なためにかつてありそうもなく見えたその多数特徴に提供しました。しかしながら、通常、TOPS-10(またそれへの増強)は、36ビットのビジネスのある部分を維持するために短期で必要なように見えました。したがって、生産ラインは、全体として1つのオペレーティング・システムにビジネスを移動させる十分な決心を達成することができませんでした。
In the early life of the -20, the product line made some overtures to -10
customers about migrating to the -20. Migration aids weren't in place,
TOPS-20 didn't have all the needed capabilities, and the -10 customers
weren't about to accept the limits on configurations that applied to the
-20. Hence, the customers reacted quite negatively and scared the product
line out of doing anything that even suggested a migration strategy.
-20の初期の生活では、生産ラインが、-20.まで移動することに関する-10人の顧客へのいくつかの提案をしました。移住援助は適所にありませんでした。TOPS-20はすべての必要とされる能力を持っているとは限りませんでした。また、-10人の顧客は、-20.まで当てはまった配置に対する制限を受理するところでありませんでした。従って、顧客は、とても否定的に反応し、移住戦略をさらに示唆したものをすべてすることからの生産ラインを脅えさせました。
Ultimately, both operating systems continued to be developed and shipped
until the corporation made the much bigger decision to offer no new 36-bit
hardware products and to wind down all 36-bit software development. For
these and other reasons, replacing TOPS-10 was mostly not a high priority
during the life of the DECSYSTEM-20 and so capabilities like a TOPS-10
command language were not seen as important. Subsequent ups and downs of
interest in re-converging on one operating system are described further
below.
結局、両方のオペレーティング・システムは、企業が新しい36ビットのハードウェア製品を提供せず、かつ36ビットのソフトウェア開発をすべて次第に縮小するはるかに大きな決定を下すまで、開発されており送られることを継続しました。これらおよび他の理由のために、TOPS-10の交換はほとんどDECSYSTEM-20の生活の間の高い優先事項ではありませんでした。したがって、重要なものとして、TOPS-10コマンド言語のような能力は見られませんでした。再度集中させることに興味のある後の上下は、1つのオペレーティング・システムにさらに下に記述されます。
With the structure of TENEX, it had been possible to implement the TOPS-10
call interface compatibility in a relatively modular form. This piece of
software was called PA1050, after the DEC 10/50 system which was the top of
the -10 line at the time. To be able to support both the old (TOPS-10) and
new (TENEX) OS call interfaces, we had decided to use a native call
mechanism completely different from that used by TOPS-10. TOPS-10 used the
Monitor UUOs, a group of instructions which transferred control to the
kernal through a transfer vector. TENEX took a previously unassigned
opcode (104 octal) and gave it the mnemonic JSYS for Jump to SYStem. (The
Berekely 940 system had used a BRS, Branch to System.)
TENEXの構造と、比較的モジュールの形式でTOPS-10呼び出しインターフェース互換性をインプリメントすることは可能でした。ソフトウェアのこの部分は、その時の-10行のラインのトップだったDEC 10/50システムの後に、PA1050と呼ばれました。古く(TOPS-10)、新しい(TENEX)OS呼び出しインターフェースを支援することができるために、私たちは、TOPS-10によって使用されるそれと完全に異なる在来の呼び出しメカニズムを使用することを決定しました。TOPS-10はモニターUUO(トランスファー・ベクトルによってkernalにコントロールを転送した1グループの指示)を使用しました。TENEXは以前に割り当てられていないopcode(104の8進法)をとり、SYStemにそれに跳躍用の記憶を助けるJSYSを与えました。(Berekely 940システムはBRS(システムへの枝)を使用しました。)x
Within TENEX, execution of any of the TOPS-10 service calls went to a small
piece of kernel code that would invoke PA1050. On the first such call, it
would map the PA1050 image into a high area of the user virtual memory and
transfer control to it. On subsequent calls, it would merely effect the
transfer. Hence, only those processes that actually made TOPS-10 calls
would get the compatibility code, and each such process had its own
incarnation. The virtual memory implementation of TENEX meant that code or
data could be put anywhere, and there was no penalty for sparse use of the
address space. At the time, it was quite safe to usurp a range of high
addresses in a TOPS-10 program, since to use such addresses on a real
(non-VM) TOPS-10 system would have required the full 256 Kwords of memory
or more to run. Later on, as TOPS-10 programs became larger, we had
trouble squeezing the program, PA1050, and DDT (which also was mapped into
a high range of addresses) all together.
TENEXの内では、TOPS-10サービス呼び出しのうちのどの実行が、PA1050を起動する小さな1片の核コードに行きました。第1のそのような呼び出しにおいては、それが、ユーザ仮想記憶の高いエリアへPA1050イメージを写像し、それにコントロールを転送するでしょう。後の呼び出しにおいては、それが単にトランスファーを達成するでしょう。従って、現実にTOPS-10呼び出しを行ったプロセスだけが互換性コードを得るでしょう。また、個々のそのようなプロセスはそれ自身の実現を持っていました。TENEXの仮想記憶インプリメンテーションは、コードか?fータをいかなる場所でも置くことができるかもしれないことを意味しました。また、アドレス空間の希薄な使用に対する罰はありませんでした。その時に、TOPS-10の中の一連の高いアドレスを強奪することは全く安全でした、実際の(非VM)TOPS-10システム上でそのようなアドレスを使用することが、メモリの十分な256のKwordsを要求したので、プログラムする、あるいは実行することがより多く。後で、TOPS-10プログラムがより大きくなるとともに、私たちはプログラム、PA1050およびDDT(さらに、それはアドレスの高い範囲へ写像された)をすべて圧搾するのに苦?Jしました。
PA1050, then, was simply unprivileged user-mode code. It interpreted the
arguments of the TOPS-10 call that had been intercepted and performed the
requested action, using JSYS calls where necessary. It maintained its own
database of TOPS-10 job state in local process memory.
PA1050はそれでは、単に特権がないユーザー・モードコードでした。それは、遮られており、必要なところでJSYS呼び出しを使用して、要求されたアクションを実行した、TOPS-10呼び出しの議論を解釈しました。それは、ローカルのプロセス・メモリの中でTOPS-10仕事状態のそれ自身のデータ・ベースを維持しました。
The idea of alternate command languages was one of the attractive features
of TENEX. The TENEX command language (the "EXEC") was simply a user-mode
program that operated within a process and performed any system actions
via defined JSYS calls. Hence, a similar program to realize any other
desired user interface could be written and executed in the same manner by
any user without impacting others on the same system. The marketing folks
had visions of offering interfaces that were compatible with various
competing systems in order to lure customers away from those systems. We
also envisioned writing a user interface that would look like the TOPS-10
command language so as to facilitate users moving over from TOPS-10.
交替コマンド言語についての考えはTENEXの魅力的な特徴のうちの1つでした。TENEXコマンド言語(「EXEC」)は単にプロセス内に作動し、定義されたJSYS呼び出しによってどんなシステム・アクションも実行した、ユーザー・モードプログラムでした。従って、同じシステム上の他のものを密着させずに、任意のユーザによって同じ方法で他の希望のユーザ・インターフェースも実現する同様のプログラムを書き、実行することができるかもしれません。売買する人々は、顧客を誘惑してそれらのシステムから引き離すために様々な競合するシステムと互換性をもった提供インターフェースのビジョンを持っていました。さらに、私たちはTOPS-10がTOPS-10から席を譲るユーザを促進するために言語を命じるように見えるユーザ・インターフェースを書くことの構想を描きました。
Such a program was in fact written during the first year of development in
DEC by the third member of the new OS group, Arnold Miller. This interface
worked well enough to support execution of TOPS-10 batch files as well as
most normal user activity. However, it was never shipped as part of
TOPS-20, largely because users who came to TOPS-20 from TOPS-10 or any
other system quickly began to use and prefer the TOPS-20 command language.
Even for users who were reluctant to try something different, the
advantages of the TOPS-20 Exec were sufficiently apparent that few wanted
to continue working in their old environment. Similarly, no other
interfaces to mimic competing systems were ever written.
そのようなプログラムは、新しいOSグループの第3のメンバー、アーノルド・ミラーによってDECの中で開発の最初の年に書かれた事実にありました。このインターフェースはほとんどの正常なユーザ活動と同様にTOPS-10バッチファイルの実行を支援するほど十分にうまくいきました。しかしながら、大部分はTOPS-10あるいは他のシステムからTOPS-20に速く来たユーザが、使用しTOPS-20が言語を命じることを好むことを始めたので、TOPS-20に分かれるように、それは送られませんでした。異なるものを試みたくなかったユーザにとってさえ、TOPS-20幹部の利点は十分に明白でした、ほとんどはそれらの古い環境で働き続けたくありませんでした。同様に、競合するシステムを模倣する他のインターフェースはかつて書かれませんでした。
Interest in the TOPS-10 Exec was revived on one or two later occasions
when the possibility of migrating TOPS-10 users to TOPS-20 was considered,
but such thoughts never lasted long enough to result in a product.
TOPS-20への移動するTOPS-10ユーザの可能性が考慮された時、TOPS-10幹部への関心は1つあるいは2つの後の場合上で復活したが、そのような考えが十分に長く続かなかったので、製品に帰着しました。
One other compatibility feature developed during early TOPS-20 development
but never shipped was TOPS-10 disk structure I/O. This allowed a TOPS-10
disk structure to be mounted on a TOPS-20 system and be read and written by
a program running in TOPS-10 compatibility mode. This was achieved by
taking a large part of the actual file system code from TOPS-10 and
encapsulating it with an interface to PA1050 on one side and direct
block-level IO on the other. Again, this proved to be a feature that was
used briefly, if at all, and so never received much additional effort.
When the next version of the TOPS-10 file system code was released, it
proved more difficult to encapsulate and run in this way, and the
capability was abandoned even for internal use.
他の1つの互換性特徴は初期のTOPS-20開発の間に発展しました。しかし、TOPS-10ディスク構造I/Oは送られませんでした。これは、TOPS-10ディスク構造がTOPS-20システムにマウントされTOPS-10互換性モードで走るプログラムによって読み書きされることを可能にしました。これは、TOPS-10から実際のファイル・システム・コードの大部分をとり一方のPA1050および他方上の直接のブロックレベルIOへのインターフェースでそれをカプセルに入れることにより達成されました。再び、これは、簡潔に使用された特徴であると分かりました、場合、いずれにしても、それで補足努力をあまり受け取りませんでした。TOPS-10ファイル・システム・コードの次のバージョンがリリースされた時、このようにカプセルに入れて走ることは、より困難であると分かりました。また、能力は内部使用のためにさえ放棄されました。
It's time to discuss the history of names of the operating system that came
to be known as TOPS-20. As part of undertaking this new operating system
development, DEC purchased the commercial rights to TENEX from BBN early in
1973. However, with a major marketing thrust anticipated for the new
KL10-based system, a new name for the operating system would be necessary.
Also, the development group in DEC intended to be independent of the group at
BBN which was continuing to develop new versions of TENEX for the KA10 ARPA
users. Within the first few months, various names were considered.
Finally, the KL10 engineering manager, Fred Wilhelm, declared that the new
operating system would be called VIROS. It seemed perfect for the time: it
suggested "virtual", which was to be a key feature of the new system, and
it had a strong, virile sound. Unfortunately, John Leng (and others)
tended to pronounce it as "virus" and so it probably wouldn't have survived
even if other factors hadn't pushed it aside.
TOPS-20として知られるために来たオペレーティング・システムの名前の歴史について議論す??a議論です。この新しいオペレーティング・システム開発を試みる部分として、DECは、1973年の初めにBBNからのTENEXへの商用権利を購入しました。しかしながら、新しいKL10ベースのシステムのために主なマーケティング推進力を予想したまま、オペレーティング・システムの新しい名前は必要でしょう。さらに、DECの中の開発グループは、KA10 ARPAのユーザのためのTENEXの新バージョンを開発し続けていたBBNのグループに依存しませんですつもりでした。最初のの数か月の内では、様々な名前が考慮されました。最後に、KL10エンジニアリング・マネージャー(フレッド・ヴィルヘルム)が新しいオペレーティング・システムがVIROSと呼ばれるだろうと宣言しました。それはその時には申し分なく見えました:それは示唆しました「仮想の」、どれが新システムの重要な特徴であることかそれ、強く男性の音を持っていました。不運にも、ジョンLeng(また他のもの)は、「ウィルス」としてそれを発音する傾向がありました。したがって、他の要因がそれを押しやっていなかったとしても、それは恐らく残存していなかったでしょう。
Later on during that first year, it was decided to change the name to
confuse the competition. This was part of a policy dictated from "on high"
to keep the marketplace from knowing too much about unannounced
developments. We knew that preventing all leaks was impossible, so the
idea was to confuse the world with conflicting information. The new name
chosen for the operating system then was SNARK, from a Lewis Carol story
about the hunting of the SNARK, where "they pursued it with forks and
hope". (We had lots of both.) That name almost had a short lifetime, since
it was further declared that internal code names would be changed every six
months to keep the enemy guessing. When time came for the first six month
change, the group resisted the hassle of yet another purturbation but
eventually yielded and put forth KRANS (SNARK spelled backwards) as the new
name. Unfortunately, it was soon discovered that this was a word that meant
"burial vault" in Swedish. The name was quickly changed back to SNARK, and
even our management then declared that we would have nothing further to do
with the semi-annual name change folly.
その最初の年に、後で、それは競争を混同する名前を変更すると決定されました。これは未発表の開発のことをあまりに知っていることからの市場を維持するために「最高値上で」書き取らせられた政策の一部でした。私たちは、漏れをすべて防ぐことが不可能なことを知っていました。したがって、目的は矛盾する情報を備えた世界を混同することでした。そのときオペレーティング・システムのために選ばれた新しい名前は、SNARKの狩猟のルイス・キャロルの話から、SNARKで、そこでは、「それらがフォークと希望でそれを追求した。」(私たちは、両方の多くを持っていました。)敵を推測させておくために6か月ごとに内部コ?[ド名が変更されるだろうことが、さらに宣言されたので、その名前はほとんど短い一生を持っていました。時間が第1の6か月の変更のために来た時、グループは激論に抵抗しました、まだ別のpurturbation、しかし結局新しい名前としてのKRANS(後ろに綴られたSNARK)を前へ産出し置いた。不運にも、これがスウェーデン語の「地下納骨所」を意味した言葉だったことはすぐに発見されました。名前は、SNARKに速く変更されました。また、私たちの管理さえ、半毎年の改名愚行で行うためには、私たちがさらに何も持たないだろうと次に宣言しました。
Hence, the name remained SNARK until it was time to announce the product.
The various interim names didn't vanish completely however; they were all
used for other internal purposes, mostly as names for disk volumes in the
TOPS-20 group. In fact, the SNARK pack (pronounced with a Boston accent as
"snak pack") remained the home of the TOPS-20 sources for the entire life
of the system. SNARK and KRANS are currently nodes on the DEC internal
network but are not in the 36-bit engineering group.
従って、製品を発表する時間であるまで、名前はSNARKのままでした。しかしながら、様々な臨時の名前は完全には消えませんでした;それらはすべて、ほとんどTOPS-20グループ中のディスク・ボリュームの名前として他の内部目的のために使用されました。実際、SNARKパック(「snakパック」としてボストン・アクセントで発音された)は、システムの全生活のためのTOPS-20出所の家のままでした。SNARKとKRANSは現在DEC内部ネットワーク上のノードであるが、36ビットのエンジニアリング・グループにありません。
As time for product announcement approached, very high-level consideration
was being given to the product name. Mere engineers were not a party to
this process, so we waited with anticipation for the new and final system
name to be handed down. Would they stay with SNARK (unlikely)? Go back to
VIROS ("V" names were getting more popular all the time)? Or come up with
something new and dynamic. The result was, to put it mildly, underwhelming.
Although TOPS-20 as a name became just a fact of life over the years, we
originally saw it as about the least exciting, least imaginative name one
could possibly have chosen for such a neat, new system. It was just the
same as the old system, TOPS-10, except for one digit. About as creative
as "Wednesday Night at the Movies" for a new TV show of the same era. But
that was the story: the new product would be the "DECSYSTEM-20" (somebody
forgot to lower-case the "system" as in DECsystem-10) and the operating
system would be TOPS-20.
製品発表のための時間が接近するように、まさにハイ・レベルの考察は製品名に与えられていました。単なるエンジニアはこのプロセスの加担者ではありませんでした。したがって、私たちはお下がりとして回される新しく最終のシステム名を、予想で待ちました。それらはSNARK(ありそうもない)を続けるでしょうか。VIROS(「V」名は終始よりポピュラーになっていました)に戻りますか。あるいは、新しく動的であるものに追いついてください。結果は白けさせて、それを温和に置くために、ありました。名前としてのTOPS-20はその数年にわたって単なる生の事実になりましたが、最も刺激的でかつ最も想像的でない名前に関して、一つがそのようなきれいな新しいシステムのために恐らく選ぶことができたように、私たちはもとはそれを見ました。それは1つの数字を除いて単に旧システム(TOPS-10)と同じでした。同じ時代の新しいテレビ番組用の「映画の水曜夜」とほぼ同じくらい創造的です。しかし、それは物語でした:新製品はそうでしょう、その「DECSYSTEM-20"(誰かが小文字にDECsystem-10でのような「システム」を忘れました)およびオペレーティング・システムは、TOPS-20でしょう。
So, although the name TOPS-20 wasn't chosen until just before the first
system ship, I have used TOPS-20 to refer to the operating system
for the entire time it was under development at DEC, that is, from January
1973 onward.
そのように、ちょうど第1のシステム船の前に、私が全時にオペレーティング・システムを参照するためにTOPS-20を使用するまで、名前TOPS-20は選ばれませんでしたが、それはDECに開発中でした、すなわち、1973年1月から、前進的。
The TOPS-20 group grew to four people during its first year. In addition to
myself, Peter Hurley, and Arnold Miller mentioned previously, Len Bosack
joined the group within the first few months. Tom Hastings was also
involved, serving briefly as the supervisor. Although it started as part
of KL10 hardware engineering, this new group made the transition to its
more logical place in software engineering after the first year.
TOPS-20グループはその最初の年に4人まで成長しました。私自身、ピーター・スティック、および以前に言及されたアーノルド製粉業者に加えて、レンBosackは最初のの数か月の内にグループに参加しました。トム・ヘースティングズもスーパーバイザを簡潔に務めて複雑でした。それはKL10ハードウェア工学の一部としてスタートしましたが、この新しいグループは最初の年後にソフトウェア工学中でそのより論理的な場所への推移を作りました。
Several others served as supervisor of the group between its formation and
first ship. On several occasions, the group hired its new supervisor. To
save time, an interview would be set up with several members of the group
at once who would fire questions at the hapless candidate. If the
candidate couldn't survive this, he clearly wouldn't last in the day-to-day
functioning of the group. Managers weren't the only candidates who were
given practical scrutiny. Judy Hall, the fifth member hired into the group,
and others who joined during that period, were typically asked to bring
samples of code they had previously written when they came for interviews.
いくつかの他のものは、その構成と第1の船の間のグループのスーパーバイザを務めました。いくつかの場合においては、グループがその新しいスーパーバイザを雇いました。時間を節約するために、不幸な候補に質問を発砲するインタビュ?[は、グループのいくつかのメンバーで直ちにセット・アップされるでしょう。候補がこれを生き残ることができなかったならば、彼はグループの日々に機能することで明らかには続かないでしょう。マネージャーは実際的な調査を与えられたただ一つの候補ではありませんでした。その期間に参加したジュディ・ホール、グループへ賃貸された第5のメンバーおよび他のものは、典型的にはインタビューのために来た時それらが以前は書いたコードのサンプル??aをように依頼されました。
The DECSYSTEM-20 (and TOPS-20) was first shipped in January, 1976, just
three years after DEC internal development began. This was, of course,
longer than we had anticipated. Both the hardware and the
software schedules were extended, and a few other changes in plans
occurred. As mentioned above, the KL10 had already departed somewhat from
its original conception as a "low-cost" KI10 replacement by the time
TOPS-20 development started. As TOPS-20 development proceeded, we provided
a couple more "1-plusses" to the machine.
DEC内部開発が始まったちょうど3年後、DECSYSTEM-20(またTOPS-20)は1976年1月に最初に送られました。これは私たちが予想したよりもちろん長かった。ハードウェアおよびソフトウェア・スケジュールの両方は拡張されました。また、計画の他の少?狽ﾌ変化が生じました。上に言及されるように、KL10はTOPS-20開発がスタートした時までに「廉価な」KI10置換として多少そのオリジナルの概念から既に外れました。TOPS-20開発が進むとともに、私たちはカップルに機械へのより多くの「1-有利な条件」を供給しました。
One of these was extended addressing. TOPS-20 didn't force this as an
issue, but it seemed to provide the opportunity to eventually take advantage
of it. The possibility of extending the address space of the PDP-10
architecture was first suggested to me by Tom Hastings during the 3-month
period when I was working on KI-TENEX. At that time, it seemed a pretty
radical idea that 256 Kwords of address space might not be enough for most
applications, but the PDP-11 was already running into trouble in that
regard and it seemed prudent to think about it for the -10 while we were
building this new processor.
これらのうちの1つは拡張アドレシングでした。TOPS-20は問題としてこれを強要しませんでした。しかし、それは、結局それを利用する機会を提供するように見えました。私がKI-TENEXを処理していた時、PDP-10アーキテクチャーのアドレス空間を拡張する可能性は、3か月の期間にトム・ヘースティングズによって私に最初に示唆されました。その時に、それはアドレス空間の256のKwordsがほとんどの適用にとって十分ではないかもしれないというかなり根本的な考えに見えました。しかし、PDP-11は既に問題にその点に関して陥っていました。また、私たちがこの新しいプロセッサーを建造していた間、-10のためにそれに関して考えることは思慮深く見えました。
There were two primary problems to be solved in extending the address space
of the PDP-10. First, a way would be needed to generate effective
addresses of greater than 18 bits; second, a means would be needed to map
this larger virtual address space. For the hardware designers, the second
problem appeared more formidable. They planned to use a table-lookup RAM
to hold virtual-to-physical address translations, and a larger address
space appeared to require a prohibitively large translation RAM. The KI10
had used an associative memory for this purpose, but the integrated
circuits available in the technology of the KL10 didn't provide a way to
make a practical associative memory.
2つの主要な問題を、PDP-10のアドレス空間を拡張する際に解決しなければなりません。最初に、方法は18ビット以上の有効なアドレスを生成するために必要でしょう;次に、手段はこのより大きな仮想のアドレス空間を写像するために必要でしょう。ハードウェア・デザイナーについては、第2の問題がより恐ろしく見えました。彼らは、物理アドレスに仮想翻訳を保持するためにテーブル検査RAMを使用することを計画しました。また、より大きなアドレス空間は、法外に大きな翻訳RAMを要求するように見えました。KI10はこの目的のために連想のメモリを使用しました。しかし、KL10の技術において利用可能な集積回路は、実際的な連想のメモリを作る方法を提供しませんでした。
As it happened, the solution to this problem resulted from a bit of
synergy. Alan Kotok had been looking for a way to make the paging RAM
smaller even than that which would appear to be required for the basic
PDP-10 address space. With 512 pages in each of user and exec mode address
spaces, 1024 entries would be necessary for a direct mapping scheme. Alan
was thinking about using the same 512 entries for both user and exec by
storing the user-mode bit in the entry and comparing it on a lookup. If
the comparison failed, the entry would be considered invalid and would be
reloaded from memory. Thus, the same entry would be used for a given user
and exec mode address and would work as well as a full-size table provided
there were not too frequent references to the same user and exec
addresses.
たまたま、この問題の解決策は少しの共同作用に起因しました。アランKotokは、ページをつけるRAMを、基礎的なPDP-10アドレス空間のために必要になるように見えるそれよりさえ小さくする方法を捜しました。512ページで、各々のユーザと幹部のモード・アドレス空間で?ﾍ、1024のエントリーが直接の写像スキームに必要でしょう。アランは、エントリーにユーザー・モードビットを格納し検査上でそれを比較することにより、ユーザおよび幹部の両方への同じ512のエントリーを使用することに関して考えていました。もし比較が失敗すれば、エントリーは無効であると考えられ、メモリから再びロードされるでしょう。したがって、同じエントリーは与えられたユーザおよび幹部モード・アドレスのために使用され、そこに提供される標準サイズのテーブルと同様に働くでしょう、同じユーザと幹部のアドレスへの頻繁すぎる言及でありませんでした。
While this was going on, I realized that there was nothing unique about the
user-mode bit in this scheme, and that it could be extended to an
arbitrarily large number of address bits. That is, a given number of bits
for translation could be divided into two parts: one part to index into the
RAM, and the other to be stored and compared. For purposes of extended
addressing, that meant we could have a number of spaces each as large as
the original 256 Kwords all mapped into the same translation RAM. The
smaller the RAM, the greater the possibility of conflict, but that could be
somewhat mitigated by "hashing" the address bits so that the different
address spaces were offset differently in the RAM.
これが起こっていた間、私は、ユーザー・モードビットに関してユニークなものは何もこのスキームでなく任意に多くのアドレス・ビットまでそれを延長することができるかもしれないことを悟りました。すなわち、翻訳用ビットの与えられた数を2部に分割することができるかもしれません:RAMへインデックスを付けるべき1部および格納され比較される他方。拡張アドレシングの目的のために、それは、私たちが多くのスペースを各々持つことができることを意味しました、同じ翻訳RAMへすべて写像されたオリジナルの256のKwordsと同じくらい大きなより小さな、RAM、より大きな、矛盾の可能性、しかし、異なるアドレス空間がRAMの中で異なって相殺されたように、アドレス・ビットを「切り刻む」ことにより、多少それを緩和することができるかもしれません。
As for modifications to the basic instruction set, we initially decided on
an extension of the address space from 18 to 23 bits. This number was
chosen because it was the number of bits available by combining the Y, I, and
X fields (address, indirect, and index) of the PDP-10 instruction.
We were fortunate in that the PDP-10 instruction set had a very clean and
consistent design -- every instruction computed its operand address in the
same way. If this algorithm could be modified to yield a larger address,
the problem would be solved for essentially all instructions. The PC could
easily be made as large as necessary in hardware, and the various word
formats in which it appeared generally had the additional 5 bits available.
基礎的な指示セットへの修正に関しては、私たちが、最初に18から23ビットまでのアドレス空間の拡張を決めました。それがYを組み合わせることにより利用可能なビットの数、私およびPDP-10指示のXのフィールド(アドレス、間接、またインデックス)だったので、この数が選ばれました。私たちは、PDP-10指示セットが非常に清潔で一貫した設計を持っていたとは幸運でした--すべての指示は、同じ方法でそのオペランド・アドレスを計算しました。より大きなアドレスを産出するためにこのアルゴリズムを修正することができるかもしれない場合、その問題は本質的に解決されるでしょう、すべての指示。容易にPCを作ることができるかもしれません、として、ハードウェア、およびそれが一般に現われた様々な単語フォーマットにおいて必要なときに大きな、さらに5ビットを利用可能にしておきました。
All that notwithstanding, any modification to the instruction set to
generate larger addresses would be incompatible with existing code to some
extent. To avoid introducing such incompatibilities, the original design
had a special way of executing an instruction when an extended operand
address was desired. An instruction executed normally would generate a
compatible 18-bit address, but the same instruction executed as the operand
of a "special execute" instruction (SXCT) could generate a larger address.
It did this by using additional bits of either an indirect word or index
specified in the instruction.
すべてのそれ、それにもかかわらず、より大きなアドレスを生成する指示セットへのどんな修正も、既存のコードとある程度まで非互換性でしょう。そのような非互換性を導入することを回避するために、オリジナルの設計は、拡張オペランド・アドレスが望まれた時指示を実行する特別の方法を持っていました。通常実行される指示は互換性をもつ18ビットのアドレスを生成するでしょう、しかしオペランドとして実行された同じ指示、1つの「スペシャル、実行する」指示(SXCT)はより大きなアドレスを生成することができました。それは、間接の単語かインデックスが指示で指定したどちらかの追加のビットの使用により、これをしました。
As it turned out, our initial extended addressing design was too
conservative. Before the first DECSYSTEM-20 even shipped, we had occasion
to revisit and greatly modify the design of extended addressing in
connection with the UNICORN project described later.
結局のところ、私たちの初期の拡張アドレシング設計は保守的すぎました。第1のDECSYSTEM-20がさらに出荷する前に、私たちは再訪するべき機械を持ち、その後記述されたUNICORNプロジェクトに関する拡張アドレシングのデザインを非常に修正します。
Another perturbation to the KL10 design was in the area of paging. Because
of the success of running TENEX on the KI10 using a software simulation of
the TENEX paging design, it was initially assumed that the same could be
done on the KL10. However, we knew that the software simulation was
consuming some amount of processor time because the speedup of TENEX
programs moving from the KA10 to the KI10 was typically not as much as
expected. Some studies using PC-sampling techniques revealed that the
paging simulation code was often using over 30% of the processor under a
typical timesharing load.
KL10設計への別の動揺はページングのエリアにありました。設計にページをつけるTENEXのソフトウェア・シミュレーションを使用して、KI10上でTENEXを実行する成功のために、KL10の上で同じことを行うことができるかもしれないと最初に仮定されていました。しかしながら、私たちは、KA10からKI10まで移るTENEXプログラムのスピードアップが、多くとして典型的に予想通りでなかったので、ソフトウェア・シミュレーションがある量のプロセッサー時間を消費していることを知っていました。PCサンプリング技術を使用するいくつかの研究は、?yージをつけるシミュレーション・コードが典型的なタイム・シェアリング・ロードの下のプロセッサーの30%以上をしばしば使用していることを明らかにしました。
This brought up yet again the thorny issue of putting the complex TENEX
paging algorithms into hardware -- the thing that had been resisted for
both the KA10 and KI10. Devoting that much hardware to paging still seemed
like a bad idea to the hardware engineers, but fortunately there was another
possibility for the KL10: microcode. Just as the KI-TENEX implementation
had shown that the page refill algorithm could be executed in software with
the result handed to the hardware, so could it be executed by microcode.
The basic instruction set was to be implemented in microcode on the KL10
(the first PDP-10 architecture processor so designed), so, the thinking
went, we could add "just a little more microcode" for the paging algorithm.
これは、ハードウェアの中にアルゴリズムにページをつける複雑なTENEXを入れる困難な問題を再び表に出しました。―― KA10およびKI10の両方のために抵抗されたもの。ハードウェア・エンジニアへの悪い考えのようにまだページをつけることにその多くのハードウェアを当てるように見えました。しかし、幸運にも、KL10の別の可能性がありました:マイクロコード。ちょうどKI-TENEXインプリメンテーションがそれを示したとともに、ページ、アルゴリズムを補充する、ハードウェアに渡された結果を備えたソフトウェア中で実行することができた、したがって、できた、それ、マイクロコードによって実行されます。基礎的な指示セットはKL10(第1のPDP-10アーキテクチャー・プロセッサー、したがって、設計された)の上のマイクロコード中でインプリメントされることになっていました、したがって、思考は行きました、私たちは付け加えることができました「ほんの少しより多くのマイクロコード」ページをつけるアルゴリズムのために。
Some changes were necessary to the hardware design of the KL10 as it
existed at that point in order to allow the microcode to get control when
an attempted address translation failed, compute the translation and load
it into the translation buffer, and continue with the instruction then in
progress. That was taken care of with little additional hardware, and
it seemed we had finally achieve full support of the paging architecture.
With a bit of myopia typical of that time, we figured we had solved all our
paging performance problems since anything done in microcode had to be
incredibly fast. ("Micro madness" as Len Bosack often called it.)
それが試みられたアドレス変換が失敗した時、マイクロコードがコントロールを得て、翻訳を計算し、翻訳バッファーにそれをロードすることを可能にし次に、進行中に指示を継続するためにその時点で存在したので、いくつかの変更はKL10のハードウェア・デ?Uインに必要でした。それは、補足ハードウェアで世話をほとんどされませんでした、また、私たちが最後に持ったように見えました、ページをつけるアーキテクチャーの全面的なサポートを達成します。少しの近視がその時間に典型的だったまま、私たちは、マイクロコード中で終わったものがすべて信じられないほどに速くなければならなかったとして以来ページをつける実行問題をすべて解決したと考えました。(レンBosackとしての「ミクロの狂気」はしばしばそれを呼びました。)
Thus the KL10 had both extended addressing and TOPS-20 paging capabilities
when it first shipped. It is just possible that those enhancements did
extend the development schedule somewhat, although we argued at the time
each of these was being considered that the additional work was
insignificant in the overall picture. I'm not quite sure how we finally
got these things approved. I recall a rather angry Win Hindle practically
throwing us out of his office the first time we came in to tell him about
adding extended addressing to the machine.
したがって、最初に船で行った時、KL10は両方ともアドレシングおよびTOPS-20ページをつける能力を拡張しました。私たちは、補足仕事が全面的な写真に些細であるとこれらの各々が思われていた時に議論しましたが、それらの増強が開発スケジュールを多少拡張したことはちょうどありえます。私は、私たちがこれらのものをどのように最後に承認したか全く確信しません。私は、私たちがはじめて機械に拡張アドレシングを加えることのことを彼に伝えるために中へ入った時に彼のオフィスから実際に私たちを投げ出すやや腹を立てた勝利Hindleをリコールします。
While we were bothering the hardware group with changes around paging and
extended addressing, we were busy with quite a number of software projects
as well. Typical of projects to make the system more robust in commercial
environments was the one to modify the system's handling of disk writes and
disk allocation tables. In TENEX and TOPS-20, essentially all disk IO is
initiated via paging. File pages are mapped, whether into user or exec
address space, and read or written with ordinary instructions. In TENEX as
it came to DEC, all file pages were treated equally, including those in
directories, page tables, and disk allocation tables. This worked just fine
providing the system never crashed. If the system were taken down
intentionally, its last act would be to write all modified pages out to the
disk and thus make the disk consistent.
ページングおよび拡張アドレシングのまわりの変更でハードウェア・グループを困らせていた間、私たちは全くソフトウェア・プロジェクトの数で同様に忙しかった。システムをより多くにするプロジェクトに典型的?A商用環境において強健、システムのディスクの取り扱いを修正するものだった、書く、またディスク割付けテーブル。TENEXおよびTOPS-20では、本質的に、ディスクIOがすべてページングによって始められます。ユーザか幹部アドレス空間、および読み取りへも、ファイル・ページは写像されるか、あるいは通常の指示で書かれます。TENEXの中で、それがDECに来るとともに、ファイル・ページはすべて、ディレクトリー、ページ・テーブルおよびディスク割付けテーブル中のものを含めて、等しく扱われました。もしシステムが衝突しなかったこととば、これはちょうど素晴らしく働きました。もしシステムが故意に降ろされれば、その最後の行為はディスクに修正済のページをすべて書き、したがって、ディスクを一貫しているようにすることでしょう。
If the system crashed however (as occasionally did happen), it could easily
be that an inconsistent set of pages had been written to the disk. A file
directory might be pointing to a file for which the page table had not been
written, or pages might be in use for which the allocation table had not
been updated. To take care of this, the practice on TENEX had been to run
a disk consistency check program called CHECKDSK. In particular, this
would mark the allocation table for any pages found in use so as to prevent
multiple assignment. This had been satisfactory at first, but with the
increase in the amount of of file storage, it had begun to take an
objectionably long time. The solution was to force writing of the
allocation tables, page tables, and directories at certain points and in a
certain order using techniques now well understood. It's interesting to
note that Unix had similar problems in its early versions, and the same
techniques have had to be applied in more recent versions.
もししかしながら(同じように時々起こった)、システムが衝突すれば、それは容易に、ページの一貫しないセットがディスクに書かれたということであることができるでしょう。ファイル・ディレクトリーは、ページ・テーブルが書かれていなかったファイルを指しているかもしれません。あるいは、ページは、割付けテーブルが更新されていなかった使用にあるかもしれません。これを世話するために、TENEXの上の実行はCHECKDSKと呼ばれるディスク一貫性チェック・プログラムを実行することでした。これは、特に、複合の割り当てを防ぐために使用で見つかった任意のページで割付けテーブルをマークするでしょう。これは、初めはしかし量の増加で満足でした、ファイル記憶装置に、不愉快に長い時間はかかり始めました。その解決は、あるポイントで、およ?ﾑある順に割付けテーブル、ページ・テーブルおよびディレクトリーの理解されて、今技術をよく使用して書くことを強要することでした。Unixがその初期のバージョンの中に同様の問題持っていたことに注目することは面白く、より最近のバージョンで同じ技術を適用しなければなりました。
Another interesting step was the development of the COMND JSYS. This system
call provides a set of services to implement the TOPS-20 style of command
interface (escape recognition, question-mark help, etc. as discussed
previously). It was not, however, part of TENEX as it came from BBN. Rather,
those interface characteristics were individually coded in each program
that supported them, and in fact, only the EXEC supported them in general.
Other programs typically supported only recognition of file names, since that
was provided by the GTJFN system call.
Even basic command line editing (rubout to delete a character, control-U to
erase the line, etc.) was not centralized and was provided more or less or
not at all by various programs.
別の面白いステップはCOMND JSYSの開発でした。このシステムコールは、コマンド・インターフェース(回避認識、疑問符支援など、以前に議論されたとともに)のTOPS-20スタイルをインプリメントする1セットのサービスを提供します。しかしながら、それは、BBNから来たとともに、TENEXの一部ではありませんでした。もっと正確に言えば、それらのインターフェース特性は個々に??閧ﾜした、それらを支援したプログラムごとの中で、および事実の中でコード化した、EXECだけが一般にそれらを支援しました。それがGTJFNシステムコールによって提供されたので、他のプログラムは典型的にはファイル名の単に認識を支援しました。基礎的なコマンドライン編集さえ(文字(ラインなどを削除するコントロール-U)を削除する抹殺)中心に集められず、様々なプログラムによって多かれ少なかれ提供されたか、全く提供されませんでした。
The need for centralized command line editing was addressed earlier in the
TOPS-20 development by the addition of the TEXTI JSYS (and related subsets
RDTXT and RDLINE). The increasing use of video terminals had made the ad
hoc provisions of the various utility programs particularly glaring.
With TEXTI, we undertook to both centralize the line editing functions and
to make them sensitive to the type of terminal being used. At that time,
taking advantage of the video terminal's ability to erase a character or
line was still impressive. Some systems had been able to add at least a
minimum of video terminal line editing support because they only supported
line input, and the line buffering was done centrally. TENEX had been
designed with a maximum of terminal flexibility however and so had no
general way of editing input. The TEXTI JSYS provided many options
so that it could be used as well by programs that wanted more
or less than line-at-a-time input.
中心に集められたコマンドライン編集の必要は、TEXTI JSYS(そして部分集合RDTXTおよびRDLINEを関連づけた)の追加によってTOPS-20開発で以前にアドレスされました。ビデオターミナルの増加する使用は、特にぎらぎら光る様々なユーティリィティ・プログラムに対する特別な準備をしました。TEXTIで、私たちは、ライン編集機能を中心に集めてそれらを使用されているターミナルのタイプに敏感にすることを試みました。その時に、文字かラインを削除するビデオターミナルの能力の利用はまだ印象的でした。いくつかのシステムは、それらがライン入力を単に支援したのでターミナルにラインをビデオに編集する少なくとも1つの最小が支援すると付け加えることができました。また、ライン・バッファーは中心に行われました。しかしながら、TENEXは最高ターミナルの柔軟性で設計されており、したがって、入力を編集する一般的な方法がありませんでした。多かれ少なかれ不足したプログラムによって同様にそれを使用することができるかもしれないように、TEXTI JSYSは多くのオプションを提供しました、より、ライン一度にの入力。
Implementing a centralized command input library was not, however, an item
that appeared on our schedules. Within the last year before the system
shipped, we had identified and were working on a few utility programs that
needed specific improvements. One of these was DUMPER (the disk-to-tape
backup and restore utility), and it had a particularly bad command
interface. I had the task of improving DUMPER's user interface to meet
some minimal level of acceptability, but I had been procrastinating doing
anything about it because it would be a rather routine and boring task. In
the meantime, I had started thinking about how this style of command
interface could be centralized into a set of functions and tables.
しかしながら、中心に集められたコマンド入力図書館のインプリメントは私たちのスケジュールに現われたアイテムではありませんでした。送られたシステムの前の昨年内では、私たちが識別しており、特定の改良を必要とした少数のユーティリィティ・プログラムを処理していました。これらのうちの1つはDUMPER(録音するディスクバックアップ、またユーティリィティを回復する)でした、また、それは特に悪いコマンド・インターフェースを持っていました。私は、受容性のある最小のレベルに会うDUMPERのユーザ・インターフェースを改善するタスクを行っていました。しかし、私は、それがややルーチンおよび退屈なタスクになるのでそれに関して何でもして遅延しました。一方、私は、1セットの機能およびテーブルへどのようにコマンド・インターフェースのこのスタイルを中心に集めることができたかに関する思考を始めました。
Because of the highly interactive nature of the interface, partial
execution of the program itself is necessary during input of the
command. For example, if file name recognition is attempted, the defaults
and any other pertinent context must be available so that failure or
success can be determined. However, the program must not take any
irrevocable action until the command is confirmed (typically with a
carriage return) so that the user can erase all or part of it with the line
editing keys. Even the original TENEX Exec didn't get this quite right.
The user could erase the entire command line with control-U, but could not
delete backward more than the current field. In other words, the Exec knew
how to flush all state for the current line and start over, and it knew how
to delete characters from the current field before it was completed, but it
didn't know how to flush part of the state and backup into a field already
completed.
インターフェースの高度に対話型の性質のために、プログラム自体の部分的な実行はコマンドの入力の間に必要です。例えば、ファイル名認識が試みられる場合、失敗または成功を決定することができるように、デフォルトおよび他の適切な情況も利用可能であるに違いありません。しかしながら、ユーザがキーを編集するラインを備えたそのすべてあるいは部分を削除することができるように、コマンドが確認される(キャリッジリターンで(典型的には))まで、プログラムは変更不可の処置を講じてはなりません。オリジナルのTENEX幹部さえこの全く右を得ませんでした。ユーザは、コントロール-Uを備えた全コマンドラインを削除することができたが、現在のフィールド以上に後方へ削除しないことができませ。言いかえれば、幹部は、現在のラインおよびスタートのための状態をすべて上方へ洗い流す方法を知っていました。また、それは、その前に現在のフィールドから文字を削除する方法が完成することを知っていました。しかし、それは、既に完成したフィールドへ状態およびバックアップの一部を洗い流す方法を知りませんでした。
My idea for solving the backup problem was not to backup at all but rather
save the command text and then rescan it from the beginning with the
unwanted part removed. With that idea and a list of functions to handle
the various kinds of fields that would occur in a command line, I started
writing a library-type facility instead of just point enhancements to
DUMPER. Of course, DUMPER was intended to be, and did become, the first
program to use new facility, but by the time of TOPS-20's first release,
these command parsing routines had been integrated into the monitor
as the COMND JSYS. Most utilities had not been modified to use
it however, and the Exec still had its original parsing code. Correcting
all this was done in later releases.
バックアップ問題の解決に対する私の考えはバックアップにありませんでした、で、ほとんどややコマンド・テキストを保存し、次に、それを再走査する、から、その、望まれない部分から始まることは移動しました。その考え、お?謔ﾑコマンドラインに生じる様々な種類のフィールドを扱う機能のリストで、私は、DUMPERに正当なポイント増強の代わりに図書館タイプ設備を書き始めま?ｵた。もちろん、DUMPERは、そうであるように意図されなりました、新しい設備を使用する最初のプログラム、しかし、TOPS-20第1のリリースの時間までに、これらのコマンド解析ルーチンはCOMND JSYSとしてモニターへ統合されました。ほとんどのユーティリィティはしかしながら、それを使用するためには修正されていませんでした。また、幹部はまだそのオリジナルの解析コードを持っていました。これすべての修正は後のリリースで終わりました。
Ultimately, most of the TOPS20 development done for the first release went
toward supporting the new hardware architectures and devices. A complete
new mass storage IO structure was necessary for the Massbus disks and
tapes, and an equally large change was necessary to handle communications IO
through the PDP-11 front-end rather than via direct line scanners.
結局、第1のリリースのために終わったほとんどのTOPS20開発は、新しいハードウェア・アーキテクチャーおよび装置の支援に向けて行きました。完全な新しい多量記憶IO構造はMassbusディスクおよびテープに必要でした。また、等しく大規模な変更は直系スキャナによってではなくPDP-11フロント・エンドによってコミュニケーションIOを扱うのに必要でした。
Almost all system code for the 36-bit architecture machines had been
written in MACRO since the first boot routine of the PDP-6. Because of its
regular structure and powerful set of operations, 36-bit assembly language
was reasonably pleasant to write in, and so less pressure existed for a
higher level language than on most other machines. BLISS was gaining some
adherents in some parts of DEC, but its various peculiarities (e.g. the
"dot" notation and use of underscore for the assignment operator in the
early -10 version) generated major resistance elsewhere. Hence, new
TOPS-20 code was written in MACRO, as TENEX had been.
36ビットのアーキテクチャー機械のためのシステム・コードはほとんどすべて、PDP-6の第1のブーツ・ルーチン以来MACROの中で書かれました。オペレーションのその規則的な構造および強力なセットのために、36ビットのアセンブリ言語を書くことは合理的に、中へ楽しかった。したがって、より少ない圧力はほとんどの他の機械上でよりも高いレベル言語のために存在しました。BLISSは、DECのいくつかの部分中の何人かの支持者を獲得していました。しかし、その様々な特色(例えば初期の-10のバージョンでの割り当てオペレーターのための下線の「ドット」記法および使用)は、主な抵抗を他のところに生成しました。従って、TENEXがそうだったように、新しいTOPS-20コードはMACROの中で書かれました。
During the development of release 1 and continuing thereafter, various
features were added to the MACRO programming conventions used in TOPS-20.
These were mostly implemented by macros, and they gave certain higher-level
language capabilities to MACRO. The first of these involved mechanisms for
representing data structures in one place (i.e. a "header" file) such that
the representation would cause appropriate code to be generated for
references. This started out as a simple macro to select "left half" or
"right half" of a 36-bit word (instead of an explicit HLxx or HRxx).
Next came macros to select the correct bit test instruction
(TLxx, TRxx, TDxx) for the mask at hand. Eventually, the macros were
capable of defining and representing complex multi-word record-type
structures with fields of various sizes.
リリース1の開発およびその後継続すること中に、様々な特徴は、TOPS-20の中で使用される協定をプログラムするMACROに加えられました。これらは、マクロによってほとんどインプリメントされました。また、それらはMACROにあるより高いレベル言語能力を与えました。これらの1番めは1つの場所(つまり「ヘッダー」ファイル)にデータ構造を表わすためにメカニズムを含んでいました、参考のために生成されるために表現が適切なコードをもたらすそのようなもの。36ビットの単語(明示的なHLxxかHRxxの代わりに)の「レフトハーフ」あるいは「ライトハーフ」を選ぶために、これは、単純なマクロとして外にスタートしました。次に、マスクに正確なビット・テスト命令(TLxx、TRxx、TDxx)を近づいて選ぶマクロは来ました。結局、マクロは、様々なサイズのフィールドを備えた複雑なマルチ単語レコードタイプ構造を定義し表わすことができました。
Secondly, macros were used to provide procedure-call and automatic (stack)
storage using named variables. A procedure entry point could be declared
using symbolic names for the parameters, and these names would expand
to the appropriate stack reference when used in an instruction. Similarly,
local stack storage could be defined symbolically and local registers
saved automatically. These conventions greatly reduced the occurrance
of explicit stack PUSH and POP instructions and the bugs that often
resulted from them.
第2に、マクロは変数と命名されて使用して、手続き呼び出しおよび自動(スタック)記憶装置を提供するために使用されました。パラメーターの記号名前を使用して、手続きエントリー・ポイントを宣言することができるかもしれません。また、指示の中で使用された時、これらの名前は適切なスタック参照に拡大するでしょう。同様に、ローカルのスタック記憶装置を象徴的に定義することができるかもしれません。また、ローカルの登録は自動的に保存されます。これらの協定は、明示的なスタックPUSHおよびPOP指示のoccurrance、およびそれらにしばしば起因したバグを非常に縮小しました。
Finally, macros were implemented to provide control structures without
explicit use of labels. Semantically, these resembled typical language
IF/THEN or IF/THEN/ELSE constructs, and arbitrary nesting was permitted.
As a result, a typical page of TOPS-20 code using these conventions
often contained only one label -- the procedure entry point.
最後に、マクロはラベルの明示的な使用のないコントロール構造を提供するためにインプリメントされました。意味論的に、これらは、IF/THENあるいはIF/THEN/ELSEが構築する、典型的な言語に似ていました。また、任意の巣捜しが許されました。その結果、これらの協定を使用するTOPS-20コードの典型的なページはしばしば単に1つのラベルを含んでいました。―― 手続きエントリー・ポイント。
All of this made for better programming, but it did not, of course,
remove dependence on the PDP-10 instruction set. Portability was
not an objective we thought to be concerned with until much too late.
これはすべてよりよいプログラミングのために役立ちました。しかし、それは、もちろん、PDP-10指示セット上の依存を削除しませんでした。ポータビリティはあまりにも遅いまで関係のあることを私たちが思った目的ではありませんでした。
The consequences of the ambitious set of new architectures were being felt
by the hardware engineers as well as by us in software. As schedules pushed
out, it wasn't too long before someone came up with the idea of shipping
just the KL10 as a processor upgrade for existing DEC-10 systems. Dropping
in new processors was, after all, well established, and it looked like a
source of significant revenue well before the full DECSYSTEM-20 would be
ready. As a result of this, the "1080" project and product were born.
新しいアーキテクチャーの大志を抱いているセットの結果はソフトウェアの中で、私たちと同様にハードウェア・エンジニアによっても感じられていました。スケジュールが外に押すとともに、また長く前(誰かが、既存のDEC-10システムのためのプロセッサー改良として単なるKL10を送る考えを提案した)ではありませんでした。新しいプロセッサーに落ちることは結局?Aよく確立され、重要な収入の源が十分なDECSYSTEM-20の前によく準備ができているだろうと思われました。この結果、「1080」プロジェクトおよび製品は生まれました。
The 1080 was the KL10 processor with adapters to connect to the KI10
external memories and IO bus. Neither external memory nor the IO bus were
intended to be part of the new architecture, but in the interest of
generating some revenue from the rather expensive KL10 development, the
adapters were expedited. Since the 1080 was to be sold to existing
customers as upgrades to existing systems, it would be delivered only with
the existing operating system, TOPS-10. It didn't take much work for
TOPS-10 to run on the KL10; the machine even had a mode which emulated the
KI10 paging rather than the new microcode-based paging designed for
TOPS-20. So, after all the original excitement around the marriage of
TOPS-20 and the KL10 processor, it was TOPS-10 that shipped on the first
KL10s that were sold.
1080は、KI10外部メモリおよびIOバスに接続するべきアダプターを備えたKL10プロセッサーでした。外部メモリもIOバスも、新しいアーキテクチャーの一部であるようには意図されませんでした。しかし、やや高価なKL10開発からのある収入の生成のために、アダプターは促進され?ﾜした。1080が既存のシステムへのアップグレードとして既存の顧客に売られることになっていたので、それは、既存のオペレーティング・システム、TOPS-10でのみ伝えられるでしょう。TOPS-10がKL10の上で走ることは仕事をあまりとりませんでした;マシンは、新しいマイクロコードベースのページングがTOPS-20のために設計したのではなくページをつけるKI10をエミュレートしたモードをさらに持っていました。そのように、結局TOPS-20の結婚およびKL10プロセッサーのまわりのオリジナルの興奮、それはTOPS-10でした、売られた最初のKL10sの上で送られたそれ。
The first 1080 ship in August, 1975 was the occasion for a sizable
celebration in front of the Marlboro plant. The entire 36-bit product line
had moved to the Marlboro plant in early 1974, and this meant that we had
manufacturing as well as engineering, marketing, and all other groups in
one location. Later on, this self-contained nature of the 36-bit line,
along with the fact that we continued to build an architecture more and
more out of the mainstream of the company, led some to refer to the 10/20
product line as "The Marlboro Computer Company".
1975年8月の最初の1080隻の船はマールボロ・プラントの前のかなり大?ｫい祝賀の機会でした。36ビットの生産ライン全体は1974年前半にマールボロ・プラントに移りました。また、これは、私たちがエンジニアリング、マーケティングおよび1つの位置の他のすべてのグループと同様に生産も行っていることを意味しました。後で、36ビットのラインのこの自給自足の性質は会社の主流から私たちがアーキテクチャーをますます建造し続けたという事実に?ﾁえて、いくらかに10/20の生産ラインを「マールボロ・コンピューター会社」と呼ばせました。
For the 1080 ship, most of the Marlboro groups gathered for speeches in
front of a large Digital truck bound for the first 1080 customer. Actually
the truck was empty at the time due to a few last minute snags, but
substantively the product was ready and the party commenced.
1080隻の船については、ほとんどのマールボロ・グループが、最初の1080人の顧客に向けられている大きなディジタル・トラックの前にスピーチのために集まりました。現実に、トラックは少数の最後の瞬間沈み木によりその時に空でした。しかし、名詞として、製品は準備ができていました。また、パーティーは始まりました。
Meanwhile, development continued on the DEC-20. With the new
architectures and the speed of the CPU, the system would be a great
deal more cost effective than previous systems. Because of this, the
product line delayed announcing it until shortly before it was
actually ready to ship. This all took place in January of 1976. The first
half dozen or so DEC-20 customers were carefully selected for what
would really be a field test of the new system.
その間に、開発はDEC-20を継続しました。新しいアーキテクチャーおよびCPUの速度で、システムは前のシステムより有効な大いにより多くのコストになるでしょう。このために、それ直前までそれを発表して遅れた生産ラインは、船に現実に準備ができていました。これはすべて1976年の1月に起こりました。前半ダース程度、DEC-20顧客は、実際に新システムの実地試験になるものに注意深く選ばれました。
For the first two or three years after the DEC-20 began shipping, it
enjoyed a certain amount of favor in DEC. Even at the time of first ship
however, there were clear signs that the mainstream of DEC products would
be elsewhere -- the PDP-11 family was doing very well and was making a lot
of money for the corporation, and design was already underway for the
machine that would later be known as VAX. There was a time however, when,
in retrospect, some significant history hung in the balance.
最初の2あるいは3年の間、DEC-20が出荷し始めた後、それはDECの中のある量の好意を楽しみました。第1の船の時でさえ、しかしながら、DEC製品の主流が他のところにあるだろうという明瞭なサインがありました--PDP-11家族は非常にうまくやっており企業のために多くの利益を出していました。また、設計は、VAXとしてその後知られる機械には既?ﾉ進行中でした。しかしながら、ある重要な歴史が振り返ってみると不確実な状態にあった時、時間がありました。
By 1975, it had become clear that the PDP-11 architecture had topped out.
In particular,
the address space was too limited to support many growing applications.
An effort was started to build a new machine
that would sell at the upper end of the PDP-11 price range and beyond
and would be the growth path for -11 users.
This new machine, code-named the UNICORN,
was to be based on the 36-bit architecture
since there was already a suite of software available for it.
Several of the most senior engineers in the PDP-11 groups
began coming to Marlboro to talk about building a small -10
--
small to our way of thinking, but large in comparison to the -11 line.
1975 年に、
PDP-11 アーキテクチャーは頂点に達したことが明らかになりました。
特に、アドレス空間は
多くの成長を続けるアプリケーションをサポートするためには
制限が多過ぎるものでした。
PDP-11 の価格帯の上位あるいはそれ以上で販売し、
PDP-11 ユーザのための成長パスとなる、
新しいマシンを開発する努力が始まりました。
UNICORN というコード名がついた、
この新しいマシンは
既に利用可能なソフトウェア一式が存在していたことから、
36-bit アーキテクチュアがベースとされていました。
PDP-11 グループの上級エンジニアのうちの数人が
小さな PDP-10 の開発について議論するため Marlboro に来はじめました。
--
我々の考え方では小さいのですが、
PDP-11 シリーズと比較すると大きいものです。
One upshot of this work was that
the original design for extended addressing came under review.
With more ambitious goals for business and performance,
and a greater appreciation for the pain of running out of address space,
the PDP-11 engineers insisted that
the extended addressing design be enhanced to improve ultimate effectiveness.
They convinced us that
performance should not be compromised for reasons of compatibility
or conversion as had been contemplated in the original design.
この仕事の結論の１つはアドレス拡張に関する独自の設計を検討することでした。
ビジネスとパフォーマンス、
そしてアドレス空間を使い果たす苦痛に対して十分に認識した
野心的なゴールを抱いていたので、
PDP-11 のエンジニアは
アドレス拡張の設計が最終的な効果改善をより高めることを強く主張しました。
独自の設計を検討する過程において、
互換性や変換を理由にパフォーマンスは妥協されるべきでないことを
私たちに確信させました。
A new extended addressing design emerged
which was a big improvement in the long run.
It was, however, too late to be fully implemented in the initial KL10 product.
The new design incorporated a 30-bit address rather than 23.
It also eliminated the "special execute"
because that would have added an additional cycle
to every extended reference and impacted the performance of programs
using extended addressing heavily.
Instead, compatibility was provided based on use of the address space.
The overall address space was divided into "sections" of 256 Kwords each.
In section 0, dubbed the "KI memorial section",
code would operate exactly as it had on the KI10,
i.e. with no extended addressing possible.
If the PC were in any non-0 section however,
a different algorithm for address calculation
would be used such that an extended address
(inter-section) could be generated at any time.
These differences meant that code was not strictly compatible,
but the overall style and feel was much the same.
In any given body of code,
most instructions would not need to be changed
to run in the extended environment,
so we felt we still had provided a good path for migration of existing code.
結局大きな改良だった新しい拡張アドレシング設計は出現しました。しかしながら、それは遅すぎたので、完全に初期のKL10製品の中でインプリメントすることができませんでした。新しい設計は、23ではなく30ビットのアドレスを組込みました。さらに、それは除去しました、その「スペシャル、実行する」それがすべての拡張参照に補足サイクルを加え密着させたから、その、実行、プログラム、使用する、極度にアドレスして拡張されました。代わりに、互換性はアドレス空間の使用に基づいて提供されました。全面的なアドレス空間は、256のKwordsの「セクション」に各々分割されました。セクション0のうち、「KI記念物セクション」を呼んだ、コードは作動するでしょう、正確に、それがKI10の上に持っていたとして、つまり、拡張可能なアドレシングなしで。もししかしながら、PCが任意の非0セクションにあれば、アドレス計算用の異なるアルゴリズムは使用されるでしょう、拡張アドレス(相互セクション)をいつでも生成することができるかもしれないそのようなもの。これらの違いは、コードが厳密に互換性をもたないことを意味しました、しかし全面的なスタイル、また感じる、ほとんど同じでした。コードの所定の身体では、ほとんどの指示が拡張環境の中で走るためには変更される必要がないでしょう。したがって、私たちは、存在する移住用のよいパスがコード化すると私たちがまだ規定したと思いました。
Ironically, as you may have already realized,
the UNICORN project never came to fruition.
Within a relatively short time, a conclusion was reached that,
even if a cheap 36-bit architecture machine could be built,
it would not be "culturally compatible" with the PDP-11 software
and applications and so would not meet the need.
Instead, a core group was formed to design an architecture
which would be culturally compatible with the PDP-11
but would eliminate the limitations of the PDP-11 address space.
Eventually, the machine built as a result of this effort was named VAX-11,
for Virtual Address eXtension of the 11.
As we know however,
the designers did a lot more than just extend the address space.
What is not widely known is that, for a while at least,
the VAX was planned to have 36 bits!
皮肉に、あなたが既に実現したかもしれないように、UNICORNプロジェクトは結実しませんでした。の内に、1つの、比較的操業短縮、安い36ビットのアーキテクチャー機械を構築することができるかもしれなくても、それがPDP-11ソフトウェアおよび適用と「文化的に互換性をもたず」、したがって、必要を満たさないだろうという結論は到達しました。代わりに、中核グループはPDP-11と文化的に互換性をもつが、PDP-11アドレス空間の制限を除去するアーキテクチャーを設計するために形成されました。結局、この努力の結果構築された機械は、11の仮想アドレスeXtensionのために、VAX-11と命名されました。しかしながら、私たちが知っているとともに、デザイナーが非常にちょうどアドレス空間を拡張した以上のことをしました。広く知られていないものはしばらくの間少なくともそれです、VAXは36ビットを持っていると計画されました!
Extended addressing is not the only way in which VAX impacted the first
release of the -20. By the time the -20 shipped, design was already
underway for VAX software as well as hardware. In an effort to reduce the
plethora of different command interfaces in DEC products, a committee had
been formed to specify a DEC Standard Command Language, or DCL. At the
time, existing system command languages included TOPS-10, TOPS-20,
and various PDP-11 systems: RSX, RSTS, RT-11, IAS, and others. As part
of the emerging "one system" strategy, this new command language standard
was intended to affect existing systems wherever possible and especially
to guide the implementation of all new VAX software.
拡張アドレシングはVAXが密着させたただ一つの入り口ではありません、第1のリリース、その-20.-20が船で行った時までに、設計は、ハードウェアにはもVAXソフトウェアにはも既に進行中でした。DEC製品中の異なるコマンド・インターフェースの過多を縮小するために、委員会はDEC標準コマンド言語、あるいはDCLを指定するために組織されました。その時に、既存のシステム・コマンド言語はTOPS-10、TOPS-20および様々なPDP-11システムを含んでいました:RSX、RSTS、RT-11、IASおよび他のもの。新興の「1つのシステム」戦略の一部として、この新しいコマンド言語基準は、可能なところならどこでも、既存のシステムに影響し、かつすべての新しいVAXソフトウェアのインプリメンテーションを特にガイドするように意図されました。
There were several controversial areas where the TOPS-20 example was
finally persuasive and was used as the basis for the standard. For example,
the TOPS-20 ordering of COPY (COPY from to) was adopted rather than the
assignment style (COPY to=from) of TOPS-10 and others. In one area
however, TOPS-20 agreed to a change in response to the consensus of the
committee. Up to that point, TOPS-20 had continued with the TENEX
practice of using semicolon as punctuation for the file generation number,
e.g. NAME.EXT;3 for generation 3. Rather late in the process, it was
realized that the generation didn't require a punctuation character
different from that for the extension and that it would be more economical
to use the same one, e.g. NAME.EXT.3. We agreed with that, even though it
meant changing some code very close to the date for Release 1 of TOPS-20.
Nonetheless, we did it so as not to have to face the problem of making an
incompatible change in a subsequent release.
TOPS-20例が最後に説得力があり、標準のために基礎として使用された、いくつかの論争の的になっているエリアがありました。例えば、COPY(COPY、から、に)のTOPS-20注文はTOPS-10の割り当てスタイル(=へのCOPY、から)および他のものではなく採用されました。1つのエリアでは、しかしながら、TOPS-20が、委員会の一致に応じて変更に同意しました。そのポイントまで、TOPS-20は、ファイル生成番号(例えばNAME.EXT)のために句読としてセミコロンを使用するTENEX実行を継続しました;生成3の3.プロセスにおいてやや遅いので、生成が拡張用のそれと異なる句読特徴を要求せず、同じもの(例えばNAME.EXT.3)を使用することがより経済的だろうことは悟られました。それは、非常にTOPS-20のリリース1の日に接近してあるコードを変更することを意味したが、私たちはそれに賛成しました。それにもかかわらず、私たちは後のリリースの非互換性の変更を加える問題に直面する必要がないようにそれを行いました。
Unfortunately, the developers of the VMS software had already begun using
semicolon and resisted making the change. Ultimately, the change was never
made, and VMS software shipped using semicolon. The standard was amended to
go back to semicolon, but TOPS-20 had already shipped using period. Thus,
one small opportunity for 20/VAX compatibility was missed despite our best
efforts to achieve it.
不運にも、VMSソフトウェアの開発者は既にセミコロンを使用し始めており、変更することに抵抗しました。結局、変更は行なわれませんでした、またセミコロンを使用して送られたVMSソフトウェア。標準はセミコロンに戻るために修正されました、しかし、TOPS-20は既に出荷しました、期間の使用。したがって、20/VAX互換性の1つの小さな機会は、それを達成する私たちの最良の努力にもかかわらず抜かされました。
Although the formal end of the 36-bit product family wasn't announced until
1983, life in 36-bit land seemed precarious for many years before that.
The KS10 had been built as a low-end addition to the family and
shipped as the "2020" within a year or so after the introduction of the 20
line, but that would ultimately be the last new processor to be introduced.
Several other were started however.
36ビットの製品ファミリーの形式上の終了は1983年まで発表されませんでしたが、36ビットの土地の生活はその前に長年不安定に見えました。KS10は、家族への低額の追加として構築され20行のラインの導入の後に一年程度以内に「2020年」として出荷しました。しかし、それは結局導入される最後の新しいプロセッサーになるでしょう。いくつかの他のもの、しかしながら、始められました。
One was known as Dolphin and was to be a high-end machine with performance
well beyond the KL10. However, it was undertaken as a combined 36-bit/VAX
development. That is, most of the engineering was intended to apply
equally to a VAX or 36-bit processor, and only a little bit of
architecture-specific work was supposed to be needed to turn out each
machine. This, along with the other complexities of technology and
performance goals, made for a project beyond the capabilities then
available. Costs increased and the project got bogged down. In early 1979,
the 36-bit part of the project was cancelled and only the VAX part, then
called VENUS, continued and ultimately produced the VAX 8600.
1つはイルカとして知られており、KL10を越えてよく実行を備えた高額のマシンであることでした。しかしながら、それは、結合した36ビット/VAXの開発として試みられました。すなわち、ほとんどのエンジニアリングは、等しくVAXか36ビットのプロセッサーに当てはまるように意図されました。また、アーキテクチャーに特有の仕事の少量だけが各マシンを生産するために必要であると思われました。これ、技術と実行のゴールの他の複雑さと共に、そのとき能力の向こうのプロジェクトのために作られた、利用可能。コストは増加しました。また、プロジェクトは身動きがとれませんでした。1979年前半では、プロジェクトの36ビットの部分が取り消されました。また、その後、VENUSと呼ばれるVAX部分だけがVAX 8600を継続し、結局生産しました。
Another project cancelled at around the same time was a very small PDP-10
known as Minnow. This project, operating in a small backroom on the second
floor of the Marlboro plant, had built a breadboard which was running well
enough to demonstrate some exec mode programs. It consisted of three large
PC boards: a processor board including 8 UARTS for comm lines, a memory
board, and a disk controller board. These could sit on a desk top but were
envisioned as residing in a deskside type cabinet with one fixed and one
removable disk. Had this machine not been cancelled, I believe it would
have been a significant entry in what later became the workstation market.
It was not a complete workstation, since we had not anticipated the value
in having an integrated display system, but it would have been a "personal"
machine and a product with cost/performance several years ahead of the
market.
同時のまわりで取り消された別のプロジェクトはヒメハヤとして知られている非常に小さなPDP-10でした。マールボロ・プラントの2階に小さな奥の部屋の中で作動するこのプロジェクトは、いくつかの幹部モード・プログラムを実証するほど十分によく走っていたパン切り台を構築しました。それは3つの大きなPCボードから成りました:commライン用の8つのUARTSを含むプロセッサー・ボード、メモリ・ボードおよびディスク・コントローラー・ボード。これらは机トップに座ることができたが、1を備えたdesksideタイプ・キャビネットの中に固定して、駐在することおよび1枚の除去可能なディスクとして構想を描かれました。もしこの機械が取り消されていなければ、私はそれがその後ワークステーション市場になったものの中の重要なエントリーになっていただろうと信じます。私たちが統合ディスプレイ・システムを持っている際に値を予想していなかったので、それは完全なワークステーションではありませんでした。しかし、それは市場の年(数)に先立つコスト/実行を備えた、「個人の」機械および製品になっていたでしょう。
It succumbed in part to the corporate determination to adhere to the VAX
one-architecture strategy. While the Minnow product seemed attractive, it
was decided that it would send the wrong message to introduce a non-VAX
machine in that price range. Also, the Minnow had limited support in the
10/20 groups as well. Many people saw 36-bit machines as living only in
computer rooms and surrounded with big disks and tape drives, and couldn't
figure out how a small one in an office could possibly be useful. This
seemed to be part of a larger conservatism that prevented or discouraged
significant attempts to sustain and expand the 36-bit business.
VAX 1-アーキテクチャー戦略を厳守するために、それは一部分企業決定に負けました。ヒメハヤ製品が魅力的に見えた一方、それがその値幅に非VAX機械を導入する間違っているメッセージを送るだろうことが決定されました。さらに、ヒメハヤは、同様に10/20のグループ中の支援を制限しました。多くの人々がコンピューター室にのみ住んでおり、大きなディスクおよびテープ・ドライブで囲まれるとして、36ビットの機械を見て、オフィスの小さなものがどのように、どうしても有用になりえるか考えることができませんでした。これは、防いだより大きな保守主義の一部あるいは36ビットのビジネスを保持し拡張する落胆した著しい試みであるように見えました。
Hence, by 1979, the 36-bit line had been essentially cancelled again [see
section 1.2]. However, the corporation wasn't quite ready to declare this
to the world. VAXes were doing well, but weren't quite ready to take over
all of the high-end business. It was decided in the wake of the Dolphin
cancellation to build one last PDP-10 architecture machine, to be called
the "2080". This project would be separate from any VAX development. It
would be simple, low-cost, predictable, and limited to producing a
cost-effective successor to the KL10. These limited objectives led to a
going-out-of-business mindset among the 36-bit groups. Ambitious or
long-term plans were shelved, and projects were refocussed on short term
deliverables. The only official purpose for building the 2080 was "support
the current customers", i.e. don't try to grow the business.
従って、1979年までに、36ビットのラインは本質的に再び取り消されました[セクション1.2を見る]。しかしながら、企業は、世界へこれを宣言する全く準備ができていませんでした。VAXesはうまくやっていたが、高額のビジネスのすべての上にとる全く準備ができませんでした。「2080年」と呼ばれるために1台の最後のPDP-10アーキテクチャー・マシンを構築するために、それはドルフィン取り消しの結果として決定されました。このプロジェクトは任意のVAX開発と離れているでしょう。それは単純で、廉価で、予言可能で、KL10のコスト効率の良い後継者の生産に制限されたでしょう。制限のある目的は、36ビットのグループ中の廃業する考え方に結びつきました。大がかりな計画あるいは長期計画は延期されました。また、焦点は短期のdeliverablesの上でプロジェクトに再び合わせられました。2080年を構築するためのただ一つの公式目的はそうでした「現在の顧客を支援します。」つまり、ビジネスを育てようとしません。
One area affected by this was TOPS-10 and the prospects for a one-system
strategy. While Dolphin development was going on, some effort was invested
in considering what it would take to make TOPS-20 fully capable of
supporting all the 36-bit customers. Performance studies had been done to
find areas in which TOPS-20 performance was less than TOPS-10. Networking
and multi-processing issues were considered. However, with the cancellation
of Dolphin and the going-out-of-business strategy, there was clearly no
point in working to move TOPS-10 customers to TOPS-20, so those objectives
were once again discarded. Each system group continued with the development
that seemed pertinent, in many cases doing essentially duplicate
projects for hardware support.
これによって影響を受けた1つのエリアはTOPS-10および1-システム戦略の前途でした。イルカ開発が起こっていた間、ある努力は、TOPS-20を完全に36ビットの顧客をすべて支援することができるすることが何をとるか考える際に投資されました。実行研究はTOPS-20実行がTOPS-10未満であったエリアを見つけるために行われ?ﾜした。ネットワーキングおよび多重処理問題が考慮されました。しかしながら、イルカの取り消しおよび廃業する戦略で、TOPS-20にTOPS-10顧客を移動させるために働くことには、意味は明らかにはありませんでした。したがって、それらの目的はもう一度廃棄されました。本質的に行う多くのケースに適切に見えた開発で継続された各システム・グループは、ハードウェア支援のためのプロジェクトを複写します。
Another probable casualty of limited horizons in 36-bit land was
TOPS-20 SMP. The architecture of TOPS-20 was well suited for SMP because
the needs of that style of operation were considered when TENEX was
designed. Not only would the system have readily supported SMP
timesharing, but the process structure would also have allowed user
programs to easily initiate parallel activity within a single job.
36ビットの土地の制限のある地平線のもう一人の蓋然的な死傷者はTOPS-20 SMPでした。TENEXが設計された時オペレーションのそのスタイルの必要が考慮されたので、TOPS-20のアーキテクチャーはよくSMPに適していました。だけでなく、でしょう、システム、容易にSMPタイム・シェアリングを快かった、しかし、プロセス構造は、さらに容易に単一の仕事内の並列の活動を始めるユーザ・プログラムを許可していたでしょう。
The TOPS-20 product was initially not SMP because the DECSYSTEM-20 hardware
was inherently single-CPU. With external memories, such as were used with
TOPS-10 configurations, SMP could be supported. Indeed, TOPS-10 SMP is one
of the most successful and widely studied aspects of TOPS-10. As a product
decision however, the DECSYSTEM-20 would NOT be configured with external
memory and so TOPS-20 could not be run on a hardware configuration capable
of SMP. The 2020 was also single-CPU. Dolphin was planned to be a
multi-processor machine, and SMP was included in initial TOPS-20 plans at
the time, but the Dolphin cancellation eliminated that possibility for a
hardware platform.
DECSYSTEM-20ハードウェアが本質的に単一のCPUだったので、TOPS-20製品は最初にSMPではありませんでした。外部メモリで、のように、TOPS-10構成と共に使用された、SMPを支援することができるかもしれません。確かに、TOPS-10 SMPは最も成功したもののうちの1つで、広くTOPS-10の様相を研究しました。製品決定として、しかしながら、DECSYSTEM-20は外部メモリで形成されませんでした。したがって、SMPに有能なハードウェア構成上でTOPS-20を実行することができないかもしれない。さらに、2020年は単一のCPUでした。イルカはマルチプロセッサマシ??aマシンと計画されました。また、SMPは、TOPS-20がその時に計画する頭文字に含まれていました。しかし、ドルフィン取り消しは、ハードウェア・プラットフォームのその可能性を除去しました。
Interestingly, TENEX was modified to support SMP, but not at DEC or
BBN. A two-processor KI10 configuration was assembled at the Stanford
University Medical Center, and KI-TENEX was modified to operate as a
full SMP operating system by Rainer Schultz of Stanford. This system
was operational around 1977 and some discussions were held with DEC about
adding the SMP modifications to TOPS-20. Nothing ever came of this
however, since the defined -20 hardware product never did include a possible
SMP configuration.
面白く、TENEXは、DECまたはBBNでではなく支援SMPに修正されました。2-プロセッサーKI10構成はスタンフォード大学医療センターで組み立てられました。また、KI-TENEXはスタンフォードのレイナーSchultzによって十分なSMPオペレーティング・システムとして作動するために修正されました。このシステムは1977のまわりで使用可能でした。また、いくつかの議論はTOPS-20にSMP修正を加えることに関してDECでされました。しかしながら、定義された-20のハードウェア製品が可能なSMP構成を含んでいなかったの?ﾅ、何もかつてこれに由来しませんでした。
As the 2080 project continued, it followed the long 36-bit tradition of
picking up a few "1-plusses" here and there. Before long, it had developed
some very ambitious performance projections due in large part to planned
use of pipelining techniques. The PDP-10 instruction set, being relatively
simple (although not as simple as a RISC instruction set) seemed to lend
itself to a great deal of pipelining, particularly if compilers could
generate optimal code sequences. It began to look as if the KL10 experience
might be repeated and give the 36-bit architecture a new lease on life.
2080年のプロジェクトが継続するように、それは、少数の「1-有利な条件」をここでそこに拾い上げる長い36ビットの伝統に続きました。やがて、それはパイプラインを敷設する技術の計画された使用に大部分予定されているいく?ﾂかの非常に大がかりな実行射出を開発しました。PDP-10指示セット、特にコンパイラーが最適のコード・シーケンスを生成することができた場合、比較的単純であること(RISC指示セット同じくらい単純でありませんが)は多くのパイプライン敷設ことに向くように見えました。あたかもKL10経験が繰り返されるかもしれないし、かつ36ビットのアーキテクチャーを与えるかもしれないように見え始めました、新しい寿命。
Another change to the original plan was the inclusion of the DEC
interconnect strategy then emerging. This called for mass storage devices
to be connected via the CI and HSC controllers, and other peripherals to be
connected via the ethernet. About two years into the project, the system
was redefined to use these new interconnects exclusively, discarding
support for massbus, Unibus, and other existing interconnects. The project
was renamed JUPITER, the LCG product line was reborn, and
going-out-of-business thoughts had largely vanished from the group.
オリジナルの計画への別の変更はDECの包含でした、出現して、そのとき戦略を相互に連結させます。CIとHSCのコントローラーによって接続されるために、これは、多量記憶装置およびethernetによって接続される他の周辺装置用に要求しました。プロジェクトの約2年前に入り、システムはこれらを使用するために再定義されました、新しい、massbusのサポートを廃棄して、排他的に相互に連結する、Unibus、そして他のもの、既存、相互に連結します。プロジェクトはJUPITERとリネームされました。LCG生産ラインは再起しました。また、廃業する考えは、グループから大部分は消えました。
Major software efforts were undertaken in connection with this. Beyond the
basic hardware support, we came up with the concept of the Common File
System as the means for supporting systems with multiple CPUs. Comparable
work was going on in the VAX/VMS group and came to be known as Clusters.
Ultimately, both VMS and TOPS-20 shipped this kind of capability. The
implementations were different and reflected the differences in the two
systems. VMS used a cluster lock manager as the basic method for
regulating simultaneous access to files, while TOPS-20 imbedded the locking
in the basic file opening primitive routines. The TOPS-20 implementation
also continued to use virtual memory mapping as the paradigm for
referencing files, and it is possibly the only system ever to implement
distributed shared virtual memory access.
メージャー・ソフトウェア努力はこれに関して試みられました。基礎的なハードウェア・サポートを越えて、私たちは、多数のCPUを備えた支援するシステムのための手段として共通のファイル・システムの概念に追いつきました。同等の仕事はVAX/VMSグループ中で起こっており、クラスタとして知られるために起こりました。結局、VMSおよびTOPS-20の両方は、この種の能力を送りました。そのインプリメンテーションは異なっていて、2つのシステムの差を反映しました。TOPS-20が原始的なルーチンを開く基礎的なファイル中のロックを埋め込んだ一方、VMSは、ファイルへの同時のアクセスを規制する基礎的な方法としてクラスタ・ロック・マネージャーを使用しま?ｵた。TOPS-20インプリメンテーションは、さらにファイルに参照を付けるためにパラダイムとして仮想記憶写像を使用し続けました。また、分配された共有される仮想記憶アクセスをインプリメントすることは常に恐ら?ｭただ一つのシステムです。
Once again, some ideas were generated around the possibility of moving
to a one-operating-system strategy for 36-bit machines. For a brief
period, a system somehow combining all the goodness of both TOPS-10
and TOPS-20 was envisioned. This was being called TOPS-36 so as
not to make partisans of either TOPS-10 or TOPS-20 think that it was
just the other one. How this might have come out is impossible to say,
since no planning or design beyond general scenarios was ever done.
もう一度、いくつかの考えは、36ビットのマシン用の1-オペレーティング・システム戦略に移る可能性のまわりで生成されました。簡潔な期間については、TOPS-10およびTOPS-20の両方の長所をすべてなんとかして組み合わせるシステムが構想を描かれました。これは一方のTOPS-10の信奉者にならないようにTOPS-36と呼ばれていました。あるいは、TOPS-20は、それが単に別のそれだったと考えます。一般的なシナリオの向こうの立案か設計がかつて行われなかったので、これがどのように現われたかもしれないかと言うことは不可能です。
Most of these ambitious plans got scaled back or abandoned because it
wasn't the KL10 history that was repeated by Jupiter; rather it was more
like the Dolphin history. Whether the project was "1-plussed" too much or
whether other avoidable mistakes were made can never be known for sure.
However, after having received one major extention of time and additional
infusion of development funds, the project found that it was going to need
a great deal more of both. Further, some long-delayed analysis of the
performance of certain common 36-bit instructions led to the conclusion
that overall performance would not be up to expectations. In fact, it
would hardly surpass the KL10 in some cases. It would probably have been
possible to fix those problems, but the project was already way over its
head and seemed mired in weekly schedule replans and indecisivness.
木星によって繰り返されたのがKL10史でなかったので、得られた大計画が元の通り縮小したものの中でほとんどかあるいは放棄されました;もっと正確に言えば、それはドルフィン史にむしろ似ていました。プロジェクトがあまりに「1-増されたか」どうか、他の回避可能な誤りが犯されたかどうかは確実には知ることができません。しかしながら、開発資金の時間および?竭ｫ鼓吹の1の主なextentionを受け取った後、プロジェクトはそれが両方に大量をもっと必要とするだろうということを知りました。さらに、ある共通36ビットの指示の実行のある長く遅れた分析は、全面的な実行が期待までなかったという結論に結びつきました。実際、それはある場合においてKL10をほとんどしのがないでしょう。それらの問題を解決することは恐らく可能?ｾったでしょう。しかし、プロジェクトは既にその頭に関する方法で、毎週のスケジュール再計画およびindecisivnessの中で泥で汚されたように見えました。
The early popularity of TENEX on the ARPANET
was certainly a key to its later acceptance, transformation,
and support as TOPS-20 by DEC.
That popularity in turn seems
to have been based not only on its technical features
but also on the fact
that it was developed within that community and was responsive to it.
When TOPS-20 became a DEC product,
it became part of a much larger market
and thus less responsive to any particular segment of the market.
ARPANETの上の TENEX の初期の人気は明らかに
その後の支持と変化、そして DEC による TOPS-20 としてのサポートの
鍵となりました。
言い換えると、
その人気はその技術的な特徴だけでなく、
コミュニティーの中で開発されており、
コミュニティーの要求に敏感に反応していたという
事実に基づいたように見えます。
TOPS-20 が DEC の製品になった時、
コミュニティーははるかに大きなマーケットの一部になりましたし、
マーケットの中のどのような個別のセグメントに対しても反応は鈍くなりました。
In addition to that,
as interest in other computer architectures increased in the late seventies,
many research sites came to the conclusion
that they did not want to be dependent on any one vendor
for either hardware or software and, instead,
wanted "open" systems which would be amenable
to local modification and evolution.
This of course led to a rapid increase in the use and popularity of Unix.
The fact that Unix was implemented in a reasonably portable language
(at least as compared with 36-bit MACRO)
also encouraged its spread to new chip architectures and beyond.
If I could have done just one thing differently
in the history of TENEX and TOPS-20,
it would be to have coded it in a higher level language.
With that, it's probable that the system,
or at least large parts of it,
would have spread to other architectures
and ultimately survived the demise of the 36-bit architecture.
それに加えて、
1970 年代末には他のコンピューター・アーキテクチャーへの関心が増加したので、
多くの研究サイトはハードウェアもソフトウェアも任意の１社のベンダーに依存せず、
代わりにローカルでの修正や発展に柔軟に対応できる「オープン」なシステムを
求めるという結論に達しました。
もちろん、これは Unix の人気とその利用の急速な拡大に結び付きました。
(少なくとも 32-bit MACRO と比較して) Unix が合理的でポータブルな言語
で実装されているという事実は Unix を新しいチップアーキテクチャへ
普及させることを促進しました。
もし私が TENEX と TOPS-20 の歴史の中で１つだけ違うことができるとしたら、
高水準言語でコードを書くでしょう。
そうすることで、
システム全部、あるいは少なくともその大部分は他のアーキテクチャーに広がり、
結局 36-Bit アーキテクチャーの崩壊から生き残れた可能性が高いでしょう。
Much of the success of TOPS-20 and other 36-bit software is the result of
qualities that came out of the interactive environments in which it was
built and used. Over the last 10 years, the driving force in interactive
environments has been moving computer power closer to the user via
personal computers and workstations. For TOPS-20 to have remained in
the forefront of interactive development and use, 36-bit hardware platforms
would have had to be built that were small and cheap enough to go into the
office, or the software would have had to be portable enough to move to
other such platforms.
TOPS-20および他の36ビットのソフトウェアの成功の多くは、それが構築され使用された対話型の環境から出て来た特質の結果です。過去10年にわたって、対話型の環境中の推進力は、パソコンとワークステーションによってユーザに近いコンピューター力を移動させていました。TOPS-20は対話型の開発および使用の最前部で残ったために、オフィスに入るように十分に小さく安かった36ビットのハードウェア・プラットフォームは建造されなければならなかったでしょう、あるいは、ソフトウェアは他のそのようなプラットフォームへ移動するように十分にポータブルでなければならなかったでしょう。
Although this book is about DEC's 36-bit architecture, it is clear now that
hardware CPU architectures are of declining importance in shaping software.
For a long time, instruction set architectures drove the creation of new
software. A new architecture would be introduced, and new software systems
would be written for it. The 36-bit architecture was large in comparison to
most other systems which permitted interactive use. It was also lower in
cost than most other systems of that size. These factors were important in
the creation of the kind of software for which the architecture is known.
この本はDECの36ビットのアーキテクチャーに関係していますが、ハードウェアCPUアーキテクチャーがソフトウェアを形作る際に重要を断わることであることは今明らかです。長い間、指示セット・アーキテクチャーは、新しいソフトウェアの生成を運転しました。新しいアーキテクチャーは導入されるでしょう。また、新しいソフトウェア・システムはそのために書かれるでしょう。36ビットのアーキテクチャーは、対話型の使用を許したほとんどの他のシステムへの比較において大きかった。さらに、それは、そのサイズのほとんどの他のシステムよりコストにおいてより低かった。これらの要因は、アーキテクチャーが知られているソフトウェアの種類の生成において重要でした。
Now, new architectures are coming along with increasing frequency, but they
are simply "slid in" under the software. The software systems are far too
large to be rewritten each time, and a system which cannot adapt to new
architectures will eventually suffer declining interest and loss of
competitive hardware platforms. TOPS-20 didn't pass that test, although
it did contribute a number of ideas to the technology of interactive
systems. How far these ideas ultimately spread is a story yet to be
told.
さて、新しいアーキテクチャーは周波数を増加させることと共に来ます。しかし、それらはソフトウェアの下で単に「滑られる。」ソフトウェア・システムは大きすぎるので、毎時間書き直すことができません。また、新しいアーキテクチャーに適合することができないシステムは結局傾く興味および競争率の高いハードウェア・プラットフォームの損失を。それは対話型のシステムの技術に多くの考えを寄付しましたが、TOPS-20はそのテストに合格しませんでした。これらの考えがどれくらいの距離結局広がるかは伝えられるためにまだ物語です。