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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#162597

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.

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

#162598

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.
Since a C pointer is a compile-time concept that doesn't survive to run-
time, a platform only knows about C pointers when it's running a C
compiler. I don't know whether all of the systems I'm talking about have a
native C compiler - it might only be possible to cross-compile for such
platforms from elsewhere.
A memory address merely identifies a location in memory. What type of
thing it points at is determined by the code that uses that address. A C
pointer not only identifies a location in memory, it is also typed, a term
you've frequently misused in this discussion to mean something else. A C
pointer's type is derived from an object or function type, and can only be
safely used to access something with a type compatible with the one it's
derived from. As a result, the pointer's type determines what machine code
is generated to implement expressions involving that pointer. Once that
code has been generated, the pointer's type is no longer a meaningful
concept, and plays no role at run-time. A C pointer can only be used to
access something of an incompatible type by converting it into a pointer to
a type that is compatible with the thing it will access (and that doesn't
always have defined behavior); this is true even if all pointers have the
same representation, in which case the conversion is NoP for which no
actual code is generated.
On a platform like the ones we've been discussing, a byte-addressed
pointer consists of a word address and a byte offset from that address.
The platform itself knows nothing about such pointers. When compiling
source code that uses such a pointer, the compiler generates machine code
that reads the word at that address, and extracts different bytes from that
word depending upon the value of the byte offset and the type that the
pointer is derived from (for instance, on a system with 32 bit words and 16-
bit shorts, it would extract two bytes from the word). The platform can
execute those instructions without, in any sense, "knowing" that they
correspond to having a byte-addressed pointer.

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

#162599

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.

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

#162600

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.

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

#162601

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.

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

#162603

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)

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

#162608

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.

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

#162610

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.

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

#162614

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.

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

#162602

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.

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

#162604

"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.

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

#162606

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

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

#162607

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.

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

#162609

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".

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

#162612

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.

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

#162611

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.

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

#162613

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.

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

#162615

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.

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

#162652

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.

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

#162676

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.

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

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

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

csiph-web