Supporting 64-bit ARM systems

Posted Jul 11, 2012 3:27 UTC (Wed) by jzbiciak (guest, #5246)
In reply to: Supporting 64-bit ARM systems by ringerc
Parent article: Supporting 64-bit ARM systems

Disclaimer: I haven't read the ARMv8 docs yet. (Still wrapping my head around v7.)

My understanding is that ARM generally has kept pretty strong source-level compatibility, and that includes at the assembly level (a few esoteric CPxx registers notwithstanding). So, if I've optimized some algorithm in ARM v5 assembly, lets say, I have a pretty good chance of running that code on ARM v7 with at most a recompile, but quite likely just a relink.

That's at least my understanding. If that weren't true, then it seems like ARM could have shed more baggage more often. After all, ARMv7 still "supports" Jazelle (albeit with a "null" implementation) for example. Why would it need to, unless there's the expectation of running some ARMv5J binaries?

If the ARMv8 AArch64 code is as different as everyone's saying, then it's not clear that you'll be compatible at the assembly level at all. You may be compatible at the C/C++ level, except in cases where pointer sizes break you. Porting may be vaguely sane, but I suspect still a bigger chore than moving among existing 32-bit ARM variants.

In any case, I imagine the first year or two of ARMv8 hardware will come with 32-bit OSes, or at least 32-bit userlands on 64-bit kernels if ARMv8 supports that, until the software stabilizes.

I guess it's time for me to start reading up on ARMv8, eh? *sigh* I just finished absorbing a couple thousand pages of docs on ARM Cortex-A15 and the current round of AXI/ACE protocols....

Supporting 64-bit ARM systems

Posted Jul 11, 2012 3:55 UTC (Wed) by ringerc (subscriber, #3071) [Link] (1 responses)

Thanks for that. I didn't realise that ARM arches retained such a high level of source compatibility despite continually breaking binary compatibility.

I've only dealt with ARM in a few areas like mutex/locking asm helpers, where the best sequence to use is different for different sub-architectures.

I can see that the break of source compatibility would make v8/ARM64 a bigger challenge if perfect source-level ASM compatibility has been the norm up until now. It still sounds more like an ia32-to-x86_64 move than an ia32-to-itanic move, though.

Supporting 64-bit ARM systems

Posted Jul 11, 2012 7:09 UTC (Wed) by cmarinas (subscriber, #39468) [Link]

The assembler syntax is different. It has some similarities for a few mnemonics but you cannot compile one into the other (like we could do with the Thumb-2 unified syntax). The register names are different: R0 on 32-bit vs X0 on 64-bit. Even the comment syntax has been changed from "@" to "//" (because of some clashes of the former).

Supporting 64-bit ARM systems

Posted Jul 17, 2012 21:58 UTC (Tue) by Tuna-Fish (guest, #61751) [Link] (1 responses)

ARMv8 really is that different. As 64-bit forced break in backcompat, they got rid of everything they felt was not a good idea in a modern instruction set. Gone are the multiple load instructions, simd on gprs and conditions on everything. Instead, we now have a zero reg and 31 gprs, IP and SP(!) not included.

Supporting 64-bit ARM systems

Posted Jul 17, 2012 22:40 UTC (Tue) by jzbiciak (guest, #5246) [Link]

I'm not sad to see the IP (aka PC) leave the GPR file. It's a concept that was past its freshness date in the 80s.

But SP's not a GPR? Wow... It makes a certain amount of sense, really, since stack pointers move in rather particular ways. Treating it specially may help when speculating memory accesses. I'm going to guess they have dedicated ways of generating SP-relative addresses for local variables, along with frame pointers.

Otherwise, it sounds very MIPS-y, at least superficially.