Apart from backwards compatibility, 32 bit apps can use less memory with half size pointers and ints than 64 bit apps.

I once read an article about a project that placed everything into 64KB size blocks. Any pointer within the block is 16-bit, and you can also have references to other blocks.

First advantage is that the pointers become tiny, so the objects took up a lot less space. The other advantage was that when it was time to serialize and deserialize the data, you didn't have to do any processing at all.

> placed everything into 64KB size blocks. Any pointer within the block is 16-bit, and you can also have references to other blocks.

Just reinvented segmentation

That and there are some applications that have algorithms that scale really badly to the much larger size of the address space.

That only applies to apps that allocate a ton of objects and refer to them using pointers instead of using a dynamic array with 16bit/32bit indexes

Many server-class Aarch64 chips have dropped support for 32 bit so in those cases it's not even an option.

Also some of the latest smartphone chips have a part of the cores that no longer can execute 32-bit code.

The next generations will not include any core supporting the 32-bit ISA.

You can still use 32-bit wide addresses in 64-bit mode and sign-extend them into 64-bit registers.

If you have a statically compiled binary all you need is compiler support for 32-bit address mode in the otherwise 64-bit ready instruction set and on x86 you get access to more registers etc but you don't pay the price for the wider addresses stored in data structures.

OTOH if you use shared libraries you also have to have your shared libraries compiled in that mode too. The difficulty of dealing with that depends also if you gave a hybrid system or a full 32 bit userspace

Yes, that's an alternate ABI with 32-bit addressing targeting the same 64-bit instruction set. But it's not trivial, as you described. You might also want some kernel support too, and there might not be enough demand to maintain that support.

AKA x32 on AMD64.

Under Linux, I have no idea. but aarch has a wide variety of use cases. 64bit means more transistors on cpus, and wider instructions. The people that implement arm's designs would like to save money on all that. if it is an embedded device or a limited use device, it may not need 64bit. Especially when you're mass manufacturing, every $0.01 counts.

Just a side-note, I am always intrigued by 16bit thumb and aarch32 "interworking", basically flipping on/off the LSB of the PC(EIP/RIP equivalent register) to tell the cpu that the next instruction is thumb mode or a32, letting them mix different instruction sets within the same program.

Backwards compatibility with older binaries (some of which might not have devs anymore), and infrastructure and workflows already in place.

Granted this might not actually be worth considering here, given the much shorter history unlike x86(-64).

The advantage of 64-bit is only a wider integer range and address space which isn't needed for most applications, so trading those for portability is probably good. I've also heard that many people doing ARM assembly prefer A32 NEON over A64 NEON.

Depends what you want to be portable to -- now that 64 bit only Arm CPUs are becoming more common, building for 32 bit means you cannot run on those systems.

For ARM, 64-bit has removed features of the instruction set.

Notibly, conditional execution is gone.

If you have a compiled binary but lack source, then this subsystem is helpful.

Closed-source applications or games, I'd say.

some legacy applications were designed around having a 32 bit wordsize for pointers. so calculations of offsets into memory where a data structure includes pointers depends on a pointer size.