third draft: add bitfields to D

[IchorDev]

On Saturday, 20 July 2024 at 20:18:32 UTC, Dom DiSc wrote:
> Use 64bit pointers anyway and translate them before handing it 
> over to the system.

Which will take a whole extra register, defeating the point of 
trying to cram data into pointers. Just using a different 
register is a much better solution in general, it's just a bit 
wasteful. If you care so much waste though, you shouldn't be 
using a language with slices—in D they take **2 times** more 
space than a pointer when you could just be using null-terminated 
arrays instead.

> [...] there is already a translation from process address space 
> to hardware addresses.

And this is done by the kernel, so I don't see how it's relevant 
to this conversation unless we are re-writing iOS' kernel?

>> How will you make this work on systems with 64-bit pointers 
>> that have all of their bits reserved?
>
> Not a problem unless those bits are used for other purposes by 
> the system.

So what you are proposing will not work for those systems.

>>> Simply shift all pointers 3bits to the right and use the 
>>> lower 3 bits to indicate the bitoffset.
>>>
>> That will only work if they are aligned to 8-byte boundaries.
>>
> ?!?
> Why? I mean, alignment maybe required also by other means, but 
> that translate only to ignoring the lower bits and fiddling out 
> the requested bits by shifts.

Let's say we have a 64 bit pointer (U='unused'; P=pointer bits; 
X=zeroed bits ; C=our data):
`UUUUUUUU UUUUUUUU PPPPPPPP PPPPPPPP PPPPPPPP PPPPPPPP PPPPPPPP 
PPPPPPPP`
Now we shift 3 bits to the right:
`XXXUUUUU UUUUUUUU UUUPPPPP PPPPPPPP PPPPPPPP PPPPPPPP PPPPPPPP 
PPPPPPPP`
We just lost the 3 least significant bits of the original 
pointer, so unless it was storing a multiple of 8 we just lost 
important data.
Now we will use the lower 3 bits to indicate the bit offset:
`XXXUUUUU UUUUUUUU UUUPPPPP PPPPPPPP PPPPPPPP PPPPPPPP PPPPPPPP 
PPPPPCCC`
We just overwrote more of the existing pointer… so actually it 
would have to be aligned to a multiple of 64, or we just lost 
important data.
Also the kernel often uses these 'unused' bits in the pointer, so 
we would have to tread lightly, and also compiled code would have 
to know not just what OS it's targeting, but also what *kernel 
version* it's targeting in case of changes to this arrangement. 
In practice it's not as bad as it sounds, but it could be a 
frustrating headache to debug.

Lastly, in general bit-packing optimisations like this are 
terribly slow. It's probably just not worth the tiny memory gain.