Bitarrays in the age of 64bit

[Basile B.]

On Friday, 3 April 2020 at 07:31:52 UTC, Dominikus Dittes Scherkl 
wrote:
> It was said that implementing bitarrays is complicated, because 
> of the indexing.
>
> Has anybody ever considered to use bit-pointers?
> Nobody really uses the full address range that 64bit pointers 
> have - in fact some hardware internally still uses 48bit or 
> 56bit address-registers, so instead adding three lower address 
> bits would not cost a lot (just forward bit 3..58 to the 
> register instead of bit 0..55).
> This would also allow for implementing 2bit-types (one that I 
> really would appreciate, because it can represent sign values, 
> providing -1, 0, 1 and NaN - which is necessary as a comparison 
> result for non-ordered values), and 4bit-types (so called 
> nibbles).
> And with bit-pointers of course implementing arrays of boolean, 
> sign, nibbles or even odd-length types would be straight 
> forward. All the strange side-effects of byte clustering would 
> vanish.
>
> Just an idea.

Yes I already thought to that, using an addressing system 
relative to the base address of a memory pool with a fixed size.

At some point I considered this for a very wasteful Radix-tree 
structure but never did.

This would work with a kind of stdx.allocator-like static 
interface but the problem is that the pointers types become 
something like ubyte[1], ubyte[2], ubyte[3], etc. depending on 
the pool max size. But the stdx alloc interface take void[] (and 
works on void[].ptr). So all the helpers (make, makeArray, etc) 
would not be usable and finally you'd have to write a lot to make 
the things usable, I mean in a generic way, with all D types.