[Info-vax] Running OpenVMS native on x86 . . .

[John Reagan]

"JF Mezei" <jfmezei.spamnot at vaxination.ca> wrote in message 
news:4ee11d94$0$32073$c3e8da3$40d4fd75 at news.astraweb.com...
>
> Seriously though, and not to support any conspiracy stuff but...
>
> Instead of writing a Macro 32 compiler for x86, would it be even
> possible to build a macro library for the x86 assembler so that Macro32
> code would be translated to x86 code by the x86 assember ?
>
>

You mean the gas assembler you'd get from binutils, yes?  gnat has the 
Itanium version buried in their toolchain.  I suppose you should be able to 
host the x86 version on OpenVMS Alpha or OpenVMS Itanium.  binutils is very 
flexible on having cross tools.

I don't think a pure macro library would be sufficient.  Look at the Macro 
compiler's support of VAX float and VAX packed decimal instructions.  Those 
are done with a set of macros.  They come very close to being like 
opcodes/operands built into the parser, but not quite.  There are some 
differences outlined in the manual.

Plus a full implementation using only macros would have a difficult time 
dealing with condition codes (especially when branches are involved).  The 
floating/packed macros set condition codes by emitting various TSTL 
instructions which then get the right condition code support out of the 
Macro compiler's real code generator [which includes a flow analyzer to 
detect loops so we can get the condition codes across loop edges as well as 
handling various argument list constructs].

Now, could you cut the Macro compiler apart from GEM and generate x86 
assembler output? (again, assuming you have an assembler), sure I guess so 
(you lose GEM for creating DWARF and unwind descriptors for instance).

You could use gcc for the C code (well, until you bump into one of those 
ugly #pragma linkage directives for example).

But you're then stuck on getting a BLISS compiler which uses much more of 
GEM.  Having GEM generate x86 assembler output VS generating a binary .obj 
file is almost the same amount of work.  GEM on Tru64 did support -S to get 
an assembler file output when specified although I don't think it produced 
DWARF in the .s file.  It was never enabled/supported on OpenVMS, but the 
infrastructure [probably very fragile] is there somewhere.  So, you're back 
to needing a GEM for x86 and we've travelled full circle.  It's deja vu all 
over again.

Alternatively, you could think about hooking a BLISS frontend to gcc but 
you'd have to deal with all those GLOBAL REGISTER definitions scattered 
across all those funky linkages.  Not rocket science, but you'd end up 
having to touch LOTS of the Macro-32, BLISS, and C code.

And then having compilers, doesn't magically solve any calling standard 
issues and the register mapping issues recently discussed.