Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #162505 > unrolled thread

Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ?

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Lynn McGuire <lynnmcguire5@gmail.com> - 2021-08-30 21:59 -0500
    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-08-30 21:53 -0700
      Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-08-30 21:59 -0700
    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-08-31 09:01 +0200
      Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Lynn McGuire <lynnmcguire5@gmail.com> - 2021-08-31 23:46 -0500
        Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 08:19 +0200
        Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 15:32 +0000
          Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 19:20 +0200
            Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 19:44 +0200
              Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Lynn McGuire <lynnmcguire5@gmail.com> - 2021-09-01 13:17 -0500
                Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 20:32 +0200
                Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 19:00 +0000
                  Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Lynn McGuire <lynnmcguire5@gmail.com> - 2021-09-01 15:06 -0500
                    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 20:14 +0000
                      Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Michael S <already5chosen@yahoo.com> - 2021-09-01 14:04 -0700
                        Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 23:44 +0000
              Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 20:37 +0200
                Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-01 12:43 -0700
                  Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-02 05:37 +0200
                    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-02 11:28 -0700
                      Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-03 07:10 +0200
                        Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-03 06:59 -0700
                          Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-03 17:02 +0200
                            Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Manfred <noname@add.invalid> - 2021-09-03 19:33 +0200
                              Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-03 19:47 +0200
                                Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-03 17:54 +0000
                                  Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-03 20:54 +0100
                                    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-03 20:52 +0000
                                Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-04 12:36 -0700
                            Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-03 10:49 -0700
                              Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-03 19:10 +0100
                                Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-03 14:20 -0400
                                  Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-03 19:45 +0100
                                    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-03 16:35 -0400
                                Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-04 13:12 +0200
                              Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-04 09:11 +0200
                                Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-04 11:27 -0700
                                  Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-05 04:25 +0200
                                    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-06 16:10 -0700
                                      Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-08 19:44 +0200
                                        Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-08 11:45 -0700
                                          Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-09 19:09 +0200
                                            Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-09 10:51 -0700
                                              Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-10 10:31 +0200
                                                Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-10 10:41 -0700
                                                  Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-14 04:14 +0200
                                                    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-14 07:45 -0700
              Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-01 20:34 +0100
                Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-01 13:02 -0700
                Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 20:18 +0000
                  Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Michael S <already5chosen@yahoo.com> - 2021-09-01 14:07 -0700
                    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-01 22:18 +0100
                    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-09-01 18:23 -0700
                    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-02 13:35 +0200
                      Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-09-02 05:24 -0700
                    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-09-02 14:56 -0600
                    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Vir Campestris <vir.campestris@invalid.invalid> - 2021-09-07 21:12 +0100
                      Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-07 22:19 -0400
                        Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Vir Campestris <vir.campestris@invalid.invalid> - 2021-09-12 21:23 +0100
                      Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Michael S <already5chosen@yahoo.com> - 2021-09-09 08:36 -0700
                  Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Lynn McGuire <lynnmcguire5@gmail.com> - 2021-09-01 17:46 -0500
                    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-01 16:53 -0700
                      Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Lynn McGuire <lynnmcguire5@gmail.com> - 2021-09-02 17:11 -0500
                  Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-09-01 16:59 -0700
                    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-01 17:01 -0700
                  Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-02 01:29 +0100
                Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-02 13:29 +0200
                  Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-02 14:19 +0100
                    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-02 17:10 -0700
                  Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Michael S <already5chosen@yahoo.com> - 2021-09-02 07:28 -0700
                    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-02 21:07 +0200
                      Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Michael S <already5chosen@yahoo.com> - 2021-09-02 13:05 -0700
                      Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-02 17:18 -0700
                        Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-03 01:25 +0100
    Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Mark Bluemel <mark.bluemel@gmail.com> - 2021-09-01 03:30 -0700
      Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Mark Bluemel <mark.bluemel@gmail.com> - 2021-09-01 03:36 -0700
      Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Lynn McGuire <lynnmcguire5@gmail.com> - 2021-09-01 12:49 -0500
        Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Mark Bluemel <mark.bluemel@gmail.com> - 2021-09-01 14:30 -0700

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#162677

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.

[toc] | [prev] | [next] | [standalone]

#162684

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.

[toc] | [prev] | [next] | [standalone]

#162685

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?

[toc] | [prev] | [next] | [standalone]

#162686

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.

[toc] | [prev] | [next] | [standalone]

#162711

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.

[toc] | [prev] | [next] | [standalone]

#162756

Am 10.09.2021 um 19:41 schrieb james...@alumni.caltech.edu:

>> 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*)", ...

Subthreads change their topic.
Rest unraed.

[toc] | [prev] | [next] | [standalone]

#162758

On Monday, September 13, 2021 at 10:15:08 PM UTC-4, Bonita Montero wrote:
> Am 10.09.2021 um 19:41 schrieb james...@alumni.caltech.edu: 
> 
> >> 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*)", ... 
> 
> Subthreads change their topic. 

Yes, but there's a procedure for doing that. You must, at the very least, mention
the new topic. If it deviates largely enough from the previous target, it's a good
practice to explicitly mention that you're changing the topic. How can you tell
whether such a warning is needed? Well, if you would criticize someone for
responding to your message with a comment that is relevant to the original
topic, but not to your new topic, then you should probably include a warning.
What you did was quite different. People posted comments that were relevant
to the the topic they were discussing. You responded to their messages by
criticizing them for not being relevant to "the issue", as if there was only one
issue, and it was the one you wanted to discuss, and not the one they had been
discussing. That is not the right way to change the topic.
You've explained so little about your new topic that I'm not even sure what it is.
All I've been able to figure out about your new topic is that machines which
provide typed syntax for accessing the memory at a specified address are
relevant to the topic, whereas C implementations that provide typed pointers of
differing sizes are not.

[toc] | [prev] | [next] | [standalone]

#162545

On 01/09/2021 18:44, David Brown wrote:
> On 01/09/2021 19:20, Bonita Montero wrote:
>> Am 01.09.2021 um 17:32 schrieb Scott Lurndal:
>>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>>> On 8/31/2021 2:01 AM, Bo Persson wrote:
>>>>> On 2021-08-31 at 04:59, Lynn McGuire wrote:
>>>>>> On 8/29/2021 1:57 PM, Alf P. Steinbach wrote:
>>>>>>> Are there any examples of current platforms/architectures where
>>>>>>> sizeof(void*) > sizeof(int*) ?
>>>>>>>
>>>>>>> - Alf
>>>>>>
>>>>>> Are there any old platforms where this was the case also ?
>>>>>>
>>>>>> Lynn
>>>>>>
>>>>>
>>>>> It would have been word-addressed machines, where char* (and thus
>>>>> void*)
>>>>> needed a part-word indicator in addition to the word address.
>>>>>
>>>>> Haven't seen any of those lately.
>>>>
>>>> Yeah, can't think of a reason why to build anything other than a byte
>>>> addressable machine.
>>>
>>> Strong words from a fortran programmer.   How many CPUs have you
>>> designed in the last forty years?
>>>
>>> As David points out, many DSPs are not byte addressable, and there
>>> are other machines _STILL IN DAILY PRODUCTION_ that don't have
>>> byte addressability, yet support C compilers (e.g. both flavors
>>> of Unisys Clearpath).
>>
>> These are not "many" but according to the examples given yet
>> a homeopathic part.
>>
> 
> I believe there are more dedicated DSP's produced per year than 64-bit
> cpus.  There may even be more 4-bit microcontrollers still produced than
> 64-bit cpus.  AMD and Intel each sell perhaps 500,000 processors a year
> (according to a quick google search).  There are DSPs and other
> specialist microcontrollers with minimum order quantities of millions.
> I know of microcontrollers (programmable in C, and in this case with
> 8-bit char) that cost $0.03 each.
> 
> I don't know what you mean by "not many".  In terms of numbers of units,
> 8-bit devices and "hidden" microcontrollers and DSPs outsell 32-bit
> devices by orders of magnitude - and 32-bit devices similarly outsell PC
> processors.  In terms of numbers of designs or chips available, it's the
> same story.  PC processors lead in terms of total cost, and lead hugely
> in terms of the number of different people programming on them.

So, you want a programming language still extensively used for 
conventional 64-bit computer chips (eg. the x64s and ARMs) to have its 
design dictated by (or even crippled by) the limitations of a 4-bit 
microcontroller used in some toaster?

It's likely anyway that that 4-bit C compiler will be implementing a 
rather specific dialect of C, without worrying too much about how well 
it might work on 64-bit machines.

But we're not allowed to do the same when it's the other way around?

[toc] | [prev] | [next] | [standalone]

#162549

On Wednesday, September 1, 2021 at 3:35:17 PM UTC-4, Bart wrote:
> On 01/09/2021 18:44, David Brown wrote: 
...
> > I believe there are more dedicated DSP's produced per year than 64-bit 
> > cpus. There may even be more 4-bit microcontrollers still produced than 
> > 64-bit cpus. AMD and Intel each sell perhaps 500,000 processors a year 
> > (according to a quick google search). There are DSPs and other 
> > specialist microcontrollers with minimum order quantities of millions. 
> > I know of microcontrollers (programmable in C, and in this case with 
> > 8-bit char) that cost $0.03 each. 
> > 
> > I don't know what you mean by "not many". In terms of numbers of units, 
> > 8-bit devices and "hidden" microcontrollers and DSPs outsell 32-bit 
> > devices by orders of magnitude - and 32-bit devices similarly outsell PC 
> > processors. In terms of numbers of designs or chips available, it's the 
> > same story. PC processors lead in terms of total cost, and lead hugely 
> > in terms of the number of different people programming on them.
> So, you want a programming language still extensively used for 
> conventional 64-bit computer chips (eg. the x64s and ARMs) to have its 
> design dictated by (or even crippled by) the limitations of a 4-bit 
> microcontroller used in some toaster?

How exactly is it crippled? 

Nothing we've been talking about involves dictating the design of the
language for 64-bit chips. It involves deliberately NOT dictating that
compilers targeting smaller chips make the same design choices when
implementating that language.

The behavior can be unspecified, and even undefined when you write
code that makes the unportable assumption that all pointers have the same
representation. However, for an implementation where all pointers do have the
same representation, such code has behavior which is defined, by the
implementation, even if not by the standard. There's nothing wrong with
writing unportable code, so long as it can be ported to every platform that it
needs to be ported to.

[toc] | [prev] | [next] | [standalone]

#162552

Bart <bc@freeuk.com> writes:
>On 01/09/2021 18:44, David Brown wrote:

>> I don't know what you mean by "not many".  In terms of numbers of units,
>> 8-bit devices and "hidden" microcontrollers and DSPs outsell 32-bit
>> devices by orders of magnitude - and 32-bit devices similarly outsell PC
>> processors.  In terms of numbers of designs or chips available, it's the
>> same story.  PC processors lead in terms of total cost, and lead hugely
>> in terms of the number of different people programming on them.
>
>So, you want a programming language still extensively used for 
>conventional 64-bit computer chips (eg. the x64s and ARMs) to have its 
>design dictated by (or even crippled by) the limitations of a 4-bit 
>microcontroller used in some toaster?

The design of C, and the standards predate 64-bit computer chips
by some time.

>
>It's likely anyway that that 4-bit C compiler will be implementing a 
>rather specific dialect of C, without worrying too much about how well 
>it might work on 64-bit machines.

Actually, the typical C programmer wants his program to run on
any system that supports the standard regardless of the underlying
hardware.  The vast majority of C programmers don't even care what
the underlying hardware is.

>
>But we're not allowed to do the same when it's the other way around?

You can complain all you want if it pleases you.  It won't change
anything, so it seems somewhat pointless.

[toc] | [prev] | [next] | [standalone]

#162554

On Wednesday, September 1, 2021 at 11:18:51 PM UTC+3, Scott Lurndal wrote:
> Bart <b...@freeuk.com> writes: 
> >On 01/09/2021 18:44, David Brown wrote: 
> 
> >> I don't know what you mean by "not many". In terms of numbers of units, 
> >> 8-bit devices and "hidden" microcontrollers and DSPs outsell 32-bit 
> >> devices by orders of magnitude - and 32-bit devices similarly outsell PC 
> >> processors. In terms of numbers of designs or chips available, it's the 
> >> same story. PC processors lead in terms of total cost, and lead hugely 
> >> in terms of the number of different people programming on them. 
> > 
> >So, you want a programming language still extensively used for 
> >conventional 64-bit computer chips (eg. the x64s and ARMs) to have its 
> >design dictated by (or even crippled by) the limitations of a 4-bit 
> >microcontroller used in some toaster?
> The design of C, and the standards predate 64-bit computer chips 
> by some time.
> > 
> >It's likely anyway that that 4-bit C compiler will be implementing a 
> >rather specific dialect of C, without worrying too much about how well 
> >it might work on 64-bit machines.
> Actually, the typical C programmer wants his program to run on 
> any system that supports the standard regardless of the underlying 
> hardware. The vast majority of C programmers don't even care what 
> the underlying hardware is.

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.

> > 
> >But we're not allowed to do the same when it's the other way around?
> You can complain all you want if it pleases you. It won't change 
> anything, so it seems somewhat pointless.

[toc] | [prev] | [next] | [standalone]

#162555

On 01/09/2021 22:07, Michael S wrote:
> On Wednesday, September 1, 2021 at 11:18:51 PM UTC+3, Scott Lurndal wrote:
>> Bart <b...@freeuk.com> writes:
>>> On 01/09/2021 18:44, David Brown wrote:
>>
>>>> I don't know what you mean by "not many". In terms of numbers of units,
>>>> 8-bit devices and "hidden" microcontrollers and DSPs outsell 32-bit
>>>> devices by orders of magnitude - and 32-bit devices similarly outsell PC
>>>> processors. In terms of numbers of designs or chips available, it's the
>>>> same story. PC processors lead in terms of total cost, and lead hugely
>>>> in terms of the number of different people programming on them.
>>>
>>> So, you want a programming language still extensively used for
>>> conventional 64-bit computer chips (eg. the x64s and ARMs) to have its
>>> design dictated by (or even crippled by) the limitations of a 4-bit
>>> microcontroller used in some toaster?
>> The design of C, and the standards predate 64-bit computer chips
>> by some time.
>>>
>>> It's likely anyway that that 4-bit C compiler will be implementing a
>>> rather specific dialect of C, without worrying too much about how well
>>> it might work on 64-bit machines.
>> Actually, the typical C programmer wants his program to run on
>> any system that supports the standard regardless of the underlying
>> hardware. The vast majority of C programmers don't even care what
>> the underlying hardware is.
> 
> 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.

They might care when UB is used as an excuse for a compiler to do 
unexpected things, when that UB is actually well-defined on their 
platforms of interest.

[toc] | [prev] | [next] | [standalone]

#162566

On 9/1/2021 2:07 PM, 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.
> 

That's pretty much equivalent to saying that you've never encountered a 
C programmer in real life yet.

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#162579

On 01/09/2021 23:07, Michael S wrote:
> On Wednesday, September 1, 2021 at 11:18:51 PM UTC+3, Scott Lurndal
>> Actually, the typical C programmer wants his program to run on any
>> system that supports the standard regardless of the underlying 
>> hardware. The vast majority of C programmers don't even care what 
>> the underlying hardware is.
> 
> 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.
> 

Surely that is going to depend entirely on the kind of programming you
do in real life?

The C programmers I talk to mostly have a very clear idea of what their
hardware is, and write code for a specific device and specific tools.
(Not that they make their code intentionally non-portable, merely that
it might depend on specific hardware, or be optimised for particular
cases.)  But that's because of the branch I work in, small-systems
embedded programming.

For many other C programmers, it's a different matter, and they work on
code that should run on lots of types of system, so portability (to at
least some extent) is important.

I'd be loath to hazard a guess as to where the split goes and what "the
vast majority of C programmers" do, but I would never think "the people
I have met in real life" is representative of anything much.

[toc] | [prev] | [next] | [standalone]

#162580

On Thursday, 2 September 2021 at 12:36:08 UTC+1, David Brown wrote:
> On 01/09/2021 23:07, Michael S wrote: 
> > On Wednesday, September 1, 2021 at 11:18:51 PM UTC+3, Scott Lurndal
> >> Actually, the typical C programmer wants his program to run on any 
> >> system that supports the standard regardless of the underlying 
> >> hardware. The vast majority of C programmers don't even care what 
> >> the underlying hardware is. 
> > 
> > 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. 
> >
> Surely that is going to depend entirely on the kind of programming you 
> do in real life? 
> 
> The C programmers I talk to mostly have a very clear idea of what their 
> hardware is, and write code for a specific device and specific tools. 
> (Not that they make their code intentionally non-portable, merely that 
> it might depend on specific hardware, or be optimised for particular 
> cases.) But that's because of the branch I work in, small-systems 
> embedded programming. 
> 
> For many other C programmers, it's a different matter, and they work on 
> code that should run on lots of types of system, so portability (to at 
> least some extent) is important. 
> 
Exactly.
We've just had Apple change their chip on us. Instead of using x86, the
latests Macs now use the Arm M1. I think there were a few minor glitches
in a low level UI library which is someone else's responsibility. But all of
our code simply compiled for the new chip. That's because it's user-level
code, it just sees that hardware through stable interfaces. It doesn't try to
manipulate any devices directly.

[toc] | [prev] | [next] | [standalone]

#162592

Michael S <already5chosen@yahoo.com> writes:
>
> 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.

We don't typically care about it until we get burned by moving code to a
new machine and having it break.

[toc] | [prev] | [next] | [standalone]

#162661

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

[toc] | [prev] | [next] | [standalone]

#162664

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?

[toc] | [prev] | [next] | [standalone]

#162751

On 08/09/2021 03:19, James Kuyper wrote:
> 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?
> 
It was late :)

Reading it again he's correct.

Andy

[toc] | [prev] | [next] | [standalone]

#162680

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

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web