Haley: We're doing an ARM64 OpenJDK port!

I work on ARM stuff, so you can call me biased, but I certainly don't expect it to end up that way. Itanium's fault wasn't that it diverged from the older 32 bit architecture, but that it did a lot of extravagant things that had not been tried before in mainstream computing and that turned out to be a bad design choice in hindsight.

64-bit ARM is by comparison the most boring architecture you can imagine, it takes the 32 bit design, and replaces most of the oddities of that architecture with more common ideas from other RISC designs. Nothing to see here really, and that's how we like it!

few differences:

1) During Itanium time, people still had lots of binary-only proprietary server applications, thus binary compatibility was much more needed. These days most server apps are in some kind of interpreted languages (java, php, python, ...). Also, many people will porting to Arm64 from mips, ppc, x86, etc, so break between a32 and a64 is not relevant to them.

2) While lack of proper backward compatibility was one reason of Itaniums demise, the other was just pure business failure. Itanium was just too expensive, Opteron and Xeon offered much better bang for buck. The whole idea was "Let's make people replace expensive UNIX RISC servers with expensive Itanium servers running UNIX". Customers were more like "Umm no thanks, let's rather replace them with cheap x86_64 servers running Linux". A lot will depend on what bang/buck and bang/watt a64 offers compared to competitors.

AArch64 actually gives me a lift whenever I see it, because I read the Arch not as the sterile-as-hell 'Architecture' but as a callback to ARM's youth, Acorn: "Archimedes'. And those were lovely machines.

(Sure, it isn't, but we can pretend it is.)

MIPS is an interesting case. MIPS has had a 64-bit design for a long time, and it's not bad, mostly. Unfortunately, its memory model suffers from the same problems as the Alpha: you can't count on anything happening in order, as seen from another processor, so you can't program a MIPS SMP without somebody else making guarantees beyond the architecture spec. x86 has the opposite problem: it promises so much that a 16-way x86 might spend most of its time waiting at barriers for memory state to settle, just in case. The Power64 and Itanic designs hit workable (but different) compromises. We can only hope the AArgh64 architects took advantage of hindsight, because without it maybe only Power64 has MP legs.

Ah! MIPS, yes I did forget that. Though I wonder if that's my fault, or a reflection of MIPS completely disappearing from the radar (other than in a few niche markets).

ARM is as bad at that as Sun. The ARM11, which is an ARMv6, is older than the A5, which is an ARMv7. If you compile something for ARMv7 or later, it will not run on an ARM11. And do not confuse ARMv7 with ARM7 - the later is an ARMv3, or later an ARMv4 or ARMv5.

The ARMv7 family has the A5, A7, A8, A9, and A15. Let's hope it does not get near A32, else things will get even more confusing.

Debian and Ubuntu are calling the arch 'arm64'. The upstream GNU triplet remains 'aarch64-linux-gnu'.

If you really care there is a doc somewhere carefully distinguishing the names of the architecture, 64-bit instruction set, 32-bit instruction set, etc. But I reckon most people without marketing droids standing behind them will just call it arm64 (or armv8).

I've been having fun with bootstrapping: http://wiki.debian.org/Arm64Port

You can install a quantal amd64 chroot with cross toolchain and start building stuff.

Linaro have OE image builds that can be run on ARM's free-beer 'Fast' Model (which is not at all fast) http://www.linaro.org/engineering/armv8