From: bc@freeuk.com

On 24/11/2025 13:33, Keith Thompson wrote:
> bart  writes:

>> What about arrays of _BitInt(1), _BitInt(2) and _BitInt(4)? These
>> could actually be practically implemented, with a few restrictions,
>> and could save a lot of memory.
>
> No, they couldn't.  Array indexing is defined in terms of pointer
> arithmetic, and you can't have a pointer to something smaller than one
> byte.


The restrictions I mentioned were to do with pointers to individual bits.

It is possible that operations such as:

    x = A[i]
    A[i] = x

can be well defined when A is an array of 1/2/4-bit values, even if
expressed like this:

    *(A + i)

But this would have to be indivisible when A is such an array: only the
whole thing is valid, not (A + i) by itself, or A by itself; you'd need &A.

This would need a small tweak to the language, but that is nothing
compared to supporting (i3783467 * i999 / i3) >> i17.

But I write a script in my dynamic language, which does support arrays
of 'u1 u2 u4', and it gives these results:

  Array of u1  uses   12,500,000 bytes
  Array of u2  uses   25,000,000 bytes
  Array of u4  uses   50,000,000 bytes
  Array of u8  uses  100,000,000 bytes
  Array of u16 uses  200,000,000 bytes
  Array of u32 uses  400,000,000 bytes
  Array of u64 uses  800,000,000 bytes

C can only get down to that u8 figure (100MB) using its 'char' type.
Even 'bool' doesn't make it smaller (presumably for the reasons you
mentioned).

You are forced to emulate such arrays in user-code using shifts and masks.

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)