🚀 go-pugleaf

In article <GRUNWALD.89May9113443@flute.cs.uiuc.edu> grunwald@flute.cs.uiuc.edu writes:
>
>In his picture, when you have a new architecture with, say, more registers,
>different delay costs or deeper pipelines, you translate your .o files and/or
>your final binaries. This is essentially what scoreboarding is doing, albeit
>dynamically. There are some limits to this approach, some obvious, some not
>so obvious.
>
>Comments?

Well, it would depend a lot on how much you expect the object translator to
do. Somethings are clearly impossible, some may be just inefficent and some
may even be useful. 

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. Similarly, there
are many problems for which optimal solution requires different algorithms
for different architectures. Yes, I would be impressed if someone can take
i860 code and translate it for Z80.

Just to show that this comparison of Z80 and i860 is not silly, consider the
Chess programs. For quite a long time, the best chess programs were written
by a husband & wife team (I forgot their names) for Z80 (or is it 6502?)
chips. The commercial products (the Chess challengers, I think) would 
compete with the programs running on Cray's and other supercomputers. Do
you seriously think an object code translator could achive the performance
on a 6502/Z80?

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?

As far as object translation as related to comp.arch, I think it is at best
a kludge. Some architectures may well need it since as you (or Hennesy) 
point out, different delay costs and lack of scorboarding make life very
interesting over the long term.
 
 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!

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

Stanley Chow        BitNet:  schow@BNR.CA
BNR		    UUCP:    ..!psuvax1!BNR.CA.bitnet!schow
(613) 763-2831		     ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public
I am just a small cog in a big machine. I don't represent nobody.