🚀 go-pugleaf

In article <RFowler.319@kelvin.jpl.nasa.gov> RFowler@kelvin.jpl.nasa.gov (Robert A. Fowler) writes:
   In article <1992Aug6.183140.10233@ennews.eas.asu.edu> hougland@enuxha.eas.asu.edu (Kriss A. Hougland) writes:

   >>  But the Intel handouts show a RISC processor in there, and imply large
   >>gains in performance if you "simply recompile for maximum performance."
   >                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   >This is almost always true for any CPU that is backwards compatable.
   >In general, trace flow, branch prediction, variable lifetime analsys and
   >lots of other good compiler optimizations are now happening.  Heck, 
   >recompiling the original program on a "good" modern compiler can do
   >wonders.
   >I also think that they mentioned something to the effect that just
   >recompiling to the 486 would yield a signifciant performance increase.

   Being an end user, rather than primarily a software deveolper, I see a need 
   for a machine-code optimizer that can take an .exe file compiled with a (old|
   diferent cpu optimized) compiler and reshufle the instruction order for best 
   performance on an [i386|i486|P5], especialy since the vast majority of MS 
   Dos programs are still compiled for the 8088 (for backwards compatiblity).

   Does anyone make such a package?  (I know there are major differences in 
   the native modes of these processors, but some improvement should still be 
   possible with out totaly rewriting the code.)

There used to be a package for porting old 8085 8-bit software to the
new 8086/8088 which did a binary conversion of the object code.
There is also at least one company that "recompiles" binary DOS
programs to run on SUNs or other RISC processors. Usually this is not
a 100% job, but requires a bit of handwork too.

The OSF and others are looking into a binary distribution format that
specifies an binary machine language, that is then recompiled into
native machine code on installation (sort of like p-code, but the
p-code is then compiled, not interpreted). For this to work well, the
abstract CPU has to be rather powerful and contain an unlimited number
of registers for example. The intermediate code compiler then assigns
those registers to physical registers if possible and to memory
otherwise. A lot of the modern C compilers like GCC work that way too.
The trouble with the 486 is that it doesn't qualify as a generic or
abstract CPU and it would require quite a lot of "expert knowledge"
within the machine code translator to come up with semantically
equivalent yet better code. It's a lot easier to do optimization when
you have the source code. To get more than peephole optimization you
need abstract CPU binaries.

Another problem is "tricky" hand assembled code which abounds in the
PC world. Things like self modifying code and jump tables assembled on
the fly are often impossible to translate. While it should be possible
to write a 386 to 486 converter which takes certain i486
characteristics into account, the speed improvement would probably not
exceed 15%. Assuming that the P5 will get it's speed from being a dual
issue machine it should be possible to write a converter that
reschedules i486 instructions so that they are less likely to cause
pipeline stalls. Still a good C compiler is likely to do a better job
and might be less difficult to program.

Just some thoughts, Tom
---
Thomas M. Hoberg   | Internet: tmh@first.gmd.de
1000 Berlin 41     |           tmh@cs.tu-berlin.de
Wielandstr. 4      |
Germany            | BITNET:   tmh@tub.bitnet 
+49-30-851-50-21   |