[Info-vax] Dave Cutler, Prism, DEC, Microsoft, etc.

[Tim E. Sneddon]

Bob Gezelter wrote:
> In any event, the use of MACRO-32 is not the impediment. It has been
> proven twice (e.g., ALPHA, Itanium) that a compiler can be
> straightforwardly constructed to convert MACRO-32 in to the native

I think that might be a bit of a stretch of the meaning of
straightforward.

> binary needed. In fact, having worked on portable code generators
> during my university research time, I could observe that one could

Portable code generators almost always go:

     High-Level-Language --> Intermediate-Language --> Machine-Code

They rarely go back the other way.

> write a MACRO-32 -> C translator, which would then "solve" the initial
> problem of getting onto a new architecture. Admittedly, such a
> bootstrapping approach has efficiency issues, but they can be dealt
> with.

I think that might be a pretty *huge* generalisation there.  Source
to source translating is not generally a big task (depending on the
languages), but certainly going from machine level to a high level
language is.  I think there would be much more than some "efficiency
issues".  There especially needs to be careful consideration of the
target architecture's calling standard and how it compares to the
source.  As I am sure you are aware writing code in assembly allows
the coder to do all sorts of neat "tricks" that just cannot be
replicated by a high level language.

Actually, a recent post by VAXman is the perfect example.  It sites
a piece of code that passes information through registers R1-R3.
How do you translate that to a HLL like C using a compiler and
without significant hand-made changes?  You couldn't even move that
to BLISS without a special linkage definition that would need to
be hand constructed.  How can you pass out-of-band information on
an architecture that doesn't have enough registers?

Tim.