🚀 go-pugleaf

>>[Dirk Grunwald's (Hi Dirk!) comments on Hennessey's comments about
>>binary translation]

>To take the impossibles first, I would be really impressed if anyone can
>take the context switching code for one machine and translates it into
>functional context switching code for a different machine.

Hennessey, and anyone else considering binary translation, was talking
about translating the binaries for *application* programs, not things
like OS kernels.

>There are, however, valid uses for object translators. For example, Hunter
>systems will translate MS-DOS programs to run on Unix boxes. From what I
>understand, this is done for support cost reasons! It is cheaper for a
>software house to support one version for MS-DOS than it is to support
>multiple versions for different systems. This is strictly a support cost
>vs. translation cost trade-off. I have not heard performance or optimization
>as a sales pitch for Hunter systems. Anyone with better knowledge?

I have done some insulti, I mean, consulting for Hunter Systems (but only
mundane things).  It is true that some of their customers are interested 
in keeping their support problems minimized.  Translating one version for
many hosts is better than supporting many versions.  XDOS can do quite
well with respect to performance, at least compared to the dynamic schemes
used to Phoenix and Insignia Solutions.

Hunter Systems XDOS is *not* an automatic translator.  It requires "key
files" that are nearly completely human generated (or at least human
supervised).  This is because automatic *static* translation is *impossible*
without more information than is present in executable images.  Some
people appear to be addressing this issue somewhat by retaining more
info in the executable.  I've written about this before; if you want to
know more, let me know.  (The hard problem is indirect branches.)

> It would also be interesting to look at the complexity of an "Optimizing
>Translator". Any OT would first have to discover the real intent of the
>program, then optimize it for the new architecture. This is a much harder
>problem than an optimizing compiler where the source code is available.
>Consider all the work that has gone into language design to make it easy
>for compilers to optimize!

This is why I was calling for one or a few "universal" (boy, is that an
overworked term) intermediate langauges to be used for application
distribution.  This would allow much more freedom for the development of
new architectures.  This would keep us all in business!

>Basically, the object code (for any architecture) is a very poor medium
>for communicating algorithm or program intent. Most emulators have trouble
>just faithfully micmacing the target system! Optimizing translators sound
>very hard to me. :-)

Well, I've written a couple of optimizing translators.  They can be
straightforward or very complex, depending on the architectures in question.

Object code is a poor intermediate language (which is what they are being
asked to be with respect to object code translation).  One way to look at
optimization is that its purpose is to lose information.