Re: SGI files for chapter 11

Dan Foster wrote:
In article <4c9mm2F14tvo9U1@xxxxxxxxxxxxxx>, Bill Gunshannon
<bill@xxxxxxxxxxx> wrote:

I have every confidence the good folks in VMS engineering would have
no great difficulty doing this port if asked.

While I have no doubt that the VMS engineers are a rather remarkable
collection of Computer Scientists, I would not go so far as to say
they "would have no great difficulty" doing the port. For a long time
people ran around saying VMS would not run on x86. If that was true,
not enough has changed to actually make a port easy.

Well, x86 has grown up a bit since Project Emerald. :)

For instance, 64-bit x86 these days has 16 64-bit GPRs (general purpose
registers), at least 16 SIMD registers (a mixture of 64 and 128-bit),
and some additional registers that aren't either GPRs or for SIMD.

In comparison:

VAX had 12 32-bit GPRs (encompassing both integer and floating point)
and no SIMD.

Alpha had 32 64-bit integer registers and 32 64-bit floating point
registers. It also had SIMD starting with PCA56 (and for EV class,
starting with EV6).

IA-64 has 128 82-bit floating point registers and 128 64-bit integer
registers. I'm not sure about SIMD status, offhand.

Clearly, even modern x86 falls short of both Alpha and IA-64.

HP also has experience in doing special magic tricks in the compilers
and back-ends to remap or insert synthetic code to take place of an
actual physical register (at expense of some performance). Mr. Reagan
wrote about some of these in a past HP Technical Journal.

While x86-64 is clearly better than the VAX for the registers, it may
not be sufficiently significantly better.

I bet it *could* be made to work on x86 if given sufficient interest and
money, but would guess it'd still be rather painful.

-Dan


I hope we've all read the excellent Technical Journal V6 article about
the porting:

<
http://h71000.www7.hp.com/openvms/journal/v6/porting_openvms_to_integrity.html


.

Relevant Pages

  • Re: SGI files for chapter 11
    ... they "would have no great difficulty" doing the port. ... x86 has grown up a bit since Project Emerald. ... and some additional registers that aren't either GPRs or for SIMD. ...
    (comp.os.vms)
  • Re: non load/store architecture?
    ... Programmers can write great code on a RISC ... Especially in a PC marketplace dominated by the x86. ... Lots of registers and an orthogonal instruction set are important - both have these. ... The lack of registers means much more memory IO, which causes stalls and requires complex scheduling. ...
    (comp.arch.embedded)
  • Re: New itaniums out at 2.5x perform gain
    ... stuff installed and running on VMS. ... somehow easier to port it to x86-64. ... Given that active investigation of porting VMS to x86 was actually under way in the early '90s, suggesting that there's any insurmountable obstacle involved seems a bit unreasonable - especially now that x86 has become 64-bit. ... Alpha sales at this point in time is a very wrong mistake). ...
    (comp.os.vms)
  • Re: Intel publishes Larrabee paper
    ... Using x86 as the base it is understandable that the third vector operand ... 32 registers times 4 sets, plus some rename registers and you are ... visible registers your actual register set becomes large, ... The die size tradeoffs of 4 way multi threading is mostly about reducing ...
    (comp.arch)
  • Re: Switch from SBCL to Erlang backend due to scalability issues(GC).
    ... to the SBCL developers saying that they don't use a precise GC on x86 ... should be more likely that their stack locations have to be touched ... than on architectires with more registers. ... and initializing all those stack locations would ...
    (comp.lang.lisp)