On Wednesday 15 June 2005 22:10, Bryan J. Smith wrote:
> > EM64T is AMD64 compatible
>
> <Anal>EM64T is compatible with a _subset_ of AMD64T</Anal>
>
> EM64T still currently runs on Intel 32-bit AGTL+ interconnect. There are
> some serious limitations to the physical interconnect _outside_ the CPU
> -- both the "memory hub" approach as well as legacy AGTL+ addressing
> issues, especially for I/O. The "dumb hub" and 32-bit addressing
> limitations are why EM64T processors lack some serious features of AMD64,
> like the I/O Memory Management Unit (MMU).
<even more anal>Except the iommu, those are limitations of chipset, bus and
whatever, not EM64T.</even more anal>
> AMD64 is based on Digital 40-bit EV6 interconnect. It is capable of safe
> memory addressing up to 40-bit/1.1TB (1TiB) for _both_ programs _and_
> memory mapped I/O. Intel proponents downplay this feature, but it's very
> much a major different in the Linux/x86-64 kernel.
EV6 is what slot/socket A was all about... The Athlon64 and Opteron (which
just happen to implement the AMD64 instruction set) use HyperTransport. The
instruction set has nothing to do with the interconnect - PowerPC and a whole
bunch of other very use specific chips use hypertransport.
>
> > Xeon's aren't compatible with ia64
>
> IA-64 is a completely different architecture, byte code, etc...
>
> <flammatory>IA-64 deploys CS ideals such as EPIC and Predication, things
> that are designed to address limitations with optimizing machine code at
> the compiler-only. The reality is that machine code (like boolean
> logic, long story) are legacy 1970s concepts for integrated circuits
> designed by CS majors, before physicists and engineers took over in the
> 1980s. You can't optimize math and algorithmic approaches that aren't
> ideal at the semiconductor-level anyway, and run-time optimizations in
> the processor design itself are the best way along with an optimizing
> compiler that leverages those tricks (especially in the x86 future of
> virtual cores of virtual, out-of-order PAE36/PAE52
> machines).</flammatory>
Nice flame - but has very little to do with real world. the IA64 architecture
got the basics right... The reason for the low performance of Itanium chips
(low as in real world performance compared to what it could do theoretically)
are because of the immaturity of the chip (not nearly as tweaked as a P4 is)
and platform (slow memory and then you expect great benchmark scores?) as
well as some really really really stupid decisions. Like allocating too few
bits for the template... but these things are simply bad decisions on how to
implement it, not something wrong with VLIW architectures in general. In
fact, if you look at the Itanium chips, they are very RISC like. To the point
where a lot of guys say its a risc core with a VLIW decoder in front of it...
and that the VLIW decoder happened to be the main issue is, at least to me,
hysterical.
Peter.
