[Info-vax] If I wanted to get there, I certainly wouldn't start from here (was: Re: VMS on a PC)

[johnwallace4 at yahoo.co.uk]

On Jan 19, 11:27 pm, "Richard Maher" <maher... at hotspamnotmail.com>
wrote:
> Hi John,
>
>
>
> > As I've said before, Macro-32 is the real bottleneck.  Besides redoing
> about
> > 1/3 of the compiler (the same 1/3 redone from Alpha to I64), you have to
> > come up with some mapping of the registers used by the current code base
> > (code currently assumes registers R0-R31 are available in some fashion).
> > Try mapping that onto the 16 registers in the X86-64 architecture and get
> > that to work with linkages to C/BLISS; exception handling; unwinding; etc.
>
> Again just idle curiosity, but would a lot of these problems go away if one
> were porting VAX/VMS to X86 rather that Alpha or I64? I guess there's just
> so much software and new versions that just never made it to VAX, but would
> CISC to CISC have been a more straight forward exercise? Surely after
> anything-to-EPIC, everything else has to be easy?
>
> FWIW, I vote a big yes for JF's dead-horse! But where would they find the
> resources for such a project?
>
> Cheers Richard Maher
>
> PS. Presumably after BLISS on VMS for I64, a "supported" BLISS for Windows
> I64 would not be out of the question? Does Microsoft not bother with a
> Windows version for Itanium any more? Does Rdb no longer induldge their
> fantasies with that Rdb for NT Workbench thing? Did anyone (apart from Rdb
> Engineering) ever really want Rdb on Windows anyway? And who really cares?
>
> "John Reagan" <johnrrea... at earthlink.net> wrote in message
>
> news:OrmdnbhjUqgxCunUnZ2dnUVZ_vjinZ2d at earthlink.com...
>
>
>
> > "Alan Winston - SSRL Central Computing" <wins... at SSRL.SLAC.STANFORD.EDU>
> > wrote in messagenews:00A85C81.E779B5E0 at SSRL.SLAC.STANFORD.EDU...
>
> > > Wasn't there an 8086 port of Bliss for Windows NT?  (I think it's even
> on
> > > the freeware someplace.)
>
> > Yes.  However, it was truely X86-only.  Knew nothing about the 64-bit
> > extensions to the architecture (additional registers, additional
> > instructions).  Didn't generate ELF object files.  Conformed to the
> Windows
> > calling conventios.  And was only a subset of BLISS.  Features not used by
> > GEM or Visual Fortran (or Rdb) were not implemented.  Beyond that, the
> > X86-variant of GEM also didn't include features used by languages other
> than
> > BLISS or C.  For instance, all the packed decimal stuff used by COBOL or
> > varying-length strings of Pascal was just stubbed-off.
>
> > As I've said before, Macro-32 is the real bottleneck.  Besides redoing
> about
> > 1/3 of the compiler (the same 1/3 redone from Alpha to I64), you have to
> > come up with some mapping of the registers used by the current code base
> > (code currently assumes registers R0-R31 are available in some fashion).
> > Try mapping that onto the 16 registers in the X86-64 architecture and get
> > that to work with linkages to C/BLISS; exception handling; unwinding; etc.
>
> > John

"Does Microsoft not bother with a Windows version for Itanium any
more?"

Nominally they do, but I suspect the answer you get to that question
very much depends on who you ask, and how much context they have.

I recently wandered into an HP/Intel presentation from HP-UX's 25th
anniversary (in 2008),  titled "Itanium - The Road Ahead". I saw the
PDF version which as I write this is "under maintenance" (I didn't
keep a copy) but the Googlecache [1] still contains an HTMLised nearly-
readable version.

Much of the presentation goes through the usual routine of why
"industry standard, open" (!) Itanium is better than "proprietary,
closed" RISC, mainframes, Power, Sparc, etc. Then miraculously it
briefly makes a leap of faith to how Itanium is also wonderful for
Windows, without making much of an attempt to explain why any real IT
department who wants Windows would actually want Windows on Itanium
rather than on x86-64.

Yes there is brief mention of *huge* systems (ie more than the 32 CPUs
and 512(?)GB memory that today's Proliant can handle) needing Itanium
but anyone who's ever looked at Windows reliability and scalability
will know that something other than Windows is likely a good choice in
boxes of that nature, so the question of Windows on boxes of that size
doesn't really arise very often in the real world.

I think there was a chart in there which showed the split of Itanium
shipments (and/or applications) by OS. Unfortunately I can't see it in
the HTMLised version and I can't remember whether Windows was visible
or invisible.

Microsoft's main "Windows on Itanium" page seems to be [2].

Some of us have been here before, e.g. those who were around during
the brief era of Windows on big Alpha (eg SAP on Windows on
Turbolaser, etc). Putting Windows on a big boys' computer didn't make
it a big boys' OS back then, and it probably doesn't do it now
either. .


[1] http://209.85.229.132/search?q=cache:x0bcUZ-qaU0J:h50025.www5.hp.com/ENP5/Admin/UserFileAdmin/EV/25758/File/1211_03.pdf

[2] http://www.microsoft.com/servers/64bit/itanium/overview.mspx