User: Password:
Subscribe / Log in / New account

Supporting 64-bit ARM systems

Supporting 64-bit ARM systems

Posted Jul 10, 2012 21:39 UTC (Tue) by jzbiciak (subscriber, #5246)
In reply to: Supporting 64-bit ARM systems by smoogen
Parent article: Supporting 64-bit ARM systems

As long as the ARMv8 instantiations run both instruction sets relatively well, I doubt it'll have quite the hurdle as IA64 did even if the ISAs are rather different.

The original IA64 parts couldn't run x86 code worth a crap, and so not only did you have to change everything to use the new 64-bit functionally, you had to change everything before the device was even useful. That's a much bigger hurdle to clear.

Assuming ARMv8 processors run ARMv7 code relatively well outside of AArch64 mode, then you could deploy quite a lot of hardware with ARMv8, and only move to 64-bit when needed. I think that was much of the allure of x86-64. Many people ran 32-bit OSes on 64-bit devices for quite awhile, until the 64-bit software matured.

(Log in to post comments)

Supporting 64-bit ARM systems

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

I suspect the reverse: ARM users don't expect new ARM sub-architectures to run their code without changes, let alone new major architectures. Porting is a normal part of developing against ARM hardware. There just isn't a legacy base of binary software to worry about being compatible with.

ARM64 doesn't have to run ARM32 code, it just has to be vaguely sane to port code for ARM32 over to ARM64.

Supporting 64-bit ARM systems

Posted Jul 11, 2012 3:27 UTC (Wed) by jzbiciak (subscriber, #5246) [Link]

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]

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]

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 (subscriber, #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.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds