Re: Apple, Jobs, and the irony of it

[mjmahon@aol.com (Michael J. Mahon)]

Supertimer wrote:

<snip>

>The Opteron runs 32-bit applications in a 32-bit mode
>natively.  That is, it can crunch x86 code.  Opteron
>was built upon the Athlon K7 but has been extended
>to 64-bits (x86-64).  G5 does the same thing with
>32-bit code designed to run on the G4 processor.
>This is no less emulation than a IIGS 65C816 chip
>running 8-bit 65C02 instructions.  In all cases (G5,
>Opteron, 65C816), the code is run natively.
>
>Itanium2 has a completely new instruction set.
>It is a VLIW chip and it runs x86 32-bit software
>the same way that the Transmeta chip does,
>translating x86 instructions in real-time into the
>native IA-64 instructions.  If you have every seen
>a Transmeta based PC, you will know how much
>more slowly this kind of emulation works than
>the native processing an Opteron, G5, or 65C816
>can perform for older code.

There is a certain irony here, in that both AMD and Intel
implementations of the IA-32 architecture, in their current
32-bit chips, do not run the IA-32 instructions "as written".

All modern implementations of the decidedly non-modern
IA-32 architecture gain speed by translating the IA-32
instructions into something much like non-optimalVLIW
code, to get better execution parallelism.

The reason that IA-64 makes sense is that it eliminates
the "middle man" of obsolete IA-32 code in this process,
removing architectural and implementation bottlenecks
and permitting much faster program execution (in native
IA-64 mode).  (BTW, the first Itanium processor was the
first of a new kind, and, like the first waffle, is not the
exemplar of what will follow.  Itanium 2 is much better,
even in a non-cutting-edge technology.  Future versions
will reveal the architecture's potential.)

Running IA-32 code is a "transition" problem, which will
vanish just as the problem of running Mac 68K code has
vanished as a performance issue.

The IA-32 instruction set architecture is very long in the
tooth and is a serious obstacle to obtaining the highest
possible performance from a given amount of silicon.
Although it may seem convenient at the moment to
compromise a chip's performance to obtain "native"
compatibility with old code, this is, in fact, mortgaging
future performance forever, when in a few years the
value of "compatibility mode" performance will be nil.

Evolutionary solutions to problems seem better until
you consider the cumulative effect of many layers of
"evolution" versus designing a new solution which is
more nearly optimal for near-future technology.

Computer scientist Brian Randell remarked many years
ago that "A philosophy of evolution, not revolution, is
actually a philosophy of fewer and bloodier revolutions."
When the compromises to retain compatibility with a
20-year-old architecture become so onerous that they
decrease execution efficiency by a sizable factor, it's
time to reconsider the architecture.

Virtually all applications today are coded in high-level
languages, so the cost of recompiling them for another
architecture is very low.  In fact, the biggest cost is in
simply _having_ two versions during the transition period.

Apple managed their transition with a far-suboptimal 68K
compatibility mode, but they made it just fine within 2-3
years, and I think most Mac users would agree that the
pain was well worth it.  I believe that PC users will be
just as pleased when given the chance.

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page:  http://members.aol.com/MJMahon/