4 ms·
We could have 32-bit pointers with a bit of hacking: First, re-implement memory management on top of std::vector (or similar dynamic array): have your pointers
by loup-vaillant 8y ago
We could have 32-bit pointers with a bit of hacking: First, re-implement memory management on top of std::vector (or similar dynamic array): have your pointers be array indices; replace the `brk()` system call by the `resize()` method; reimplement `malloc()` on top of that.
And voilà, you can have your 32-bit pointers. You can even go down to 16-bits for small enough arenas.
(No, I'm not actually serious. Though we could imagine something similar on some new language.)
- jcelerier 8y ago> We could have 32-bit pointers with a bit of hacking: We can also have them with zero hacking since there is an existing ABI for 32 bits pointers in 64 bit mode: https://wikipedia.org/wiki/X32_ABI https://wikipedia.org/wiki/X32_ABI ; you get all the benefits of x86_64 mode (more registers, default support of SSE2 etc) for the memory usage level of x86 (and 4gb of accessible ram instead of x86 OSes's 2.something addressable gigabytes). I'm pretty sure that only specialized apps actually require >4gb of ram - most common utilities (e.g. shell, text editor, etc...) should really be compiled in x32 mode.
- loup-vaillant 8y agoMy, I didn't know about x32 mode. I'll keep that in mind, thanks.
- aidenn0 8y agoAnything that is going to mmap a file of 1GB or larger will probably want 64-bit addressing, which will include any document editor that is designed around mmap. That's somewhat specialized, but not as much as you might think.