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

[ChrisQ]

On 12/08/11 22:30, John Reagan wrote:

>
> 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.
>

I never did any alpha assembler, but did do a little on vax. Can only 
say that
the instruction set capabilities were bountyfull, to say the least. 
pdp11 was
a trivial architecture in comparision. A very complex instruction set, 
not to
mention the calling mechanisms, condition codes and that's without even 
thinking
about any fpu capability. All this would need to be handled by a virtual 
machine
or native compiler / assembler. o/s tools may get you part of the way 
there, but
there are probably too many missing links in the chain right now.

If hp had the will, then it would get done, but with the apparent 
running down
of the high end at hp in favour of consumer electronics, I won't be 
holding my
breath...

Regards,

Chris









>
>
>
>
>