[fpc-devel]Re: Latest status

Sebastian Kaliszewski Sebastian.Kaliszewski at softax.com.pl
Tue Nov 27 13:24:41 CET 2001

From: "Florian Klaempfl" <Florian.Klaempfl at gmx.de>
> No. The AMD hammer support even hasn't started :/ though it shouldn't that
> hard ...
> I really don't know if it is worth to support both architectures (and we
> don't have so
> much time to support everything :/ ). I can't believe that (on the long
> run) both will survive.

We'll see. Do not underestimate installed base if x86 applications. IA64
implementations are very, very bad at executing x86 code. x86-64 is naural
extension, there should be no performance penalty for legacy code. And
adding support to the stuff should be ways easier (esp. in 32bit adressing
mode with 64bit registers).

> I still think that the ia64 is a really good architecture for the next 20
> years, so ...

There are serius issues about this stuff. To sum that up: the innards of the
CPU are very complex, and this design does not lend itself easily anything
like dynamic execution. With new techniques like on chip SMT (Symmetric
multi threading) with shared resources and other - OoO - used by the
majority of top performing architectures (Alpha, PA RISC, both x86 current
incarnations, Power PC and last but certailly not least new Power from IBM)
it does not yield best promise from IA64. BTW -- the design of the thing has
started back in 1994 before ANY dynamic execution CPU was released -- the
outcome was then unknown, and complexity of the dynamic execution seemed to
be bottleneck in the future. Now it apeared that complexity of OoO is not
that bad, classic VLIW never went out of signal processing niche (with the
rather failed exception of Transmeta) and VLIW boosted to apropriate
performance (IA64) is more complex inside than OoO chips. Adding SMT or even
worse DMT (Speculative threads) would raise the complexity, size and power
draw to unseen levels.

So don't put your bets yet.

More of this stuff shows sometimes on hardware architecture newsgrouops and
Web BBs...

Sebastian Kaliszewski

More information about the fpc-devel mailing list