Supporting 64-bit ARM systems

Posted Jul 11, 2012 17:33 UTC (Wed) by Lumag (subscriber, #22579)
In reply to: Supporting 64-bit ARM systems by gnb
Parent article: Supporting 64-bit ARM systems

There is no such register shortage on ARM as it is on IA-32.

P.S. I'm not voting against Aarch64. I just say that "just extending registers to 64-bit" probably won't work as expected.

Supporting 64-bit ARM systems

Posted Jul 11, 2012 18:20 UTC (Wed) by gnb (subscriber, #5132) [Link]

Agreed it's nothing like as bad as IA-32 but I suspect the increase in registers will still give some benefit. Also worth noting is that all useful ARMv8 implementations will probably still support 32-bit ARM, so the 32-bit app. on 64-bit kernel pattern can be used.,

Supporting 64-bit ARM systems

Posted Jul 12, 2012 22:16 UTC (Thu) by cesarb (subscriber, #6266) [Link] (3 responses)

It depends on what you are trying to do.

For instance, the inner loop of SHA-512 needs 8 64-bit registers, plus an array of 16 64-bit values. On a 32-bit architecture with 15 registers, you will have to spill to the stack (each 64-bit register would be represented by a pair of 32-bit registers, so you would need 16 of them). On a 64-bit architecture with 31 registers, you could have the whole state (8+16 values) in the registers, and still have a few left for the intermediate calculations. The entire inner loop can run without having to touch the stack.

Supporting 64-bit ARM systems

Posted Jul 14, 2012 22:40 UTC (Sat) by jzbiciak (guest, #5246) [Link] (2 responses)

In the specific case of ARMv7 vs. ARMv8, you need to consider NEON. An ARMv7 with NEON, wouldn't you do the SHA-512 hash using the NEON registers?

(These guys show decent results for other crypto algorithms using NEON. They suggest SHA-512 would speed up well also, but say they "didn't bother" with it yet.)

I guess my point is, ARM v7 already offers a path to way more registers than the base 16 x 32. I would imagine anyone springing for a Cortex-A15 would also include NEON. NEON is designed to absorb the heavy duty bulk computation, leaving the 16 GPRs for the more general control stuff.

Supporting 64-bit ARM systems

Posted Jul 14, 2012 23:00 UTC (Sat) by dlang (guest, #313) [Link] (1 responses)

If you are building software for one device, everything you say is reasonable.

But if you are trying to build software for many different devices (like a disto needs to), then you can't count on optional features being there

Supporting 64-bit ARM systems

Posted Jul 15, 2012 4:42 UTC (Sun) by jzbiciak (guest, #5246) [Link]

There are CP15 registers (ID_ISARx, MVFRx, CPACR, NSACR) that tell you whether VFP and NEON are present, and if present, whether they're powered up and available. (VFP/NEON are in a separate power domain on A15.) So, you could theoretically build software that includes NEON-optimized algorithms, and set up the right versions of the functions at the start of the code.

Your point stands, though, for devices that would have to run the fallback version. Those would benefit from ARMv8 without having to use NEON. Plus, keeping the multiple versions around takes up more space, wrangling them is added complexity, etc. etc.

For something like a cell phone, where interpreters like Dalvik have a JIT, the compiled code can match the exact CPU in the phone. After all, that isn't exactly a user-serviceable part. ;-)