[Info-vax] Compilers and architectures

[johnwallace4 at yahoo.co.uk]

On Jan 20, 1:07 am, "John Reagan" <johnrrea... at earthlink.net> wrote:
> "JF Mezei" <jfmezei.spam... at vaxination.ca> wrote in message
>
> news:0060f0dd$0$10083$c3e8da3 at news.astraweb.com...
>
> > (subject renamed from some meaningless one)
>
> > John Reagan wrote:
>
> >> The fact that Itanium is EPIC doesn't really matter to most code other
> >> than
> >> compilers or those brave few who want to write Itanium assembly for
> >> performance reasons
>
> > In the case of VMS to Alpha, is it correct to assume that they had to
> > build Alpha cross compilers on VAX-VMS so that they could generate a
> > minimal VMS binary and then boot it on Alpha ?  (since there were no
> > tools yet available on Alpha and there were no other OS running on Alpha
> > at the time).
>
> Correct.  We had VAX-hosted/Alpha-target cross-compilers for the
> VAX-to-Alpha port; and Alpha-hosted/Itanium-target cross-compilers for the
> Alpha-to-I64 port.
>
>
>
> > In the case of a theoretical port to a 64 bit 8086, would they build
> > such cross platform compilers on Alpha or IA64 VMS to generate the early
> > 8086 VMS binaries ?
>
> > Or would they use existing Intel compilers on windows/linux to compile
> > and generate the early VMS binaries for 8086 ?
>
> Since the cross-compilers would need access to source files that currently
> exist in CMS libraries on ODS-5 structured file systems, using a non-VMS
> hosted compiler makes your job worse.   Using VMS-hosted compilers leverages
> existing code and command files that knows how to use RMS/DCL/CMS/etc to
> open/read/write/close files, process command lines, etc.
>
>
>
> > And once you havce a minimal VMS running on the 64 bit 8086, how
> > difficult is it to port 8086 compilers written for linux or windows over
> > to VMS ? Is it mostly just adding the vms-style command line parsing and
> > the logic to search include files in libraries and/or directories  with
> > the rest more or less unchanged ? or are there significant compiler core
> > changes needed for VMS ?
>
> Which compilers are you suggesting?  Do you want/need a binary translator?
> Do you want/need VAX-floating support?  Do you want/need traditional Calling
> Standard features like an architected argument-count register?  Want your C
> compiler to be able to use special linkages to the Macro-32 and BLISS code?
> (We would.)   All of which does ripple through the compiler.  Glueing on
> command line parsing, #include processing, etc. is just the tip of the
> iceberg.
>
> The language RTLs would need work if you want any sort of multi-language
> exception handling support.  I'll guess any library you pull from a Linux
> box doesn't know much about signal/mechanism arrays or things like
> SYS$UNWIND.
>
> John

So, perhaps not surprisingly, life would be marginally easier tacking
an AMD64 back end onto current VMS compilers, which have already gone
through the retargeting more than once, and using those retargeted
compilers to (re)implement current VMS RTL technology as far as
possible, rather than starting from (say) gcc and libc and building
VMSness into them (that sounds like an uphill battle).

Multi-language exception support? Dunno about Linux, but Windows has
only just got around to a "common language runtime" aka language-
independent runtime, almost thirty years after VMS had it. So that
kind of thing presumably has to come from new ports of the VMS calling
standard and new ports of VMS RTLs, along with everything else that
people developing software for VMS have come to know and love.

The shortage of registers in AMD64 is a shame, how on earth did people
survive on PDP11s with only six (or maybe five) user-usable
registers...