Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: James Kuyper <jameskuyper@alumni.caltech.edu>
Newsgroups: comp.lang.c
Subject: =?UTF-8?Q?Re=3A_technology_discussion_=E2=86=92_does_the_world_need?=
 =?UTF-8?B?IGEgIm5ldyIgQyA/?=
Date: Thu, 11 Jul 2024 12:09:33 -0400
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <v6p03t$2go2s$1@dont-email.me>
References: <v66eci$2qeee$1@dont-email.me> <v67gt1$2vq6a$2@dont-email.me>
 <v687h2$36i6p$1@dont-email.me> <v68sjv$3a7lb$1@dont-email.me>
 <v6a76q$3gqkm$6@dont-email.me> <87plrruvmt.fsf@nosuchdomain.example.com>
 <v6argi$3ngh6$5@dont-email.me> <v6crb5$1gpa$1@dont-email.me>
 <v6kma1$1jcln$7@dont-email.me> <v6lcg3$1qhmn$1@dont-email.me>
 <v6nhbr$29e0c$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 11 Jul 2024 18:09:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7338e67614b36e18c17f3563b3f8bed2";
	logging-data="2646108"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19QNsKiuL/ut2DgDx7WtafW20TIjom5qCM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:UibcBiYDKpkAKtD0nwlpVguJ6GY=
In-Reply-To: <v6nhbr$29e0c$3@dont-email.me>
Content-Language: en-US
Bytes: 4081

On 7/10/24 22: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? Many architectures have bitfield instructions, but C cannot easily 
> make use of them without the ability to have arbitrarily-bit-aligned 
> pointers.

Note: on such a platform, the C shift and mask instructions could be
translated internally to bitfield instructions. I suppose that would be
a nice feature to try out, but what does that have to do with what we
were talking about?

The key point is that the addressable unit of the hardware doesn't have
to match the addressable unit implemented by C code. It can be emulated.

On a bit-addressable machine, a C compiler could implement a char* by
using a machine address that moves forward 8 bits every time you add 1
to it.

On a machine where the addressable memory locations are 64 bits apart, a
C compiler could implement a char* by using a machine address combined
with 3 bits set aside to designate which 8 bits within the 64 bit word
are being pointed at. Adding 1 to such a pointer increments the offset;
if it's already pointing at byte 7, the offset would wrapping around to
0 bytes and the machine address would be incremented.

Furthermore, in the intermediate ranges, systems with a bit size greater
than 8 and less than 16 bits or so, there's also the option to choose
CHAR_BIT to match the size of the addressable unit. Some real world DSPs
set CHAR_BIT to 16.

The C standard gives implementors enough freedom to implement byte
addressability, as required by the C standard, on machines with just
about any size of addressable unit. It is simply not the problem you
suggested it was in your message that was posted at 2024-07-06 01:38 +0000.