[presumably the agreement has expired by now!]
[おそらく現在、契約は期限切れになっているでしょう]
The project is called `VAX'-- Virtual Address Extension.
The first hardware is called `STAR' (unoriginal name!) and the operating
system STARLET.
Its speed, in native mode, is "between 1 and 2 times the 11/70."
プロジェクトは
VAX -- Virtual Address Extension
呼ばれています。
第１のハードウェアは「STAR」(独創的でない名前!)
およびオペレーティング・システムSTARLETと呼ばれています。
その速度はネイティブモードにおいて 11/70 の １〜２倍です。
[It wasn't. On programs that didn't need much memory an 11/70 was noticeably faster.]
[これは誤りでした。 メモリをあまり必要としないプログラムでは、 11/70 のほうが明らかに速かったのです]
The speed emulating an 11/70 in user mode is about that of an 11/70.
The cost is intended to be comparable to an 11/70.
ユーザー・モードで
11/70
をエミュレートする速度は、
11/70
のそれに関係しています。
コストは
11/70
と比較できる程度に収まる予定です。
[It was considerably more, actually.]
現実には相当に高額でした。
We could get a machine on a field test basis toward the end
of 1977.
1977の終わり頃、
フィールドテストの形で
私たちはマシンを手に入れることができました。
[We didn't, in our group; another research group at Bell Labs did, and produced Unix 32/V, direct predecessor to the UC Berkeley distributions]
[それは、 私たちのグループではなく、 ベル研究所の別の研究グループが行い、 UC Berkeley distributions の直接の祖先となった Unix 32/V が開発されました]
I don't know when regular deliveries are scheduled.
They are now "past the breadboard stage;" which seems to mean at least
that they have at least one machine electrically,
but not mechanically, the same as the final version.
I gather that a "field test" machine is free but of course it
is likely to be used for training FE's and would not be our own.
いつ正式な出荷が予定されているか私は知りません。
現時点では実験段階を過ぎています;
電気的には１台のマシン、
しかし機械的にはそうでない、
最終バージョンと同じことを
意味するように思えます。
フィールドテスト用のマシンは自由に使えますが、
それはもちろんフィールドエンジニア(FE)の訓練のために使用され、
私達のものにはならないであろうと推測しています。
The machine is byte-addressed, with a 32-bit virtual address.
It handles the following data formats:
マシンは
バイトでアドレスされ、
32ビットの仮想アドレスが使えます。
それは次のデータ・フォーマットを扱います:
[Here I delete a long section describing data formats, address modes, and instructions. It is pretty much correct; Joe must have taken excellent notes.]
ここにあった データ・フォーマット、アドレス・モードおよびインストラクションを記述した 長いセクションはは削除しました。 それはほとんど正確です; Joe は優れたノートをとったに違いありません。
Calls. The machine has a built-in calling sequence.
I'll try to reproduce it exactly.
Briefly, though, it appears to be possible to do just what C wants.
I'll try to make clear just what the hardware does do that it can be
checked.
Calls.
マシンはコーリングシーケンスが組み込まれています。
私はそれを正確に再現するつもりですが、
概ね、それは単に C が望むことを行うことができるように見えます。
私はハードウェアがちゃんとチェックできるかどうか確認するつもりです。
[ Here there is a long, essentially correct, description of 'calls' and 'callg' and how to use them--access arguments, allocate and refer to locals, and so forth.]
[ここに 引数へのアクセス、 ローカル領域の確保と参照など、 概ねに正確な 'calls' と 'callg' の長い説明がありました]
As a side note, SCJ [Steve Johnson] with some advice from me has just written
a description of what C wants from a calling sequence
and what it is forced to take on some machines.
So far as I can determine, this organization embodies every desirable
feature that was imagined by us and several more besides.
I am astonished at how well it is designed, particularly considering
that this is the same company that gave us the `mark' instruction.
サイドノートとして、
SCJ [Steve Johnson]
は
私からいくつかの助言を得て、
Cがコーリングシーケンスに望むもの、
および幾つかのマシンに積み込まざる
得ないものについて説明を書いています。
私が決定することができる限り、
この構成は私たちが思い描いた、
あるいはそれ以外のいくつかの
すべての望ましい特徴を具体化します、
特にこれが私たちに 'mark' 命令を与えたのと同じ会社であること考えると、
私はそれがどれくらい上手に設計されているかに驚きます。
[1999 addition: although it's not remarked upon in the 1988 netnews posting, my gushing admiration of the VAX calling instructions is one of the things most attackable from the RISC perspective, and in fact we and others discovered that even on VAX it was possible to call faster with the simpler instructions.]
[1999年の追加: 1988年にネットニュースをポストされる際それは注意されませんが、 VAX の呼び出し命令に対する私の感情に任せた賞賛は、 RISC の観点から最も攻撃可能なもののうちの１つで、 実際、私たちやその他の人々によって VAX の上でさえ、 より単純な命令で より速く呼び出しを行うことが可能であることを発見しました。
There are lot more miscellaneous instructions.
様々な命令がたくさんがあります。
[things like insque and find-first-set; I omit.]
[insque や find-first-set のようなものまで; 省略します]
Memory mapping and system features.
メモリのマッピングとシステムの特徴
This area is rather complicated and somewhat less nice.
The virtual address is 32 bits (maybe it was really 31,
but it hardly matters).
The high order bit selects "system" or "program" space;
this has no protection implications, but does help determine the style of mapping.
The next bit selects "program 0" or "program 1"
if the "system" bit is off.
"System" plus the "program 1" bit is undefined and reserved.
The machine is paged, but not segmented, except
that the three legal states of the program bit with the system bit
select one of three page tables.
The page size is XX bytes.
[Note that either we missed hearing this or they didn't say!]
Suppose an address lies in system space.
Then the YY bits below the S and P bits are used to look up in a
system page table; its base is stored in a hardware register
and there is a limit.
The page table word (discussed more below) gives the physical
address.
The system page table lies on a physical page boundary.
If the address is in program space, the page number is looked up
in either the p0 or p1 page tables.
The base and limits of both of these are in hardware registers,
however the base is not a physical address but is mapped according to the
system address space.
Incidentally, the P1 page table goes backwards in memory.
One thinks of a P1 address as a moderately small
31-bit negative number.
The page table word ultimately accessed has a present bit, 4 bits
(15 states) of protection information,
and a physical address.
I don't know the size of the bit bield, but it is generous
compared to the 2MB of memory that can be attached to the machine
at the moment.
There is a "modified" bit but no "accessed" bit.
The machine is designed for virtual memory.
Any instruction can be restarted.
They don't promise that if you look at the detailed
state of things when a page-fail interrupt occurs
you will see anything interesting; just that you get the virtual
address of the failing reference,
and that the instruction can be restarted from the beginning
with the right results.
The implication is, that things work right, but that all pages
referenced by an instruction must be in core for the whole
instruction.
You can't step through a piece at a time.
Thus there is theoretically a minimum set of pages that have to be present
and it is not entirely trivial (perhaps as big as 20)
for some of the odder instructions.
There are four protection domains, something like kernel,
executive, supervisor, user.
The latter three cannot execute privileged instructions
and in general they claim attempts have been made to
prevent a less privileged domain from interfering with a more privileged.
The 15 states in a page table word somehow encode
a nested set of access rights to the page.
This must be some subset of the cross product (read, write [,execute?])X(k,e,s,u).
I don't know the details.
One hopes it is sensible.
The design of the user-available instruction set is
is one of the most attractive I have ever seen.
We could not investigate all the nooks and crannies,
but it appears to be extremely regular in its treatment of both operators
and operands; this tends to make a compiler's code generator
simple
(and thus more nearly able to approach optimality).
DEC claims that despite the doubled number of bits in the virtual
address space, the size in bytes of programs should approach
that of the 11.
I intend to investigate this with C outputs,
but I am inclined to accept the claim.
The architecture loses bits in most address modes (which occupy
at least one byte, and sometimes several more),
but gains in being able to express small displacements from registers
and small literals.
For example, to load a small constant, or a value at a small
displacement from a register, takes three bytes on VAX and four
on the 11.
ユーザーが利用可能な命令セットのデザインは
私がこれまで見てきたものの中では
最も魅力的なもののうちの１つです。
私たちはすべてのすみずみを調査することができませんでした。
しかし、それは、オペレーターおよびオペランドの両方の
その処理に対して非常に規則的に見えます;
これはコンパイラーのコード・ジェネレーターを単純にする傾向があります。
(そして、それにより最適にアプローチすることができます)
DECは
仮想のアドレス空間のビット数が２倍になったにもかかわらず、
プログラムのバイト長は PDP-11 のそれに接近するべきであると主張します。
私は C の出力でこれを調査するつもりですが、
私はこの主張を受け入れます。
アーキテクチャーは
ほとんどのアドレス・モードでビットを
(少なくとも１バイトを占め、時にはさらに幾つかの)無駄にしますが、
レジスタおよび小さなリテラルから小さな置換を絞ることができる場合には
増加します。
例えば、レジスタからの小さな置換で
小さな定数や値をロードするのに
VAX
の上では３バイト、
PDP-11
の上では４バイト
かかります。
Some care will be needed to produce programs in which all the
addresses have minimal length.
Fortunately, the same techniques which we use on the Interdata
remain applicable.
アドレスがすべて最小の長さを持っている
プログラムを生成するためには注意が必要でしょう。
幸運なことに、
私たちが
Interdata
の上で使用している技術は適用可能です。
The memory mapping is not so good, mainly because it
does not seem easy to use the very large virtual address space.
If information is placed at random the page tables become
huge (2^21 words!).
However, the user page tables can themselves be paged,
and this may provide an out.
I asked Steve Rothman why they did not go to a segmented scheme,
and the reply was that the overhead
(presumably on address-cache misses)
seemed too large.
I should have investigated this further,
because I don't believe it.
He may have had in mind segmentation
combined with full mapping of the user
addressing tables.
This might indeed be pretty messy.
主として非常に大きな仮想アドレス空間を使用することが容易には見えないので、
メモリマッピングはそれほどよくありません。
情報が任意に置かれる場合、
ページ・テーブルは巨大に (2＾21 words!) なります。
しかしながら、
ユーザ・ページ・テーブルは
それ自身をページ化することができ、
外に放り出すことができるかも知れません。
私は
Steve Rothman
に
何故
segmented scheme
へ向かわないのか尋ねました。
返答は
オーバーヘッド(おそらくアドレスキャッシュのミス)
が大き過ぎるように見えるとのことでした。
私はそれを信じていないので、
これをさらに調査するべきでした。
彼はユーザ・アドレシング・テーブルの完全なマッピングと組み合わせた
セグメンテーションを考えていたかも知れません。
確かにこれは厄介です。
They talked some about software.
It was rather depressing.
Most of it will be emulated.
(Presumably in a 2MB machine you will still have to tell the
assembler how big a symbol table to use.)
The system itself will be new, but unimaginative.
They did not seem to understand,
for example,
why or even how the command interpreter
should be a separate process and not in the system,
and why commands themselves should be processes.
They are also still stuck mostly in assembly language.
There are companies that
are learning about how to write software,
but DEC is evidently not one of them.
彼らはソフトウェアに関していくらか話しましたが、
それはかなりガッカリさせるものでした。
ほとんどが (過去の DEC の OS を) エミュレートしたものでしょう。
(おそらく２ＭＢのマシンでは、
どれくらい大きなシンボル・テーブルを使用するか
アセンブラーを伝えなければならないでしょう)
システム自身は新しいですが、想像力に欠けているようです。
例えば、
何故、コマンド・インタープリタをシステムに組み込むのではなく、
個別のプロセスにしなければなければならないか、
あるいはそのためにはどのような方法をとるべきなのか、
更に何故コマンド自体はプロセスでなければならないか
を理解しているようには見えませんでした。
さらに、
まだほとんどがアセンブリ言語で立往生しています。
ソフトウェアを書く方法について学んでいる会社がありますが、
明らかに
DEC
はそれらのうちの１つではありません。
My general impression is that this is a remarkably good machine.
DEC talked about lots of other features, such as the physical
design, self-checking, and subset isolation;
at least they were soothing to hear.
It sounded pretty good, but it's hard to know how it will work
out in practice.
私の一般的な印象は、
これが著しくよいマシンであるということです。
DECは
物理的な設計や自己診断、
subset isolation
などその他の多くの機能について話しましたが、
少なくとも、それらは穏やかに聞くことができました。
それはかなりよく思えましたが、
実際にそれがどのように出てくるのかを知ることは困難です。