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.