🚀 go-pugleaf

[]
In article <blahblahblah (John R. Levine) responds to my defense of
the VAX as merely a product of its time, rather than a bad design

>....  The architecture was predicated on a
>technological bet that microcode memory would always be faster than regular
>memory, and when that turned out to be wrong the penalty for the heavily
>microcoded implementation that the Vax demands has become very large.

>Also, it has the distinct flavor of having been designed by a bunch of guys
>sitting around saying "yeah, that would be nice, we'll put it in microcode...
>I don't doubt that the OS and compiler guys were in on the design, but a
>little more scepticism about what the software guys asked for would have
>helped a lot.

Well, technological bet sounds a bit worse than technological prediction.
They may have predicted wrong, but they based the design on a prediction, 
rather than just design it according to what was around then. And they did
ask OS & compiler guys what they wanted. Both of these may be considered
innovations, AT THE TIME THE DECISIONS WERE MADE. Now, they're trite.

>For comparison, consider the considerably older IBM 360 architecture.  They
>made a few real goofs, notably 24 rather than 32 bit addresses...

Actually, we could spend a lot of time dicussing /360 architectural goofs.
Like, no PC relative branches. Like, no immediate operations...

>There are relatively few instructions that nobody uses (MVZ and LNR,
>perhaps.)

I think instruciton frequency lists might prove you wrong. The top 10 insts.
account for 90% of the executed insts., like all other machines. This leaves
a lot of those instructions used almost never.

>IBM has certainly had more success with really fast 360s than DEC
>has with really fast Vaxen. 

They sell them for a LOT more money, too. Perhaps even DEC could come up with
a fast VAX if it sold them for $2 mil.

--
		  baum@apple.com		(408)974-3385
{decwrl,hplabs}!amdahl!apple!baum