back to article ARM arms devs for 64-bit Android push with 'Juno' board

ARM has announced a pair of initiatives that should help Android make the jump to 64-bit architectures. The first is that Linaro, the not-for-profit mob making sure open sourcery runs well on ARM, has ported the Android Open Source Project (AOSP) to the 64-bit ARMv8-A architecture and popped it out the door in the form of Linaro …

WTF?

Didn't Samsung promise a 64-bit flagship this year because they were worried that everyone would suddenly jump ship now that Apple had gone 64-bit?

0
3
Anonymous Coward

Sadly people are idiots

if they believe that 64bit is some magic miracle.

The reality is that on mobile, the overhead of 64bit pointers, larger binaries and larger memory footprints mean they are worse off than 32bit.

This is a prime example of where marketing wins over reality.

7
1
Silver badge

Re: Sadly people are idiots

I used to think that, then spoke to a chip designer who put me right. There are definite benefits of 64 bit CPU's over 32 even in today's devices. Although code might get a bit bigger, memory foot print also, (but not by huge amounts), there are clear performance benefits of going to 64 bits.

Although marketing does play a part, it's not all snake oil.

4
1

This is always interesting

this argument over 32 or 64.

As far as i remember, 64 bit architectures had an address space of around 41 bits, still a huge improvement over 4GB i suppose. The rest is reserved for ECC, pointers and page frame numbers etc.

So is there really any benefit in a handheld device? I don't know and perhaps you boffins out there could explain the technical benefits other than huge amounts of RAM to flood with cached data.

0
0
Anonymous Coward

Re: This is always interesting

" 64 bit architectures had an address space of around 41 bits, still a huge improvement over 4GB i suppose. "

Try not to confuse architecture concepts (64bit) with implementation restrictions (41bit).

"So is there really any benefit in a handheld device? "

From what I've seen, there are many benefits in these newfangled ARM 64bit chips, above and beyond their 64bitness. These will be useful benefits even in non-huge systems (I refuse to call a 4GB system a 'small' system).

What I can't remember is a useful reference that summarises these handy new features.

1
0
Silver badge

Dalvik and the NDK

Most apps are pure Dalvik. They neither know nor care if the host OS is 32-bit or higher since Dalvik imposes the app constraints in much the same way as a JVM does.

Apps that use the NDK (and some like games need to) on the other hand definitely know what the architecture is and are probably rolling their eyes about yet another target appearing. The problem at present is that every architecture .so needs to be built and bundled together in a single APK (bloating it out), or separate apks for each architecture (an administration and testing nightmare). Neither is optimal and unsurprisingly devs won't support a new architecture until it gains traction. And a new architecture won't gain traction unless the apps support it.

Google could help a lot here (and ARM and Intel) by supporting LLVM targets. Let someone compile their NDK app against a LLVM bitcode target. Let the device compile that target into native code during installation. Or even Google could do it when the apk is uploaded to their store. The point being that then devs don't care what the architecture is because their app will work on anything and new 64-bit cpus integrate seamlessly into the ecosystem.

0
0
Anonymous Coward

Re: Dalvik and the NDK

LLVM bitcode isn't automatically portable. For example, what do you think the LLVM bitcode translation of this C function looks like?

int f() { return sizeof(void *); }

You could standardise on a particular 32-bit ABI and find a way of turning that into native code on all Android targets. (Are they all little-endian?) Or you could replace LLVM bitcode with something more portable. (There's a proposal for something called "LLVM Wordcode".)

Whatever you do, C being what it is, developers would still have to test their apps on 32-bit and 64-bit targets as it is all too easy to write C code that works on one but not the other.

0
0
Anonymous Coward

Re: Dalvik and the NDK

"Google could help a lot here (and ARM and Intel) by supporting LLVM targets. Let someone compile their NDK app against a LLVM bitcode target. Let the device compile that target into native code during installation. "

Hey look! 1970s calling, someone's reinvented the UCSD p-system. Or do I mean ANDF, from the 90s?

:)

1
1

Re: Dalvik and the NDK

Yeah, everything old is new again. I still want one to play with as I have a rover to build which would suit it just fine.

0
0

32-bit vs 64-bit

On a mobile device, I would have thought the 64-bit advantage is more about SIMD than address space.

0
0
Silver badge

Re: 32-bit vs 64-bit

64 bits is irrelevant for SIMD. Nothing stops you from having 64 bit, 128 bit, 256 bit even 1024 bit SIMD running in 32 bit mode, any more than 32 bit CPUs were unable to use 64 bit or 80 bit wide FP.

There are real benefits to 64 bits however, even with only 1GB of RAM like the iPhone 5S has, which is shown in the performance comparison between the 5S running identical apps compiled for 32 bit and 64 bit. For certain apps the difference is exaggerated, because they make use of new ARMv8 instructions, but 10% or more is not unusual for real world gains. Not world shaking, but worth doing since it comes without any additional hit on the battery.

Implementing 64 bits before it is absolutely required is also helpful becauase it gets developers building 64 bit apps now, rather than waiting until they're needed, and will allow Apple to phase out the 32 bit instruction set sooner rather than later. Since Apple designs its own CPU, it will be able to completely dump the 32 bit instruction set sooner, which will make their 64 bit CPUs cheaper and faster.

They may do this with the upcoming A8, since it could run 32 bit code via translation. That would slow it down when running 32 bit code, but it should still be faster than a 32 bit A6 when doing so, and most developers have already updated apps that performance sensitive in any way to build a 64 bit version.

0
0

Re: 32-bit vs 64-bit

Sure, you can have wider registers for SIMD operations (e.g. NEON), but you've got to load and store them somehow. A 64-bit data path throughout your architecture means you can move more data per operation which will benefit SIMD performance, so it is relevant. Incidentally, one of the major features of the ARMv8 architecture is enhanced SIMD support, making it standard and increasing the number of available 128-bit registers.

As mobile apps are generally audio/graphics DSP intensive, an increase in throughput is likely to be more useful to developers than the ability to address a vast and sparsely populated address space.

0
0
Silver badge

Re: 32-bit vs 64-bit

A 64-bit data path throughout your architecture means

Comprehension fail. A "64 bit CPU" has nothing do with the width of the data path, it speaks solely to the width of the address registers. The width of the data path is an implementation detail, and there were some 32 bit RISCs that had 256 bit wide data paths, Intel x86 had 64 bit and 128 bit data paths in its 32 bit days, and probably most ARMv7 implementations have had at least 64 bit data paths.

1
0
Bronze badge

2038 problem ?

Just getting in early ?

1
1

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums