🚀 go-pugleaf

In article <7628@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
I wrote:
>>However, leading-edge hardware seems hard-pressed to maintain binary
>>compatibility very far backwards.
>
>Examples, please?  Yes, MIPS, SPARC, and HP-PA have all introduced
>additional user-mode-visible features to their architectures, but they
>haven't, as far as I know, invalidated any *old* stuff (other than

Will MIPS, SPARC, or HP-PA CPU run any binary compiled before the year
1985? That is what I meant by "very far backwards". (See that I
qualified my claim with "seems": I don't claim to have expertise
here.)

Here is another question for the comp.arch pundits:

Are we likely to see the fastest CPU in year X being able to run,
without change, a binary program more than 5 years old? (Does HP-PA
do this right now? If so, I am very impressed. I would be much more
impressed if it could also run the large existing libraries of 
CISC binaries at full speed, but that would be asking quite a bit :-)

Already, I have seen claims (possibly biased) that SPARC is now
sacrificing performance to maintain compatibility, and will therefore
not reach the top of the RISC pile again. Is this inescapable? Must
advancing hardware technology always obsolete software?

Would someone like to plot each leading CPU's performance vs. the age 
of the oldest compiled binary each CPU can run (at all)? Express CPU 
performance both as absolute, and normalized by clock rate, if possible.

My hunch would be that the chips with the shortest history of binary
compatibility tend to be the fastest, especially when normalized by 
clock rate.


--
Dan Mocsny				
Internet: dmocsny@minerva.che.uc.edu