not related to X32, but a similar motivation - X32 is potentially interesting to me for the same reason that I want this;
in the transition from 32-64bits, we have the same issues as historically in the transition from 16 to 32 bits: an intermediate range where doubling the everywhere bits is overkill.
e.g. working on a 16mb machine, with vectors of 4 byte elements, 32bit indices are sufficient. (infact it is very unlikely any real application would fill the entirety of 16mb with a char array.)
This doesn’t achieve the pointer-compression suggested above, but is very much in the same spirit; I am trying to point out there is a case where you want 64bit addressing/64bit ALU, but 32bit indices (which, with some alignment scaling, are going to achieve sufficient range).
Also I would definitely be interested in compressed pointers for the same purpose.
But doing this transparently in a system language could be harder.
indeed it would not be as transparent as Java; but the advertisement as “A systems language” includes domains where the user is very likely to have to think about this crossover size issue, whether its the 8mb game console target, or some tiny embedded controller. Perhaps without needing ‘compressed pointers’ across the board, a lot of cases could be covered by extending the standard library collections (Vec, HashMap etc) to handling 32 or 64bit indices (default to the address size, but offer the option to over-ride). “i want a hash map, but I know upfront there wont be more than 2^32 entries”.
There are even use cases for 16bit indices IMO (much of what I did in real world projects has involved clustering mesh such that 16 or 8bit indices could be within cache-sized chunks despite it being a 32bit target)
