Summary of DEC 32-bit machine.
- DMR, from notes by JFO [Joe Ossanna]
(DEC confidential--subject to non-disclosure agreement)
[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
Its speed, in native mode, is "between 1 and 2 times the 11/70."
[It wasn't. On programs that didn't need much memory an 11/70
was noticeably faster.]
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.
[It was considerably more, actually.]
We could get a machine on a field test basis toward the end
[We didn't, in our group; another research group at Bell Labs
did, and produced Unix 32/V, direct predecessor to the UC Berkeley
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.
Instruction set architecture.
The machine is byte-addressed, with a 32-bit virtual address.
It handles the following data formats:
[Here I delete a long section describing data formats,
address modes, and instructions. It is pretty much
correct; Joe must have taken excellent notes.]
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
[ 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.]
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.
[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
There are lot more miscellaneous instructions.
[things like insque and find-first-set; I omit.]
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
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
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
(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.
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
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
This might indeed be pretty messy.
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.
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.