[Info-vax] Reading Gordon Bell's VAX strategy document

gah4 gah4 at u.washington.edu
Sun Sep 24 12:20:15 EDT 2023


On Sunday, September 24, 2023 at 7:10:45 AM UTC-7, John Dallman wrote:

(snip)

> As of 1978/70 they had achieved this and were deciding what to do next. 
> The strategy expressed in this document is to continue to sell the other 
> ranges, but concentrate development efforts on the VAX family, and that's 
> what basically happened. Using a single architecture is seen as a 
> competitive advantage against IBM's proliferation of incompatible 
> architectures, which is pretty reasonable, since IBM saw the same problem. 

(snip)

> The idea of running VMS on a terminal with a total of 64KB of RAM and ROM 
> in 1982 seems implausible now, but it seems to have been the reason for 
> 512-byte pages. Bell praises the extremely compact VAX instruction set 
> and its elaborate function calls, without appreciating the ways they will 
> come to inhibit pipelining and out-of-order execution, and thus doom the 
> architecture to uncompetitive performance. 

I was thinking not so long ago, and wrote it into some thread, about how
bad VAX design is for pipelining and OoO execution.

A tiny change would have made a bid difference, if someone thought
about it earlier. 

The way VAX addressing modes work, is each operand has a mode byte
followed by any offsets that go with it.  Then the next mode byte and offset.
If instead, all mode bytes were together, followed by the offsets, it
would have been much easier to do OoO processing.

The most important thing you want, when you start reading an instruction,
is to know where the next one is.  For IBM S/360, you always know from the 
first byte where the next instruction is.  Even with the above change, it isn't
easy for VAX, but would be close. 

You could put the first 8 or so bytes in a register, and then enough logic
to decode the address mode bytes, and know where the next one was.

VAX is very well designed for serial, microprogrammed processing,
where you read a mode byte, process it along with its offset, then go on
to the next one.  There are probably even better ways to change it, but
that one would have been (if done early) so easy, and yet wasn't.

VAX is also nicely designed to make it easy for assembly programmers,
just at the time that just about everyone was moving away from assembly
programming.  And the 512 byte page size was too small.






More information about the Info-vax mailing list