3 ms·

I've been wondering whether it would be possible to write programs that have most of their memory in 32 bits, so most pointers would be 32 bits. Also, such pro

by ant6n 10y ago

I've been wondering whether it would be possible to write programs that have most of their memory in 32 bits, so most pointers would be 32 bits. Also, such program would have int as a 32 bit value unless specifically declared to be larger - we could write programs that use less memory, but still use more registers, and use 64bit pointers and values as necessary

mox1 10y ago
I guess this is theoretically possible (...maybe..), but I would definitely require cooperation from the underlying operating system and some of the hardware. Additionally, processors have "modes". You tell the processor to go into 64-bit or 32-bit mode. I don't think quickly switching back and forth between those in real-time is a very good idea.
- ant6n 10y ago
  64-bit mode is kind of a strict superset of 32-bit mode. So the program can run in 64bit mode. But for example, if a program stores a pointer in memory, it's stored as a 32bit number. Once it's loaded, it gets 0-extended to a 64bit integer. The main thing is having a differen ABI (within the program), and using the linker/memmapping to ensure that the stack, code, and a heap is in the lower 4G. Another heap can be in the 64bit space, using 64bit pointers. edit: one could even use trickery related to the alignment of pointers (i.e. 32bit alignment) to shift values on load or access, using the fact that the lower bits of the address. This could allow 36bit addresses that cover 16GB of memory.
messe 10y ago
Look up the x32 ABI for Linux. It's exactly that.
psi-squared 10y ago
One of the less-well-known features of Linux is that you can do this! Theres's a thing called the "x32 ABI" (use the option -mx32 with gcc or clang; you'll need all your libraries compiled with it too) where: * As far as the processor itself is concerned, the code runs in 64-bit mode, so you get the extra (and wider) registers from that. * But pointers are still 32 bits, so you get the memory savings of 32-bit mode. In principle, as long as you're using <4GiB of memory, it should be at least as fast as the best of 32-bit or 64-bit mode for any particular program. But I haven't heard of it being used much. https://en.wikipedia.org/wiki/X32_ABI https://en.wikipedia.org/wiki/X32_ABI
- tomcam 10y ago
  Like GP, I thought I had cleverly thought of this idea up myself. So glad that smarter people than I have did this up right!
  - ant6n 10y ago
    The only thing missing, I guess, is 64bit 'himem' pointers.
- ant6n 10y ago
  does something like this exist for aarch64?
GFK_of_xmaspast 10y ago
So basically going back to segmented memory with near (32bit) and far (64bit) pointers?

by ant6n 10y ago

mox1 10y ago

I guess this is theoretically possible (...maybe..), but I would definitely require cooperation from the underlying operating system and some of the hardware. Additionally, processors have "modes". You tell the processor to go into 64-bit or 32-bit mode. I don't think quickly switching back and forth between those in real-time is a very good idea.

ant6n 10y ago
64-bit mode is kind of a strict superset of 32-bit mode. So the program can run in 64bit mode. But for example, if a program stores a pointer in memory, it's stored as a 32bit number. Once it's loaded, it gets 0-extended to a 64bit integer. The main thing is having a differen ABI (within the program), and using the linker/memmapping to ensure that the stack, code, and a heap is in the lower 4G. Another heap can be in the 64bit space, using 64bit pointers. edit: one could even use trickery related to the alignment of pointers (i.e. 32bit alignment) to shift values on load or access, using the fact that the lower bits of the address. This could allow 36bit addresses that cover 16GB of memory.

messe 10y ago

Look up the x32 ABI for Linux. It's exactly that.

psi-squared 10y ago

One of the less-well-known features of Linux is that you can do this! Theres's a thing called the "x32 ABI" (use the option -mx32 with gcc or clang; you'll need all your libraries compiled with it too) where: * As far as the processor itself is concerned, the code runs in 64-bit mode, so you get the extra (and wider) registers from that. * But pointers are still 32 bits, so you get the memory savings of 32-bit mode. In principle, as long as you're using <4GiB of memory, it should be at least as fast as the best of 32-bit or 64-bit mode for any particular program. But I haven't heard of it being used much. https://en.wikipedia.org/wiki/X32_ABI https://en.wikipedia.org/wiki/X32_ABI

tomcam 10y ago
Like GP, I thought I had cleverly thought of this idea up myself. So glad that smarter people than I have did this up right!
- ant6n 10y ago
  The only thing missing, I guess, is 64bit 'himem' pointers.
ant6n 10y ago
does something like this exist for aarch64?

GFK_of_xmaspast 10y ago

So basically going back to segmented memory with near (32bit) and far (64bit) pointers?