ARM64 Vs ARM32 -- What's Different For Linux Programmers? (edn.com)

New submitter DebugN writes: When ARM introduced 64-bit support to its architecture, it aimed for Linux application compatibility with prior 32-bit software on its architecture. But for Linux programmers, there remain some significant differences that can affect code behavior. If you are a Linux programmer working with — or will soon be working with — 64-bit, you might want to know what those differences are, and this useful EDN article says it all.

Comments

Re:ARM32? ARM64?

[Anonymous Coward]

Vegeta, what does the scouter stay about his ARM level?

Re:ARM32? ARM64?

[Anonymous Coward]

I'm wrestling with how to answer all these ARM questions.

tl;dr;

[viperidaenz]

It's mostly nothing to do with ARM and much to do with "Moving to a later Linux kernel", implying ARM 32bit CPU's don't run on the latest kernels. But they do.

Re:tl;dr;

[Guy Harris]

It's mostly nothing to do with ARM and much to do with "Moving to a later Linux kernel",

You're thinking of the third item in their list.

The first item in their list does have to do with ARM; its register set is different, and OS APIs for debugging have platform dependencies - in particular, the Linux kernel handled A64 differently from A32 - and those particular developers happen to be using ptrace() and had to handle A64 differently.

The second item in their list has to do with the C library doing more atomic load/store operations on A64 for some reason; they speculate that it's "to better support multiprocessor systems."

The problem here is that the article had a misleading title; it was "ARM64 vs ARM32 -- What's different for Linux programmers" when it should have been "ARM64 vs ARM32 -- What's different for people working at a company whose core technology is a record and replay engine, which works by recording all non-deterministic input to a program and uses just-in-time compilation (JIT) to keep track of the program state". What Undo Software are doing is rather specialized and system-softwareish, and they run into issues that wouldn't affect the majority of programmers; those are the issues they're talking about.

Re:tl;dr;

[AReilly]

Only people who don't actually use processors at the instruction set level are uncertain about whether or not a processor is "32 bit" or "64 bit". If you look at the architecture, it is usually very easily apparent. Not always, but usually.

Does it take more than one instruction to shift a 64-bit value? It probably isn't a 64-bit processor.

Re:tl;dr;

[viperidaenz]

There are many instructions in x86 that operate on values larger than 32 bits.
MMX comes with 8 64bit registers
The movq instruction can move a 64bit value between memory and the MM registers.

Re:tl;dr;

[Anonymous Coward]

Will people *please* stop saying that hardware "runs on" software: it's the other way round!

(If you want to say that a piece of hardware "runs" some software, that's perfectly acceptable -- but not "runs on".)

Re:tl;dr;

[Guy Harris]

Of course the title is misleading! For a user-space programmer, the ISA is completely hidden by the compiler and the system libraries (for example, synchronization).

Unless you're one of the user-space programmers writing the compiler or the system libraries. :-)

The programmers at Undo are programmers like that, not typical user-space programmers writing code for which the ISA doesn't matter.

(And a fair bit of kernel programming is done with the ISA hidden by the compiler and lower-level kernel code, for that matter.)

That's easy

[pushing-robot]

One has a lot more arms.

So in summary

[NaCh0]

There are no changes for programmers in general. Only the compiler writers need to care. (as usually happens with new cpu architectures)

C Programmers on Linux, not "Linux Programmers"

[Anonymous Coward]

This will have absolutely no effect to the majority of programmers that use a higher level language such as Java or Objective-C.

As the article shows examples, only Assembly and C have changes from the 32 bit version, which are to be expected. Not a big surprise for anyone. I am sure my Python code will run the same as it did on ARM32.

Details

[Galaga88]

You see, when you have ARM32 vs ARM64 you have to remember that 64 is at least twice as much as 32. So you're going to need to use larger instructions in your program or you're going to have a lot of empty space. Because your functions can go twice as far, you're going to need more data highways to get there without all the congestion. It's like moving from a crowded boulevard to an expressway.

When it comes to mobile apps, which is where you're going to be programming the ARM, these wider highways occupy valuable space on your mobile board, but it's worth it to reduce congestion by at least a half. Also, because you have larger bits, you can get more numbers in your apps without having to stress the fixed point unit. This means fonts take up less space and as such you can use more serifed typefaces.

This answer brought to you by That Guy Who Clearly Bullshitted Through His Interview and Got Promoted To Manager Last Week.

Re:Trump vs Clinton -- Whats different for voters

[The Wild Norseman]

Hang on, I think I'm getting it. Usually people use car analogies on /. but you're talking about the US and Denmark, right? So in this case, Denmark is 64-bit and the US is only 32-bit? Or are you talking about ARMs as in "the right to keep and bear ARM [chips]"?

Re: ARM32? ARM64?

[LoRdTAW]

[goku@dragonball]$ scouter -h
It's over
Segmentation fault
[goku@dragonball]$

Re:I'm not a programmer...

[OrangeTide]

The instruction set for ARM64 is a bit more like MIPS than ARM. I don't think it would matter to an end user, but this new 64-bit mode has made for a lot of extra work for compiler developers as many of the optimizations developed over the years are no longer effective for 64-bit code. And the bits of operating system and library code that was written for 32-bit or Thumb has to be rewritten as if ARM64 was a totally alien architecture.

It came as a big surprise really, because years ago when ARM Thumb was added as an extension it was somewhat compatible with the old instruction set, at least in the assembler syntax. That made it relatively easy to port between the two modes. Thumb mode instructions that are half as big, but still operate on 32-bit values, but those instructions are more limited in terms of what they can do and what arguments they will accept. On the Game Boy Advance, the thumb operations could run twice as fast as the non-thumb operations because the 16-bit bus for cartridges was relatively slow compared to the CPU performance.

ps - I prefer to call it aarch64 or ARMv8.

Re:2+ years late

[unixisc]

iOS only has to bother about Apple's A series of processors, and not the myriad variety of ARM CPUs from different vendors, such as Qualcomm, Freescale, TI, et al Not the same challenges

Re:Trump vs Clinton -- Whats different for voters

[TheRaven64]

If you're going to define socialism by the fact that the NAZIs and the USSR had socialist in their name, then you also need to define democratic based on the Democratic Republic of Congo. Or you can try using the definitions that you'll find in a politics textbook and then people might be able to have a sensible conversation with you.