Petz,
I am not really much of a low level programmer. Maybe Mike (minnow68) or the other Mike (mozek) can comment.
I just checked, and I just realized that there already is a way to deal with 64 bit integers in MMX. If you look at this document:
amd.com
which is "AMD64 Architecture Programmer's Manual Volume 5: 64-Bit Media and x87 Floating-Point Instructions" Document 26569, there are instructions such as:
MOVD instruction, page 63, which can load from regular 32 bit registers to 64 bit (or lower 64 of 128) MMX registers or from memory location. AMD extends these a bit apparently.
PADDQ page 84 - can add 2 64 bit integers
PSUBQ page 232 - you can guess.
Anyway, this is very barebones, it could be extended a bit with more instructions, but the downside is that these instructions don't participate in program flow the way normal registers do. They need to be moved to MMX registers, and moved back all the time, can't be used in comparisons, as indexes to arrays, or counters etc.
So Intel would really need to change the ALU for the claim of 64 bitness to have any legitimacy, which makes the whole thing less like an extension, and more like another mode of operation, something on the level of Long / Compatibility mode in Opteron. Whether it can be made into an extension of regular 32 bit Windows XP, subset / superset of AMD64 Windows, or something entirely seperate, I am not sure.
But my argument is that if it is not a full 64 bit implementation, it means that Intel is putting even more eggs in the Itanium basket, because with an incomplete 64 bit Xeon extension, failure of Itanium would leave Intel without any 64 bit option to battle AMD64.
That's why my opinion is that Intel will not do a partial extension, but will stick with IA64 / x86-32 for as long as possible, and when IA64 failure is imminent, they will introduce a full fledged 64 bit x86-64 CPU, either AMD64 compatible or not. And if IA64 looks like it has legs, then no action by Intel is needed.
Joe |
