On 2020-04-03 09:31, 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.

I see what you mean. The addressable space would be 8 times less (not a problem for the foreseeable future of course).

No clue what implementations this would have though :)

On Sunday, 5 April 2020 at 16:42:24 UTC, Faux Amis wrote:
> On 2020-04-03 09:31, 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.
>
> I see what you mean. The addressable space would be 8 times less (not a problem for the foreseeable future of course).
>
> No clue what implementations this would have though :)

D had bit pointer a long time ago (or it was seriously envisioned) in pre 1.0 times and Walter had said that it was waste of time. Complicates the compiler significantly for not much benefit. He referred to it recently and he was still hostile towards it.

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.

Sure.

1. GC allocated bitarrays.
http://mir-algorithm.libmir.org/mir_ndslice_allocation.html#.bitSlice

2. Ref-counted bitarrays
http://mir-algorithm.libmir.org/mir_ndslice_allocation.html#.bitRcslice

2. Bit array on top of a user-provided integer array.
http://mir-algorithm.libmir.org/mir_ndslice_topology.html#.bitwise

3. Packed integer (1-65 bits) arrays on top of a user-provided integer array.
http://mir-algorithm.libmir.org/mir_ndslice_topology.html#.bitpack

4. Packed bytes bytegroup arrays on top of a user-provided integer array.
http://mir-algorithm.libmir.org/mir_ndslice_topology.html#.bitpack

All of the provided API has random access range primitives, as well the types are ndslices. Thus mean you can have construct for example a bitmatrix.


Have a good day :)