From: jgd@cix.co.uk   
      
   In article <10ac7ph$2nnj7$1@dont-email.me>,   
   clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:   
      
   > Especially given that z/OS is actually several years older than VMS   
   > and is still going very strongly indeed.   
   >   
   > Could VMS still have been as strong to this day if different   
   > decisions and paths in the past had been taken ?   
      
   Possibly, but one can't be certain what different decisions would have   
   that effect, and there's a substantial element of luck in these matters.   
   Here's my bid:   
      
   The VAX instruction set is quite nice in some ways and quite horrible in   
   others. Some of those made it hard to make run very fast.   
      
   The extremely variable-length instructions are a prime example. In   
   contrast to VAX, the IBM Z instruction set only has three instruction   
   lengths - 2, 4 and 6 bytes, which has not changed since System/360 - and   
   you can always discover the length of each instruction from its first two   
   bytes. That makes having multiple instructions being decoded   
   simultaneously easier, which is a bottleneck in x86 and x86-64, the other   
   long-lasting CISC instruction set.   
      
   The relative simplicity of the IBM Z instruction set probably derives   
   from the greater abstraction in its design process. IBM tried to design   
   it without considering implementation very much, because they were   
   producing five initial implementations. These had a speed range of 30:1,   
   using quite varied technology.   
      
   There's one place where IBM paid too much attention to implementation:   
   the hexadecimal floating point. It was picked because it allowed a   
   simpler shifter for normalisation, but caused excessive loss of precision.   
   That was a bad idea, no matter how much IBM tried to hide the problems,   
   and limited their mainframes in technical computing. They added IEEE   
   floating-point in System/390, but that was far too late.   
      
   In contrast, the VAX instruction set was likely designed in parallel with   
   the 11/780, and is pretty much built around the concept of a microcode   
   implementation running one instruction at a time. It did get floating   
   point right, though.   
      
   VAX was replaced by Alpha because there was no way to make VAX fast   
   enough to compete with the RISCs of the late 1980s and early 1990s. A   
   different VAX that could use out-of-order execution effectively might   
   have been able to compete. If so, that would have enabled DEC to stay in   
   its technical computing niche, instead of switching to the commercial   
   data processing market in time to be slaughtered by Wintel.   
      
   Our alternate history VAX would then have had to be extended to 64-bit.   
   This was possible for System/390 and x86, so it might well have been   
   possible for alt-VAX. If DEC had still been financially healthy, there   
   could have been a proper 64-bit VMS API, rather than the half-done   
   mixture that was implemented in our history.   
      
   I talked to a colleague, who returned to my employer after a takeover,   
   and remembers our business in the early 1980s. He's perfectly clear that   
   VMS was a far better OS for technical computing than any of the   
   proprietary minicomputer OSes of the time, all of which are dead. But VAX   
   couldn't match the performance of high-end 68000 Unix machines, followed   
   by the RISCs, and the rest is history.   
      
   John   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)