On 9/3/2021 5:02 PM, Bonita Montero wrote:
> Am 03.09.2021 um 15:59 schrieb james...@alumni.caltech.edu:
>> On Friday, September 3, 2021 at 1:10:37 AM UTC-4, Bonita Montero wrote:
>>> Am 02.09.2021 um 20:28 schrieb james...@alumni.caltech.edu:
>>>
>>>> The platform doesn't have pointers - that's a C concept. ...
>>>
>>> If they allow memory-addressing they know pointers.
>>
>> A platform can only be said to "know" something if it's running a
>> program.
>
> Machine-level does know pointers and architecture-depenent data-types:
>     MOV EBX, DWORD PTR [EAX + ECX * 8]
> Rest of your nonsense unread.
>

Actually that's an example of the difference between a pointer and an
address.
The rest of James' post explains that difference in detail, but that's
out of your reach.

Am 03.09.2021 um 19:33 schrieb Manfred:
> On 9/3/2021 5:02 PM, Bonita Montero wrote:
>> Am 03.09.2021 um 15:59 schrieb james...@alumni.caltech.edu:
>>> On Friday, September 3, 2021 at 1:10:37 AM UTC-4, Bonita Montero wrote:
>>>> Am 02.09.2021 um 20:28 schrieb james...@alumni.caltech.edu:
>>>>
>>>>> The platform doesn't have pointers - that's a C concept. ...
>>>>
>>>> If they allow memory-addressing they know pointers.
>>>
>>> A platform can only be said to "know" something if it's running a
>>> program.
>>
>> Machine-level does know pointers and architecture-depenent data-types:
>>      MOV EBX, DWORD PTR [EAX + ECX * 8]
>> Rest of your nonsense unread.
>>
>
> Actually that's an example of the difference between a pointer and an
> address.

The pointer DWORD PTR [EAX + ECX * 8] is typed: DWORD.

On Friday, September 3, 2021 at 11:03:12 AM UTC-4, Bonita Montero wrote:
> Am 03.09.2021 um 15:59 schrieb james...@alumni.caltech.edu:
> > On Friday, September 3, 2021 at 1:10:37 AM UTC-4, Bonita Montero wrote:
> >> Am 02.09.2021 um 20:28 schrieb james...@alumni.caltech.edu:
> >>
> >>> The platform doesn't have pointers - that's a C concept. ...
> >>
> >> If they allow memory-addressing they know pointers.
> >
> > A platform can only be said to "know" something if it's running a program.
> Machine-level does know pointers and architecture-depenent data-types:
> MOV EBX, DWORD PTR [EAX + ECX * 8]
> Rest of your nonsense unread.

On a platform such as the one I've described, with no hardware support for
access to any piece of memory smaller than 16 bits, and a compiler which
chooses to set CHAR_BIT == 8, the following function:

void add_3a(unsigned char *p) { *p += 3; }

Would have to be compiled into machine code which does something
similar to:

struct _byteptr {
int *addr
int offset;
};

void add_3b(struct _byteptr p)
{
int temp = *p->addr;
unsigned char low = temp & 0xff;
unsigned char high = temp >> 8;
if( byteptr->offset)
low += 3;
else
high += 3;
*p->addr = high<<8 + low;
}

In fact, such a compiler might generate code for add_3a() which is
interchangeable with that for add_3b().

On such a platform, in what sense does the platform "know" about
char*? The compiler knows about char*, but I don't see how the
platform can be said to know about it.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 03.09.2021 um 19:33 schrieb Manfred:
>> On 9/3/2021 5:02 PM, Bonita Montero wrote:
>>> Am 03.09.2021 um 15:59 schrieb james...@alumni.caltech.edu:
>>>> On Friday, September 3, 2021 at 1:10:37 AM UTC-4, Bonita Montero wrote:
>>>>> Am 02.09.2021 um 20:28 schrieb james...@alumni.caltech.edu:
>>>>>
>>>>>> The platform doesn't have pointers - that's a C concept. ...
>>>>>
>>>>> If they allow memory-addressing they know pointers.
>>>>
>>>> A platform can only be said to "know" something if it's running a
>>>> program.
>>>
>>> Machine-level does know pointers and architecture-depenent data-types:
>>>      MOV EBX, DWORD PTR [EAX + ECX * 8]
>>> Rest of your nonsense unread.
>>>
>>
>> Actually that's an example of the difference between a pointer and an
>> address.
>
>The pointer DWORD PTR [EAX + ECX * 8] is typed: DWORD.

I don't see any DWORD in assembly. The fact that Intel annotated the assembler
source syntax is meaningless with respect to the difference between a pointer
and an address.

262: e8 00 00 00 00 callq 267 <_ZN8c_system4initEv+0x1b7>
267: 48 8d 74 24 10 lea 0x10(%rsp),%rsi
26c: 48 89 e7 mov %rsp,%rdi
26f: e8 00 00 00 00 callq 274 <_ZN8c_system4initEv+0x1c4>
274: 4c 89 e7 mov %r12,%rdi
277: 8b 48 14 mov 0x14(%rax),%ecx
27a: 8d 91 6c 07 00 00 lea 0x76c(%rcx),%edx
280: 48 63 d2 movslq %edx,%rdx
283: 48 89 93 f0 09 00 00 mov %rdx,0x9f0(%rbx)
28a: 8b 48 10 mov 0x10(%rax),%ecx
28d: 8d 51 01 lea 0x1(%rcx),%edx
290: 48 63 d2 movslq %edx,%rdx
293: 48 89 93 f8 09 00 00 mov %rdx,0x9f8(%rbx)
29a: 48 63 50 0c movslq 0xc(%rax),%rdx
29e: 48 89 93 00 0a 00 00 mov %rdx,0xa00(%rbx)
2a5: 48 63 48 08 movslq 0x8(%rax),%rcx
2a9: 48 69 c9 10 0e 00 00 imul $0xe10,%rcx,%rcx
2b0: 48 89 8b 08 0a 00 00 mov %rcx,0xa08(%rbx)
2b7: 48 63 50 04 movslq 0x4(%rax),%rdx
2bb: 48 8d 34 95 00 00 00 lea 0x0(,%rdx,4),%rsi
2c2: 00
2c3: 48 c1 e2 06 shl $0x6,%rdx
2c7: 48 29 f2 sub %rsi,%rdx
2ca: 48 01 ca add %rcx,%rdx
2cd: 48 8b 4c 24 08 mov 0x8(%rsp),%rcx
2d2: 48 89 93 08 0a 00 00 mov %rdx,0xa08(%rbx)
2d9: 48 63 00 movslq (%rax),%rax
2dc: 48 c7 83 28 0a 00 00 movq $0xffffffffffffffff,0xa28(%rbx)

"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:

> On Friday, September 3, 2021 at 11:03:12 AM UTC-4, Bonita Montero wrote:
>> Am 03.09.2021 um 15:59 schrieb james...@alumni.caltech.edu:
>> > On Friday, September 3, 2021 at 1:10:37 AM UTC-4, Bonita Montero wrote:
>> >> Am 02.09.2021 um 20:28 schrieb james...@alumni.caltech.edu:
>> >>
>> >>> The platform doesn't have pointers - that's a C concept. ...
>> >>
>> >> If they allow memory-addressing they know pointers.
>> >
>> > A platform can only be said to "know" something if it's running a program.
>> Machine-level does know pointers and architecture-depenent data-types:
>> MOV EBX, DWORD PTR [EAX + ECX * 8]
>> Rest of your nonsense unread.
>
> On a platform such as the one I've described, with no hardware support for
> access to any piece of memory smaller than 16 bits, and a compiler which
> chooses to set CHAR_BIT == 8, the following function:
>
> void add_3a(unsigned char *p) { *p += 3; }
>
> Would have to be compiled into machine code which does something
> similar to:
>
> struct _byteptr {
> int *addr
> int offset;
> };

I used (as was tangentially involved in the implementation of) C on a
machine that had 16 bit words and only word addressing. The choice made
there was to use the bottom bit to select between the two halves of the
word addressed by the pointer (shifted right by 1).

--
Ben.

On 9/3/21 2:10 PM, Ben Bacarisse wrote:
> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
....
>> On a platform such as the one I've described, with no hardware support for
>> access to any piece of memory smaller than 16 bits, and a compiler which
>> chooses to set CHAR_BIT == 8, the following function:
>>
>> void add_3a(unsigned char *p) { *p += 3; }
>>
>> Would have to be compiled into machine code which does something
>> similar to:
>>
>> struct _byteptr {
>> int *addr
>> int offset;
>> };
>
> I used (as was tangentially involved in the implementation of) C on a
> machine that had 16 bit words and only word addressing. The choice made
> there was to use the bottom bit to select between the two halves of the
> word addressed by the pointer (shifted right by 1).

If I understand you correctly, that's a workable approach so long as you
have no more than 32768 words of addressable memory. However, as such,
it's not an example of an implementation where sizeof(void*) > sizeof(int*).

I replied to an email from you instead of the public post. Please don't
mail copies of posts...

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 9/3/21 2:10 PM, Ben Bacarisse wrote:
>> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
> ...
>>> On a platform such as the one I've described, with no hardware support for
>>> access to any piece of memory smaller than 16 bits, and a compiler which
>>> chooses to set CHAR_BIT == 8, the following function:
>>>
>>> void add_3a(unsigned char *p) { *p += 3; }
>>>
>>> Would have to be compiled into machine code which does something
>>> similar to:
>>>
>>> struct _byteptr {
>>> int *addr
>>> int offset;
>>> };
>>
>> I used (as was tangentially involved in the implementation of) C on a
>> machine that had 16 bit words and only word addressing. The choice made
>> there was to use the bottom bit to select between the two halves of the
>> word addressed by the pointer (shifted right by 1).
>
> If I understand you correctly, that's a workable approach so long as you
> have no more than 32768 words of addressable memory.

Yes. It was a per-process limit. The machine had more than that in total.

> However, as such,
> it's not an example of an implementation where sizeof(void*) > sizeof(int*).

Yes. I was only showing another approach to implementing byte
addresses.

--
Ben.

On 03/09/2021 18:54, Scott Lurndal wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 03.09.2021 um 19:33 schrieb Manfred:
>>> On 9/3/2021 5:02 PM, Bonita Montero wrote:
>>>> Am 03.09.2021 um 15:59 schrieb james...@alumni.caltech.edu:
>>>>> On Friday, September 3, 2021 at 1:10:37 AM UTC-4, Bonita Montero wrote:
>>>>>> Am 02.09.2021 um 20:28 schrieb james...@alumni.caltech.edu:
>>>>>>
>>>>>>> The platform doesn't have pointers - that's a C concept. ...
>>>>>>
>>>>>> If they allow memory-addressing they know pointers.
>>>>>
>>>>> A platform can only be said to "know" something if it's running a
>>>>> program.
>>>>
>>>> Machine-level does know pointers and architecture-depenent data-types:
>>>>      MOV EBX, DWORD PTR [EAX + ECX * 8]
>>>> Rest of your nonsense unread.
>>>>
>>>
>>> Actually that's an example of the difference between a pointer and an
>>> address.
>>
>> The pointer DWORD PTR [EAX + ECX * 8] is typed: DWORD.
>
> I don't see any DWORD in assembly. The fact that Intel annotated the assembler
> source syntax is meaningless with respect to the difference between a pointer
> and an address.
>
> 262: e8 00 00 00 00 callq 267 <_ZN8c_system4initEv+0x1b7>
> 267: 48 8d 74 24 10 lea 0x10(%rsp),%rsi
> 26c: 48 89 e7 mov %rsp,%rdi
> 26f: e8 00 00 00 00 callq 274 <_ZN8c_system4initEv+0x1c4>
> 274: 4c 89 e7 mov %r12,%rdi
> 277: 8b 48 14 mov 0x14(%rax),%ecx
> 27a: 8d 91 6c 07 00 00 lea 0x76c(%rcx),%edx
> 280: 48 63 d2 movslq %edx,%rdx
> 283: 48 89 93 f0 09 00 00 mov %rdx,0x9f0(%rbx)
> 28a: 8b 48 10 mov 0x10(%rax),%ecx
> 28d: 8d 51 01 lea 0x1(%rcx),%edx
> 290: 48 63 d2 movslq %edx,%rdx
> 293: 48 89 93 f8 09 00 00 mov %rdx,0x9f8(%rbx)
> 29a: 48 63 50 0c movslq 0xc(%rax),%rdx
> 29e: 48 89 93 00 0a 00 00 mov %rdx,0xa00(%rbx)
> 2a5: 48 63 48 08 movslq 0x8(%rax),%rcx
> 2a9: 48 69 c9 10 0e 00 00 imul $0xe10,%rcx,%rcx
> 2b0: 48 89 8b 08 0a 00 00 mov %rcx,0xa08(%rbx)
> 2b7: 48 63 50 04 movslq 0x4(%rax),%rdx
> 2bb: 48 8d 34 95 00 00 00 lea 0x0(,%rdx,4),%rsi
> 2c2: 00
> 2c3: 48 c1 e2 06 shl $0x6,%rdx
> 2c7: 48 29 f2 sub %rsi,%rdx
> 2ca: 48 01 ca add %rcx,%rdx
> 2cd: 48 8b 4c 24 08 mov 0x8(%rsp),%rcx
> 2d2: 48 89 93 08 0a 00 00 mov %rdx,0xa08(%rbx)
> 2d9: 48 63 00 movslq (%rax),%rax
> 2dc: 48 c7 83 28 0a 00 00 movq $0xffffffffffffffff,0xa28(%rbx)
>

You'd get the same output from compiled HLL code.

The 'dword' part in Intel assembly syntax, and the -l suffix used above,
serve the same purpose in telling the assembler that that particular
pointer/address refers to a 4-byte-wide memory location rather than 1, 2
or 8 bytes.

It helps it choose the correct instruction encoding.

However it is unnecessary in the 'move ebx' example as the pointer type
can be inferred from the destination register size.

On 9/3/21 2:45 PM, Ben Bacarisse wrote:
> I replied to an email from you instead of the public post. Please don't
> mail copies of posts...

Sorry - it's been a couple of months since Mozilla Thunderbird changes
the meaning of the "Reply" button, and added a "Followup" button. Since
I've spent a couple of decades hitting the "Reply" button when I want to
follow-up on a usenet message, it's taking me quite a while to break
that habit. I'm still hitting "Reply" far more often than "Followup",
and only occasionally noticing the mistake before hitting "Send".

Bart <bc@freeuk.com> writes:
>On 03/09/2021 18:54, Scott Lurndal wrote:

>You'd get the same output from compiled HLL code.
>
>The 'dword' part in Intel assembly syntax, and the -l.

Indeed. Unnecessarily noisy.

Am 03.09.2021 um 19:49 schrieb james...@alumni.caltech.edu:
> On Friday, September 3, 2021 at 11:03:12 AM UTC-4, Bonita Montero wrote:
>> Am 03.09.2021 um 15:59 schrieb james...@alumni.caltech.edu:
>>> On Friday, September 3, 2021 at 1:10:37 AM UTC-4, Bonita Montero wrote:
>>>> Am 02.09.2021 um 20:28 schrieb james...@alumni.caltech.edu:
>>>>
>>>>> The platform doesn't have pointers - that's a C concept. ...
>>>>
>>>> If they allow memory-addressing they know pointers.
>>>
>>> A platform can only be said to "know" something if it's running a program.
>> Machine-level does know pointers and architecture-depenent data-types:
>> MOV EBX, DWORD PTR [EAX + ECX * 8]
>> Rest of your nonsense unread.
>
> On a platform such as the one I've described, with no hardware support for
> access to any piece of memory smaller than 16 bits, ...

That's not what we've been discussing.
Rest of your nonsense unread.

On 03/09/2021 20:10, Ben Bacarisse wrote:

>
> I used (as was tangentially involved in the implementation of) C on a
> machine that had 16 bit words and only word addressing. The choice made
> there was to use the bottom bit to select between the two halves of the
> word addressed by the pointer (shifted right by 1).
>

There are a number of microcontrollers that have a similar principle for
bit-sized accesses (with hardware support, rather than
compiler-generated code for using the bit pointers). This is typically
restricted to a particular section of on-chip ram (or peripheral
registers) that is mapped in two address areas - one as bytes (or
bigger), and one as bits using byte addresses. It can be very handy for
giving fast, atomic bit-wise access.

On Saturday, September 4, 2021 at 3:11:34 AM UTC-4, Bonita Montero wrote:
> Am 03.09.2021 um 19:49 schrieb james...@alumni.caltech.edu:
> > On Friday, September 3, 2021 at 11:03:12 AM UTC-4, Bonita Montero wrote:
> >> Am 03.09.2021 um 15:59 schrieb james...@alumni.caltech.edu:
> >>> On Friday, September 3, 2021 at 1:10:37 AM UTC-4, Bonita Montero wrote:
> >>>> Am 02.09.2021 um 20:28 schrieb james...@alumni.caltech.edu:
> >>>>
> >>>>> The platform doesn't have pointers - that's a C concept. ...
> >>>>
> >>>> If they allow memory-addressing they know pointers.
> >>>
> >>> A platform can only be said to "know" something if it's running a program.
> >> Machine-level does know pointers and architecture-depenent data-types:
> >> MOV EBX, DWORD PTR [EAX + ECX * 8]
> >> Rest of your nonsense unread.
> >
> > On a platform such as the one I've described, with no hardware support for
> > access to any piece of memory smaller than 16 bits, ...
>
> That's not what we've been discussing.

The Subject: header for this thread says "sizeof(void*) > sizeof(int*)". While the
standard permits this without imposing any requirements on the reason, the
only real-world implementations I've heard of which had that characteristics
were implementations which choose to have CHAR_BIT smaller than the
number of bits in the smallest hardware-addressable unit of memory. Every
comment I've posted to this thread was about such systems; I believe that this
has also been the case for many of the other posters, though they haven't all
been clear about the matter. If you ever responded to one of my comments on
this thread, discussing a system for which that wasn't the case, then you
weren't meaningfully responding to my comments.

On Friday, September 3, 2021 at 1:47:34 PM UTC-4, Bonita Montero wrote:
> Am 03.09.2021 um 19:33 schrieb Manfred:
> > On 9/3/2021 5:02 PM, Bonita Montero wrote:
> >> Am 03.09.2021 um 15:59 schrieb james...@alumni.caltech.edu:
> >>> On Friday, September 3, 2021 at 1:10:37 AM UTC-4, Bonita Montero wrote:
> >>>> Am 02.09.2021 um 20:28 schrieb james...@alumni.caltech.edu:
> >>>>
> >>>>> The platform doesn't have pointers - that's a C concept. ...
> >>>>
> >>>> If they allow memory-addressing they know pointers.
> >>>
> >>> A platform can only be said to "know" something if it's running a
> >>> program.
> >>
> >> Machine-level does know pointers and architecture-depenent data-types:

For the implementations in question, a char is NOT an architecture- dependent
data-type, because the target architecture doesn't know about any data type
smaller than a word, and therefore has no instructions for retrieving such data
types. Operations involving smaller data types can only be emulated in
software - there is no hardware support for them.

> >> MOV EBX, DWORD PTR [EAX + ECX * 8]
> >> Rest of your nonsense unread.
> >>
> >
> > Actually that's an example of the difference between a pointer and an
> > address.
> The pointer DWORD PTR [EAX + ECX * 8] is typed: DWORD.

As I said, in machine language "What type of thing it points at is
determined by the code that uses that address.". You could just as easily
use a different instruction to retrieve a single word from the same address.
That's very different from C pointers, where the behavior and permitted
operations depends very strongly on the pointer type.

Am 04.09.2021 um 20:27 schrieb james...@alumni.caltech.edu:
> On Saturday, September 4, 2021 at 3:11:34 AM UTC-4, Bonita Montero wrote:
>> Am 03.09.2021 um 19:49 schrieb james...@alumni.caltech.edu:
>>> On Friday, September 3, 2021 at 11:03:12 AM UTC-4, Bonita Montero wrote:
>>>> Am 03.09.2021 um 15:59 schrieb james...@alumni.caltech.edu:
>>>>> On Friday, September 3, 2021 at 1:10:37 AM UTC-4, Bonita Montero wrote:
>>>>>> Am 02.09.2021 um 20:28 schrieb james...@alumni.caltech.edu:
>>>>>>
>>>>>>> The platform doesn't have pointers - that's a C concept. ...
>>>>>>
>>>>>> If they allow memory-addressing they know pointers.
>>>>>
>>>>> A platform can only be said to "know" something if it's running a program.
>>>> Machine-level does know pointers and architecture-depenent data-types:
>>>> MOV EBX, DWORD PTR [EAX + ECX * 8]
>>>> Rest of your nonsense unread.
>>>
>>> On a platform such as the one I've described, with no hardware support for
>>> access to any piece of memory smaller than 16 bits, ...
>>
>> That's not what we've been discussing.
>
> The Subject: header for this thread says "sizeof(void*) > sizeof(int*)". ...

This sub-thread is about typing of assembly.

On Saturday, September 4, 2021 at 10:25:22 PM UTC-4, Bonita Montero wrote:
> Am 04.09.2021 um 20:27 schrieb james...@alumni.caltech.edu:
> > On Saturday, September 4, 2021 at 3:11:34 AM UTC-4, Bonita Montero wrote:
> >> Am 03.09.2021 um 19:49 schrieb james...@alumni.caltech.edu:
> >>> On Friday, September 3, 2021 at 11:03:12 AM UTC-4, Bonita Montero wrote:
....
> >>>> Machine-level does know pointers and architecture-depenent data-types:
> >>>> MOV EBX, DWORD PTR [EAX + ECX * 8]
> >>>> Rest of your nonsense unread.
> >>>
> >>> On a platform such as the one I've described, with no hardware support for
> >>> access to any piece of memory smaller than 16 bits, ...
> >>
> >> That's not what we've been discussing.
> >
> > The Subject: header for this thread says "sizeof(void*) > sizeof(int*)". ...
>
> This sub-thread is about typing of assembly.

You've sidetracked the discussion is that direction, but that sidetracking occurred in the
context of the following comments:

On Thursday, September 2, 2021 at 2:28:11 PM UTC-4, james...@alumni.caltech.edu wrote:
> On Wednesday, September 1, 2021 at 11:37:37 PM UTC-4, Bonita Montero wrote:
....
> > Keep in mind that not being able to address bytes is the single most
> > common reason for having two or more different sizes of pointers.
> No, on the platforms where you don't have byte-pointers you almost never
> have typed pointers.

Assembly language addresses aren't typed pointers. As your own example demonstrated,
it has typed instructions for accessing data at a specified address. An address can be
used to access different types of data depending only upon what instruction it is passed
to. C's pointers, which actually are typed, can only be safely used to access an object or
function with a type that's compatible with the one that the pointer's type is derived from.
But the most important point is that, for an implementation that chooses to define
CHAR_BIT to be smaller than the smallest hardware-addressable unit of memory on the
target platform, byte-pointers are, by definition, a feature of that implementation, and not
something that the hardware knows anything about. At the very least, char*, signed char*,
unsigned char*, and void* are all required to have the same representation, and on such an
implementation their representation is necessarily not one that corresponds simply to a
machine address, since it must be able to point at individual bytes within a word.
You used the term "architecture-dependent data types". While these types may depend
upon the architecture, they only as part of the design of the C implementation, the
architecture itself knows nothing about them.

On 01/09/2021 22:07, Michael S wrote:
> I didn't yet encounter in real physical life a C programmer that cared in a slightest about portability or C Standard.
> Only on Internet.

Then I'm your first.

I write code for embedded devices that use three different processor
families - ARM, MIPS and Intel.

The chip manufacturers supply us with a Linux port and some other stuff
I can't discuss, but our code has to be platform agnostic.

Andy

On 9/7/21 4:12 PM, Vir Campestris wrote:
> On 01/09/2021 22:07, Michael S wrote:
>> I didn't yet encounter in real physical life a C programmer that cared in a slightest about portability or C Standard.
>> Only on Internet.
>
> Then I'm your first.

You've met Michael S in real physical life, and not just on the internet?

Am 07.09.2021 um 01:10 schrieb james...@alumni.caltech.edu:
> On Saturday, September 4, 2021 at 10:25:22 PM UTC-4, Bonita Montero wrote:
>> Am 04.09.2021 um 20:27 schrieb james...@alumni.caltech.edu:
>>> On Saturday, September 4, 2021 at 3:11:34 AM UTC-4, Bonita Montero wrote:
>>>> Am 03.09.2021 um 19:49 schrieb james...@alumni.caltech.edu:
>>>>> On Friday, September 3, 2021 at 11:03:12 AM UTC-4, Bonita Montero wrote:
> ...
>>>>>> Machine-level does know pointers and architecture-depenent data-types:
>>>>>> MOV EBX, DWORD PTR [EAX + ECX * 8]
>>>>>> Rest of your nonsense unread.
>>>>>
>>>>> On a platform such as the one I've described, with no hardware support for
>>>>> access to any piece of memory smaller than 16 bits, ...
>>>>
>>>> That's not what we've been discussing.
>>>
>>> The Subject: header for this thread says "sizeof(void*) > sizeof(int*)". ...
>>
>> This sub-thread is about typing of assembly.
>
> You've sidetracked the discussion is that direction, but that sidetracking occurred in the
> context of the following comments:
>
> On Thursday, September 2, 2021 at 2:28:11 PM UTC-4, james...@alumni.caltech.edu wrote:
>> On Wednesday, September 1, 2021 at 11:37:37 PM UTC-4, Bonita Montero wrote:
> ...
>>> Keep in mind that not being able to address bytes is the single most
>>> common reason for having two or more different sizes of pointers.
>> No, on the platforms where you don't have byte-pointers you almost never
>> have typed pointers.
>
> Assembly language addresses aren't typed pointers. ...

When you use a register as a pointer you attach a type which directs
the CPU to load a value from memory with a certain width - that's a
type -, like BYTE, WORD, DWORD, QWORD.

Rest of your nonsense unread.

On Wednesday, September 8, 2021 at 1:44:40 PM UTC-4, Bonita Montero wrote:
> Am 07.09.2021 um 01:10 schrieb james...@alumni.caltech.edu:
> > On Saturday, September 4, 2021 at 10:25:22 PM UTC-4, Bonita Montero wrote:
> >> Am 04.09.2021 um 20:27 schrieb james...@alumni.caltech.edu:
> > On Thursday, September 2, 2021 at 2:28:11 PM UTC-4, james...@alumni.caltech.edu wrote:
> >> On Wednesday, September 1, 2021 at 11:37:37 PM UTC-4, Bonita Montero wrote:
....
> >>> Keep in mind that not being able to address bytes is the single most
> >>> common reason for having two or more different sizes of pointers.
> >> No, on the platforms where you don't have byte-pointers you almost never
> >> have typed pointers.
> >
> > Assembly language addresses aren't typed pointers. ...
>
> When you use a register as a pointer you attach a type which directs
> the CPU to load a value from memory with a certain width - that's a
> type -, like BYTE, WORD, DWORD, QWORD.

Agreed - the assembly language you showed uses a PTR keyword with a
specified type as part of the instruction syntax. But - and this is the most
important point - the implementations under discussion in this thread set
CHAR_BIT to a size smaller than the number of bits retrieved by any of the
available instructions on the platforms under discussion; either they don't have
a BYTE instruction modifier, or the size of the BYTE that they retrieve when that
modifier is used has more than CHAR_BIT bits, and therefore does not
correspond to the "byte" defined by the C implementation. This doesn't prevent
a C implementation targeting that platform from having [[un]signed] char*
and void* pointers. They are simply emulated in software, not implemented in
hardware. Getting back to the Subject: header for this thread, that emulation
may require sizeof(void*) > sizeof(int*).
Far less important is your misuse of the term "typed pointers", which means
something quite different; what you've described are typed instructions. C's
typed pointers are associated with declared objects, and not with the
operations performed on those objects. The type of a C pointer determines
which operations can safely be performed on it, rather than being determined
by which operation is performed on it.
You might be correct that such platforms don't have what you call "typed
pointers", and what I call "typed instructions". It only matters whether the C
implementation has what is more conventionally called a "typed pointer", as
it's required to have. Those can be emulated in software, whether or not the
platform has typed instructions.

On Tuesday, September 7, 2021 at 11:12:37 PM UTC+3, Vir Campestris wrote:
> On 01/09/2021 22:07, Michael S wrote:
> > I didn't yet encounter in real physical life a C programmer that cared in a slightest about portability or C Standard.
> > Only on Internet.
>
> Then I'm your first.
>

No, you are not.
I don't know you in real physical life.

> I write code for embedded devices that use three different processor
> families - ARM, MIPS and Intel.
>
> The chip manufacturers supply us with a Linux port and some other stuff
> I can't discuss, but our code has to be platform agnostic.
>
> Andy

Am 08.09.2021 um 20:45 schrieb james...@alumni.caltech.edu:
> On Wednesday, September 8, 2021 at 1:44:40 PM UTC-4, Bonita Montero wrote:
>> Am 07.09.2021 um 01:10 schrieb james...@alumni.caltech.edu:
>>> On Saturday, September 4, 2021 at 10:25:22 PM UTC-4, Bonita Montero wrote:
>>>> Am 04.09.2021 um 20:27 schrieb james...@alumni.caltech.edu:
>>> On Thursday, September 2, 2021 at 2:28:11 PM UTC-4, james...@alumni.caltech.edu wrote:
>>>> On Wednesday, September 1, 2021 at 11:37:37 PM UTC-4, Bonita Montero wrote:
> ...
>>>>> Keep in mind that not being able to address bytes is the single most
>>>>> common reason for having two or more different sizes of pointers.
>>>> No, on the platforms where you don't have byte-pointers you almost never
>>>> have typed pointers.
>>>
>>> Assembly language addresses aren't typed pointers. ...
>>
>> When you use a register as a pointer you attach a type which directs
>> the CPU to load a value from memory with a certain width - that's a
>> type -, like BYTE, WORD, DWORD, QWORD.
>
> Agreed - the assembly language you showed uses a PTR keyword with a
> specified type as part of the instruction syntax. But - and this is the most
> important point - the implementations under discussion in this thread set
> CHAR_BIT to a size smaller than the number of bits retrieved by any of the
> available instructions on the platforms under discussion; ...

That's not what we're discussing here.

On Thursday, September 9, 2021 at 1:09:48 PM UTC-4, Bonita Montero wrote:
> Am 08.09.2021 um 20:45 schrieb james...@alumni.caltech.edu:
....
> > Agreed - the assembly language you showed uses a PTR keyword with a
> > specified type as part of the instruction syntax. But - and this is the most
> > important point - the implementations under discussion in this thread set
> > CHAR_BIT to a size smaller than the number of bits retrieved by any of the
> > available instructions on the platforms under discussion; ...
>
> That's not what we're discussing here.

Such systems are the only ones I've been discussing on this thread from the
very beginning, because such systems are the only ones I'm aware of where
sizeof(void*) > sizeof(int*), as specified in the Subject: header. To the best of
my knowledge, the same is true of the other participants in this discussion
(though in some cases they've been less than clear about the matter). Why
do you keep changing the subject by talking about some other kind of
system? How are the systems you were discussing relevant to the Subject:
header?

Am 09.09.2021 um 19:51 schrieb james...@alumni.caltech.edu:
> On Thursday, September 9, 2021 at 1:09:48 PM UTC-4, Bonita Montero wrote:
>> Am 08.09.2021 um 20:45 schrieb james...@alumni.caltech.edu:
> ...
>>> Agreed - the assembly language you showed uses a PTR keyword with a
>>> specified type as part of the instruction syntax. But - and this is the most
>>> important point - the implementations under discussion in this thread set
>>> CHAR_BIT to a size smaller than the number of bits retrieved by any of the
>>> available instructions on the platforms under discussion; ...
>>
>> That's not what we're discussing here.
>
> Such systems are the only ones I've been discussing on this thread from the
> very beginning, ...

Discuss this at a different point in this thread where it fits.

On Friday, September 10, 2021 at 4:31:54 AM UTC-4, Bonita Montero wrote:
> Am 09.09.2021 um 19:51 schrieb james...@alumni.caltech.edu:
> > On Thursday, September 9, 2021 at 1:09:48 PM UTC-4, Bonita Montero wrote:
> >> Am 08.09.2021 um 20:45 schrieb james...@alumni.caltech.edu:
> > ...
> >>> Agreed - the assembly language you showed uses a PTR keyword with a
> >>> specified type as part of the instruction syntax. But - and this is the most
> >>> important point - the implementations under discussion in this thread set
> >>> CHAR_BIT to a size smaller than the number of bits retrieved by any of the
> >>> available instructions on the platforms under discussion; ...
> >>
> >> That's not what we're discussing here.
> >
> > Such systems are the only ones I've been discussing on this thread from the
> > very beginning, ...
>
> Discuss this at a different point in this thread where it fits.

Every message on this thread other than yours has been directly or indirectly
about the Subject: header, "sizeof(void*)>sizeof(int*)", for which platforms that
are not byte-addressable are entirely relevant, because such systems are the
only types of platforms for which anybody has even suggested that such
implementations might exist. There might be other reasons for having
"sizeof(void*)>sizeof(int*)", but no other reasons have been discussed in this
thread.
David mentioned such platforms in his message of September 1st. You
responded by claiming they are nearly non-existent, and he responded by
identifying some current ones, to which you responded:

> The issue is not about whether they're can't address raw bytes but just
> larger quantities. The issue is about machines with typed pointers, i.e.
> when you cast a pointer they change their bit-representation

Every message you've posted since then has reflected that
misconception, and is therefore an appropriate opportunity to point out
that it is a misconceptions, as I have been doing.

Platforms where raw bytes cannot be addressed are the only ones
anyone has identified as possibly supporting C implementations with
two or more different pointer representations with different sizes. If you
know of any other reasons why an implementation might have multiple
pointer sizes, that's fine, but it does not render those platforms irrelevant.
Do you know of any machines with typed pointers that have C
implementations where "sizeof(void*)>sizeof(int*)"? If so, identifying
such machines would be extremely relevant to this thread.
However, claiming that all machines that are not byte addressable lack
typed pointers is irrelevant. It is not the hardware pointers that matter,
but the pointers supported by the C implementation. A C implementation
for a platform that cannot address individual bytes, can still implement C
pointers that address bytes, with a representation that is meaningless to
the hardware; and those pointers might be larger than the ones that only
need to address larger memory units. Whether or not that platform
supports typed pointers is irrelevant - it only matters whether the C
implementation does so.