Posted Dec 2, 2012 14:08 UTC (Sun) by normcf (guest, #88125)
Parent article: The x32 system call ABI
Having found the conversation interesting, I just want to interject a small historical thought. About 30 years ago, I worked on a Burroughs B6700. This machine had a 48bit architecture and the virtual memory management that was quite advanced. In this discussion, I have heard many consider the tradeoffs of 64bit pointers in the cache vs most programs requiring < 4G of user space. I offer a compromise of 48 bits, which would greatly extend the date/time issue, give space for almost all programs and still not be piggish on pointers in cache. Of course, I presume there are plenty of downsides of this, including, perhaps, hardware issues, but if we're doing all this work anyway, changing system calls, compilers, loaders etc., maybe considering a middle ground would be useful. Please just ignore me if it is too ridiculous. Thanks.
Posted Dec 2, 2012 23:06 UTC (Sun) by dlang (✭ supporter ✭, #313)
[Link]
all current hardware has significant benefits if the data is aligned properly (32 bit values aligned on a multiple of 4 bytes, 64 bit values aligned on a multiple of 8 bytes). As a result, in the normal case, 48 bit unaligned values are going to be slower to use.
If you have a huge array of pointers, the memory savings will outweigh this cost, but not for the normal uses.