🚀 go-pugleaf

The object code recompilation is implicitly assumed to be
intra-architecture, only, or intra-architecture-family at best. The
goal would be to take advantage of, e.g., new registers, different
pipe delays and the like. Translation of z80<->6502 is a red herring
in this context.

The reason that this is interesting is that:
	(a) as brian case pointed out, register loads/stores occur at
	    different pipe slots, and thus are advantageous even w.r.t
	    to on-chip cache designs.

	(b) It's been stated that the MIPS design can be justified by
	    ``well someday, we'll have more registers if we need them'',
	    which begs the question of ``oh yeah, well how will old
	    code use them'' (usually mentioned by register window fans).

Things people have pointed out by mail:

(1) Yuke, more versions of binaries? Each re-compiled binary will take more
    disk space.

	Sadly, this is true, but you wouldn't have to recompile *everything*,
	since few programs are really CPU bound anyway.

(2) Software Management Nightmare. Would vendors still support those .o files?
    What about bug reports, warrenty?

	Good point, and probably, from a commerical standpoint, the strongest.

(3) Why not just recompile the source?

	Another good point. Since you're usually not given the .o files
	anyway, and if you are, you're probably also given the source,
	or should be able to convince the .o provider to recompile for you.

Although I realise this might jyst be a case of ``The Boss Expositing
At A Talk,'' would anyone at MIPS care to join the frey?
--
Dirk Grunwald
Univ. of Illinois
grunwald@flute.cs.uiuc.edu
--
Dirk Grunwald
Univ. of Illinois
grunwald@flute.cs.uiuc.edu