Supporting 64-bit ARM systems

Posted Jul 14, 2012 22:40 UTC (Sat) by jzbiciak (guest, #5246)
In reply to: Supporting 64-bit ARM systems by cesarb
Parent article: Supporting 64-bit ARM systems

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. ;-)