~ wrote:
It could be called i64 to make completely clear that it would only run in 64-bit mode, such as the i386 was the first to give access to full 32-bit mode.
Well, gee, they could call it "IA-64" instead... oh, wait, they did that once already... yeah,
as I have said more than once before, what Intel (and pretty much everyone else) actually wants to do is throw the x86 in a hole and cover it up with cement. They have
tried to do this three times already (the
iAPX 432 - before the 8086 was even released! - the
i860 RISC, and IA-64, aka
Itanium, the failure of which came to be referred in the tech press as "The Sinking of the Itanic"
even before it was released, and while it is still in production, it never made much headway even in the server market it was designed for) and ended up crawling back to it, because the PC software market was a mess and no one wanted to throw away all the existing code for what would be, to the end users, a negligible improvement if any.
And to preempt the obvious counter-claims:
- "oh, you just recompile" mindset many here seem to have, is not a simply task for most software that isn't limited to using a very narrow subset of POSIX, and does nothing hardware-specific or OS-specific - in other words, any non-trivial software that wasn't written with portability in mind from the outset.
- "cross-rebuild" - cross rebuilds are a fantasy, especially if you are talking about doing it from the executable rather than the source code. While it isn't impossible to disassemble/decompile a program, then do most of the translation of the code to a different platform and/or OS, and manually fix it for rebuilding, it isn't practical - the translation would need a tremendous amount of clean-up, efficiency would drop through the floor, and any hardware-specific parts would have to be rewritten to match the original - a re-write makes more sense.
- "use emulation" - Aside from the inevitable drop in efficiency (even when combined with cross-rebuilding), it runs into problems of inconsistent hardware implementations across the PC world, and the loose standards for software compliance under Windows and MS-DOS. Apple got away with it (twice, which is positively amazing) because they tightly controlled the Macintosh hardware and software, and even then about 15% of the software base had to be scrapped or re-written on each of the transitions. For Windows, that figure would probably be closer to 75%, including nearly all the games.
- "move to a pseudo-machine (JVM, CLR, whatever)" - that just re-frames the problem, replacing a hardware target with a software one, and while it would make sense for the next round of hardware changes, for this one you need to do the same things you would need for a change of hardware platform. The same applies to any kind of portable executable, regardless of how it is translated into working code - it only helps with new software, not existing programs.
I agree that Intel will, eventually, move to a completely new instruction set architecture, and as far as I am concerned, it cannot happen soon enough. The chances are that they will indeed switch soon, especially now when ARM systems vastly outnumber x86-64 ones (albeit not on the desktop), but people have been looking for that switch to happen for over twenty years. The inertia, both in terms of users and in terms of companies, is enormous, and it probably will take some sort of crisis with the production of x86 processors (e.g., a design or performance roadblock that can't be overcome) to actually set it in motion.