Sujet : Re: technology discussion → does the world need a "new" C ?
De : bc (at) *nospam* freeuk.com (bart)
Groupes : comp.lang.cDate : 11. Jul 2024, 14:50:58
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v6oo01$2fja8$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11
User-Agent : Mozilla Thunderbird
On 11/07/2024 03:51, Lawrence D'Oliveiro wrote:
On Wed, 10 Jul 2024 03:16:18 -0400, James Kuyper wrote:
On 7/9/24 20:57, Lawrence D'Oliveiro wrote:
>
On Sat, 6 Jul 2024 21:34:29 -0400, James Kuyper wrote:
>
On many platforms, if _Alignof(type) is less than the word size, then
a C pointer to that type is implemented as the combination of the
machine address of the correct word, combined with an offset within
that word of the first byte of that object.
>
Which is a terrific idea, except it cannot be carried to its logical
conclusion (addressing of arbitrarily-aligned dynamically-defined
bitfields) because of the requirement in the C spec that the size of a
“byte” be at least 8 bits.
>
I will grant you that I failed to mention the fact that this is a
feasible way of implementing C only on platforms with a word size of 16
bits or longer.
Don’t you think C needs a better way of handling bitfields than shift-and-
mask?
Yes. But because it's not hard for a million programmers to each create their own macros like GETBIT and SETBIT, that's not going to happen.
Although bit operations are unusual in other languages too.
Many architectures have bitfield instructions, but C cannot easily
make use of them without the ability to have arbitrarily-bit-aligned
pointers.
When you look in depth at working with bits and bitfields, it is a surprisingly wide area with lots of possibilities
* Define named bits and bitfields within a struct (C already has this, although with little control). These bitfields are fixed length and location known at compile-time (although only to the compiler!), and can be of size 1 to 64 bits
* Extract a bit/bitfield from an integer value. These can have a position and length only known at runtime.
* Inject such a bit/bitfield into an integer value
* Allow bitfields that can straddle a word boundary.
* Allow small arrays of bitfields of width 1, 2 or 4 bits that fit within an integer. (8-bit bitfields are just bytes.)
* Allow full arrays of such bitfields, and slices of such arrays
* Allow arrays of bitfields of any width 1..64 bits
* Allow pointers to a bitfield of a certain fixed width 1..64 bits
* Allow that pointer to to stepped either to the next bitfield, or by any arbitrary number of bits
* Allow a bit-pointer with a variable target bit-width
* Allow bitwise ops between arrays of bits
* ....
----------------------
For my static language, I have:
* Bitfields within structs with more control than C, and are defined inside a regular integer field.
* Bit indexing to extract or inject bits/bitfields: A.[i] and A.[i..j]
My dynamic language also has arbitrary arrays of 1/2/4 bits, bit-slices, and bit-pointers to fields of 1..64 bits. It also has bit-sets of any size on which bitwise ops can be used.
At the level of C, I believe that bit-arrays are a possibility, without also needing to have bit-pointers that are bit-aligned. Pointers to the start of such arrays are fine, as they will be byte-aligned.