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

Started byLynn McGuire <lynnmcguire5@gmail.com>
First post2021-08-30 21:59 -0500
Last post2021-09-01 14:30 -0700
Articles 18 on this page of 78 — 19 participants

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

#162559

FromLynn McGuire <lynnmcguire5@gmail.com>
Date2021-09-01 17:46 -0500
Message-ID<sgovss$tna$1@dont-email.me>
In reply to#162552
On 9/1/2021 3:18 PM, Scott Lurndal wrote:
> 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.

I am reading "Masters Of Doom" right now.  John Carmack wrote Doom on a 
Next Step box in C and ported it to PC, first for 386 DOS then Windows 
92 XX 93 XX 94 XX 95 then Sega then several other platforms.
 
https://www.amazon.com/Masters-Doom-Created-Transformed-Culture/dp/0812972155/

Lynn

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

#162561

From"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date2021-09-01 16:53 -0700
Message-ID<sgp3pv$47h$1@gioia.aioe.org>
In reply to#162559
On 9/1/2021 3:46 PM, Lynn McGuire wrote:
> On 9/1/2021 3:18 PM, Scott Lurndal wrote:
>> 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.
> 
> I am reading "Masters Of Doom" right now.  John Carmack wrote Doom on a 
> Next Step box in C and ported it to PC, first for 386 DOS then Windows 
> 92 XX 93 XX 94 XX 95 then Sega then several other platforms.
> 
> https://www.amazon.com/Masters-Doom-Created-Transformed-Culture/dp/0812972155/ 

Do you happen to be familiar with a port of Wolfenstein on an apple iigs?

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

#162593

FromLynn McGuire <lynnmcguire5@gmail.com>
Date2021-09-02 17:11 -0500
Message-ID<sgri7c$v6m$1@dont-email.me>
In reply to#162561
On 9/1/2021 6:53 PM, Chris M. Thomasson wrote:
> On 9/1/2021 3:46 PM, Lynn McGuire wrote:
>> On 9/1/2021 3:18 PM, Scott Lurndal wrote:
>>> 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.
>>
>> I am reading "Masters Of Doom" right now.  John Carmack wrote Doom on 
>> a Next Step box in C and ported it to PC, first for 386 DOS then 
>> Windows 92 XX 93 XX 94 XX 95 then Sega then several other platforms.
>>
>> https://www.amazon.com/Masters-Doom-Created-Transformed-Culture/dp/0812972155/ 
> 
> 
> Do you happen to be familiar with a port of Wolfenstein on an apple iigs?

Nope.  I played Wolfenstein on the PC.

Lynn

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

#162563

FromTim Rentsch <tr.17687@z991.linuxsc.com>
Date2021-09-01 16:59 -0700
Message-ID<86bl5bx2xc.fsf@linuxsc.com>
In reply to#162552
scott@slp53.sl.home (Scott Lurndal) writes:

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

+1

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

#162564

From"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date2021-09-01 17:01 -0700
Message-ID<sgp499$47h$2@gioia.aioe.org>
In reply to#162563
On 9/1/2021 4:59 PM, Tim Rentsch wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
> 
>> 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.
> 
> +1
> 

Indeed! This is why I loved the fact that C/C++ finally got around to 
standardizing memory barriers and atomics. Love it!

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

#162565

FromBart <bc@freeuk.com>
Date2021-09-02 01:29 +0100
Message-ID<sgp5t4$pvm$1@dont-email.me>
In reply to#162552
On 01/09/2021 21:18, Scott Lurndal wrote:
> 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.

I appreciate that. I'd been writing stuff on x86-only for decades until 
about 2012 when I tried to port one of my interpreters to the RPi1, by 
generating intermediate C code, and it worked almost first time.

I was very impressed.

However when I posted that code here, it was torn to be pieces. 
Apparently it was full of UB, or potential UB, and some of the reasons 
were that C couldn't guarantee defined behaviour on every possible 
target, even though it would have been fine on the hardware it was going 
to work on.

(Another issue was gcc thinking I was doing misaligned accesses, when I 
wasn't, and substituting byte-at-a-time code.)

Now I've find a way around that: don't post C code on these forums and 
it'll generally be fine.

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

#162578

FromDavid Brown <david.brown@hesbynett.no>
Date2021-09-02 13:29 +0200
Message-ID<sgqcis$esi$1@dont-email.me>
In reply to#162545
On 01/09/2021 21:34, Bart wrote:
> 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?
> 

I have no idea how you managed to drag such ideas from what I wrote.

4-bit devices are almost invariably stack machines, so that their
assembly looks like a restricted version Forth.  And they are almost
invariably programmed either directly in that assembly, or a slightly
higher level variant of Forth.  I have not heard of C implementations
for 4-bit devices.

Nor did I talk about what programming languages I might want, or say
anything about what /you/ are allowed to do.

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

#162582

FromBart <bc@freeuk.com>
Date2021-09-02 14:19 +0100
Message-ID<sgqj0n$vmn$1@dont-email.me>
In reply to#162578
On 02/09/2021 12:29, David Brown wrote:
> On 01/09/2021 21:34, Bart wrote:
>> 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?
>>
> 
> I have no idea how you managed to drag such ideas from what I wrote.
> 
> 4-bit devices are almost invariably stack machines, so that their
> assembly looks like a restricted version Forth.  And they are almost
> invariably programmed either directly in that assembly, or a slightly
> higher level variant of Forth.  I have not heard of C implementations
> for 4-bit devices.
> 
> Nor did I talk about what programming languages I might want, or say
> anything about what /you/ are allowed to do.

The discussion was about the likelihood of a void* type being wider than 
int*.

And it invariably brought up all these odd devices where that could 
conceivably be the case.

Which means that now you can't reliably make the assumption that void* 
and int* are the same size.

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

#162594

FromKeith Thompson <Keith.S.Thompson+u@gmail.com>
Date2021-09-02 17:10 -0700
Message-ID<875yvih633.fsf@nosuchdomain.example.com>
In reply to#162582
Bart <bc@freeuk.com> writes:
[...]
> Which means that now you can't reliably make the assumption that void*
> and int* are the same size.

What do you mean "now"?  C has never guaranteed that void* and int* are
the same size.  Before the introduction of void* in C89, there was never
a guarantee that char* and int* are the same size.  In particular, I see
no such guarantee in the 1975 C Reference Manual (though it may well
have been true for all implementations at the time).

I've rarely, if ever, written code that would have benefitted from such
an assumption.

But of course you knew that.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#162584

FromMichael S <already5chosen@yahoo.com>
Date2021-09-02 07:28 -0700
Message-ID<c7656818-0421-4cb3-8759-afb2f2661267n@googlegroups.com>
In reply to#162578
On Thursday, September 2, 2021 at 2:29:45 PM UTC+3, David Brown wrote:
> On 01/09/2021 21:34, Bart wrote: 
> > 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 <lynnmc...@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? 
> >
> I have no idea how you managed to drag such ideas from what I wrote. 
> 
> 4-bit devices are almost invariably stack machines, so that their 
> assembly looks like a restricted version Forth. And they are almost 
> invariably programmed either directly in that assembly, or a slightly 
> higher level variant of Forth. I have not heard of C implementations 
> for 4-bit devices. 
> 
> Nor did I talk about what programming languages I might want, or say 
> anything about what /you/ are allowed to do.


Which 4-bit devices are still in wide use?
Which of them are stack machines?
Without ever programming 4-bitter or even looking at architecture of 4-bitter I would expect that 
most of them are accumulator-based designs rather that stack machines, except that
some could have tiny HW stack dedicated for subroutine calls.

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

#162590

FromDavid Brown <david.brown@hesbynett.no>
Date2021-09-02 21:07 +0200
Message-ID<sgr7dr$2gc$1@dont-email.me>
In reply to#162584
On 02/09/2021 16:28, Michael S wrote:
> On Thursday, September 2, 2021 at 2:29:45 PM UTC+3, David Brown wrote:

>> 4-bit devices are almost invariably stack machines, so that their 
>> assembly looks like a restricted version Forth. And they are almost 
>> invariably programmed either directly in that assembly, or a slightly 
>> higher level variant of Forth. I have not heard of C implementations 
>> for 4-bit devices. 
>>
>> Nor did I talk about what programming languages I might want, or say 
>> anything about what /you/ are allowed to do.
> 
> 
> Which 4-bit devices are still in wide use?

I don't know which are much in use - they are not generally stocked by
public suppliers, nor are their datasheets and information publicly
available.  If you are a big enough user to be interested in these
things, you talk directly to the manufacturers.  They certainly used to
be standard in things like remote controls, wireless keys, tire sensors,
clocks, "amusing" musical birthday cards, toys, and countless other
mass-produced devices.  They might also turn up inside other microchips
which hardware designers use without ever knowing or caring that there
is a processor inside.

The most easily accessible 4-bit device for mere mortals was the Atmel
MARC4 series, but that was removed from public availability in 2015
(IIRC).  But it should not be too hard to google for some old datasheets
if you are interested.  And I am sure Atmel continues to supply them to
big customers.

> Which of them are stack machines?

All of them.  With such short instructions, you don't waste instruction
code space on things like register numbers or addressing modes.

> Without ever programming 4-bitter or even looking at architecture of 4-bitter I would expect that 
> most of them are accumulator-based designs rather that stack machines, except that
> some could have tiny HW stack dedicated for subroutine calls.
> 

That is common for 8-bit devices, with the AVR series as one of the few
exceptions.  (Dedicated HW stack for returns is usually only for the
very smallest devices.  The smallest AVR I used had no ram, only its 32
8-bit registers and a three entry hardware return stack.)

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

#162591

FromMichael S <already5chosen@yahoo.com>
Date2021-09-02 13:05 -0700
Message-ID<fd5633e6-d52f-4147-8a24-261b56eb5375n@googlegroups.com>
In reply to#162590
On Thursday, September 2, 2021 at 10:07:51 PM UTC+3, David Brown wrote:
> On 02/09/2021 16:28, Michael S wrote: 
> > On Thursday, September 2, 2021 at 2:29:45 PM UTC+3, David Brown wrote: 
> 
> >> 4-bit devices are almost invariably stack machines, so that their 
> >> assembly looks like a restricted version Forth. And they are almost 
> >> invariably programmed either directly in that assembly, or a slightly 
> >> higher level variant of Forth. I have not heard of C implementations 
> >> for 4-bit devices. 
> >> 
> >> Nor did I talk about what programming languages I might want, or say 
> >> anything about what /you/ are allowed to do. 
> > 
> > 
> > Which 4-bit devices are still in wide use?
> I don't know which are much in use - they are not generally stocked by 
> public suppliers, nor are their datasheets and information publicly 
> available. If you are a big enough user to be interested in these 
> things, you talk directly to the manufacturers. They certainly used to 
> be standard in things like remote controls, wireless keys, tire sensors, 
> clocks, "amusing" musical birthday cards, toys, and countless other 
> mass-produced devices. They might also turn up inside other microchips 
> which hardware designers use without ever knowing or caring that there 
> is a processor inside. 
> 
> The most easily accessible 4-bit device for mere mortals was the Atmel 
> MARC4 series, but that was removed from public availability in 2015 
> (IIRC). But it should not be too hard to google for some old datasheets 
> if you are interested. And I am sure Atmel continues to supply them to 
> big customers.
> > Which of them are stack machines?
> All of them. With such short instructions, you don't waste instruction 
> code space on things like register numbers or addressing modes.

I see. MARC4 has no resemblance to the first 4-bit micros - Intel 4004 and TI TMS1000.
I can't find programming manual for another ancient 4-bitter - NEC μCOM-4, but would 
be surprised if it wasn't accumulator machine as well.
Wikichips claims that MARC4 is much newer than those - first built around 1985.

> > Without ever programming 4-bitter or even looking at architecture of 4-bitter I would expect that 
> > most of them are accumulator-based designs rather that stack machines, except that 
> > some could have tiny HW stack dedicated for subroutine calls. 
> >
> That is common for 8-bit devices, with the AVR series as one of the few 
> exceptions. (Dedicated HW stack for returns is usually only for the 
> very smallest devices. The smallest AVR I used had no ram, only its 32 
> 8-bit registers and a three entry hardware return stack.)

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

#162595

FromKeith Thompson <Keith.S.Thompson+u@gmail.com>
Date2021-09-02 17:18 -0700
Message-ID<871r66h5p3.fsf@nosuchdomain.example.com>
In reply to#162590
David Brown <david.brown@hesbynett.no> writes:
> On 02/09/2021 16:28, Michael S wrote:
[...]
>> Which 4-bit devices are still in wide use?
>
> I don't know which are much in use - they are not generally stocked by
> public suppliers, nor are their datasheets and information publicly
> available.  If you are a big enough user to be interested in these
> things, you talk directly to the manufacturers.  They certainly used to
> be standard in things like remote controls, wireless keys, tire sensors,
> clocks, "amusing" musical birthday cards, toys, and countless other
> mass-produced devices.  They might also turn up inside other microchips
> which hardware designers use without ever knowing or caring that there
> is a processor inside.
>
> The most easily accessible 4-bit device for mere mortals was the Atmel
> MARC4 series, but that was removed from public availability in 2015
> (IIRC).  But it should not be too hard to google for some old datasheets
> if you are interested.  And I am sure Atmel continues to supply them to
> big customers.
[...]

The HP Saturn was a family of 4-bit microprocessors.  It was used in
some HP calculators, including the HP28 and HP48 series.

https://en.wikipedia.org/wiki/HP_Saturn

Apparently there's a gcc-based cross-compiler (it uses 8-bit char).
http://hp48xgcc.sourceforge.net/hp48xgcc.htm

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#162596

FromBart <bc@freeuk.com>
Date2021-09-03 01:25 +0100
Message-ID<sgrq2b$1n6$1@dont-email.me>
In reply to#162595
On 03/09/2021 01:18, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 02/09/2021 16:28, Michael S wrote:
> [...]
>>> Which 4-bit devices are still in wide use?
>>
>> I don't know which are much in use - they are not generally stocked by
>> public suppliers, nor are their datasheets and information publicly
>> available.  If you are a big enough user to be interested in these
>> things, you talk directly to the manufacturers.  They certainly used to
>> be standard in things like remote controls, wireless keys, tire sensors,
>> clocks, "amusing" musical birthday cards, toys, and countless other
>> mass-produced devices.  They might also turn up inside other microchips
>> which hardware designers use without ever knowing or caring that there
>> is a processor inside.
>>
>> The most easily accessible 4-bit device for mere mortals was the Atmel
>> MARC4 series, but that was removed from public availability in 2015
>> (IIRC).  But it should not be too hard to google for some old datasheets
>> if you are interested.  And I am sure Atmel continues to supply them to
>> big customers.
> [...]
> 
> The HP Saturn was a family of 4-bit microprocessors.  It was used in
> some HP calculators, including the HP28 and HP48 series.
> 
> https://en.wikipedia.org/wiki/HP_Saturn
> 
> Apparently there's a gcc-based cross-compiler (it uses 8-bit char).
> http://hp48xgcc.sourceforge.net/hp48xgcc.htm
> 

According to this:

   https://en.wikipedia.org/wiki/HP_48_series

It uses a 64-bit processor pretending to be a 4-bit one.

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

#162531

FromMark Bluemel <mark.bluemel@gmail.com>
Date2021-09-01 03:30 -0700
Message-ID<d0ceeb9a-14ef-4a7b-ba62-2c2afbe517afn@googlegroups.com>
In reply to#162505
On Tuesday, 31 August 2021 at 04:00:06 UTC+1, 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 ? 

Historically Prime (aka Pr1me) 50-series machines had this.

The underlying architecture was based on 16-bit "half-words", with the memory organized into segments.

As I recall, the standard 32-pointer held a 2-bit protection/privilege ring number, 14-bits of segment number and 16-bits of offset to a half-word in the segment.
Accessing 8-bit bytes was via a 48-bit pointer with the final 16-bits dedicated to holding 0 or 1 as the offset of the byte in the half-word (honestly).

In addition, 8-bit ASCII had the sign bit on rather than off, and native I/O was half-word oriented.

Porting C to it was, I gather, a bit of a pain. Oh - and when you incremented a pointer past the end of a segment, it would wrap back to the beginning of that segment, not move on to the next, if I recall correctly.

For a later C release, an alternative form of 32-bit addressing was added - I can't remember the details, but think the ring number bits were repurposed.

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

#162532

FromMark Bluemel <mark.bluemel@gmail.com>
Date2021-09-01 03:36 -0700
Message-ID<84536b60-77ba-4aaf-a998-378a3b6c873dn@googlegroups.com>
In reply to#162531
On Wednesday, 1 September 2021 at 11:30:12 UTC+1, Mark Bluemel wrote:
> On Tuesday, 31 August 2021 at 04:00:06 UTC+1, 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 ?
> Historically Prime (aka Pr1me) 50-series machines had this. 
> 
> The underlying architecture was based on 16-bit "half-words", with the memory organized into segments. 
> 
> As I recall, the standard 32-pointer held a 2-bit protection/privilege ring number, 14-bits of segment number and 16-bits of offset to a half-word in the segment. 
> Accessing 8-bit bytes was via a 48-bit pointer with the final 16-bits dedicated to holding 0 or 1 as the offset of the byte in the half-word (honestly). 
> 
> In addition, 8-bit ASCII had the sign bit on rather than off, and native I/O was half-word oriented. 
> 
> Porting C to it was, I gather, a bit of a pain. Oh - and when you incremented a pointer past the end of a segment, it would wrap back to the beginning of that segment, not move on to the next, if I recall correctly. 
> 
> For a later C release, an alternative form of 32-bit addressing was added - I can't remember the details, but think the ring number bits were repurposed.

See also <http://www.c-faq.com/null/machexamp.html>

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

#162540

FromLynn McGuire <lynnmcguire5@gmail.com>
Date2021-09-01 12:49 -0500
Message-ID<sgoefh$543$1@dont-email.me>
In reply to#162531
On 9/1/2021 5:30 AM, Mark Bluemel wrote:
> On Tuesday, 31 August 2021 at 04:00:06 UTC+1, 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 ?
> 
> Historically Prime (aka Pr1me) 50-series machines had this.
> 
> The underlying architecture was based on 16-bit "half-words", with the memory organized into segments.
> 
> As I recall, the standard 32-pointer held a 2-bit protection/privilege ring number, 14-bits of segment number and 16-bits of offset to a half-word in the segment.
> Accessing 8-bit bytes was via a 48-bit pointer with the final 16-bits dedicated to holding 0 or 1 as the offset of the byte in the half-word (honestly).
> 
> In addition, 8-bit ASCII had the sign bit on rather than off, and native I/O was half-word oriented.
> 
> Porting C to it was, I gather, a bit of a pain. Oh - and when you incremented a pointer past the end of a segment, it would wrap back to the beginning of that segment, not move on to the next, if I recall correctly.
> 
> For a later C release, an alternative form of 32-bit addressing was added - I can't remember the details, but think the ring number bits were repurposed.

Good night, what a mess !

We had a Prime model 450 in 1977 and a model 750 in 1980 ???.   And then 
a model 2xxx ??? in 1985 ???  The only compilers they had that I knew of 
were the Fortran, Cobol, and PL/I ???

Lynn

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

#162556

FromMark Bluemel <mark.bluemel@gmail.com>
Date2021-09-01 14:30 -0700
Message-ID<546d6d53-4ee4-491c-8376-dd2e505c3ae1n@googlegroups.com>
In reply to#162540
On Wednesday, 1 September 2021 at 18:49:49 UTC+1, Lynn McGuire wrote:
> On 9/1/2021 5:30 AM, Mark Bluemel wrote: 
> > On Tuesday, 31 August 2021 at 04:00:06 UTC+1, 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 ? 
> > 
> > Historically Prime (aka Pr1me) 50-series machines had this. 
> > 
> > The underlying architecture was based on 16-bit "half-words", with the memory organized into segments. 
> > 
> > As I recall, the standard 32-pointer held a 2-bit protection/privilege ring number, 14-bits of segment number and 16-bits of offset to a half-word in the segment. 
> > Accessing 8-bit bytes was via a 48-bit pointer with the final 16-bits dedicated to holding 0 or 1 as the offset of the byte in the half-word (honestly). 
> > 
> > In addition, 8-bit ASCII had the sign bit on rather than off, and native I/O was half-word oriented. 
> > 
> > Porting C to it was, I gather, a bit of a pain. Oh - and when you incremented a pointer past the end of a segment, it would wrap back to the beginning of that segment, not move on to the next, if I recall correctly. 
> > 
> > For a later C release, an alternative form of 32-bit addressing was added - I can't remember the details, but think the ring number bits were repurposed.
> Good night, what a mess ! 
> 
> We had a Prime model 450 in 1977 and a model 750 in 1980 ???. And then 
> a model 2xxx ??? in 1985 ??? The only compilers they had that I knew of 
> were the Fortran, Cobol, and PL/I ??? 
> 
> Lynn

I worked for Prime in the late 80s. The hardware design was derived, iirc, from Data General machines of the early 70s. The original systems programming language was FORTRAN(!), subsequently supplemented with PL/1 derivatives (PL/P & SPL) and later Modula-2.

I believe the two generations of C compilers were produced by a third-party contractor.

I mainly worked with the Prime Information system, a Pick-derived data management system with its own programming language (Info/Basic).

[toc] | [prev] | [standalone]

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

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

csiph-web