third draft: add bitfields to D

[Dom DiSc]

On Saturday, 20 July 2024 at 17:32:40 UTC, IchorDev wrote:
> On Thursday, 18 July 2024 at 08:52:35 UTC, Dom DiSc wrote:
>> Why? As pointers are 64bit, the highest three bits will never 
>> be used anyway (at least not for the next 20 years).
>
> This is a stupidly unreliable and highly system-dependant hack: 
> https://stackoverflow.com/a/18426582
> How will you make this work on 32-bit systems?

Use 64bit pointers anyway and translate them  before handing it 
over to the system. How is memory above 4GB handled on such 
systems? The answer is: there is already a translation from 
process address space to hardware addresses. This need only a 
little adjustment.

> How will you make this work on iOS—a 64-bit system where 
> pointers are 32-bit?

Same of course.

> 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.

>> 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.

Of course all this is just a workaround unless processors exists 
that support bit addresses directly. But I see no reason why that 
should be problematic at all. The low address lines doesn't even 
need to exist. On 68000 there was also no line for odd addresses, 
so you needed to get 16bit and then shift if access to an odd 
byte was necessary. And it worked.