From Newsgroup: comp.sys.raspberry-pi

I have been looking forward to the Raspberry Pi Pico 2 for a while. The increased speed will be welcome for one project I want to use it for.

However, according to what I've read there seem to be some missed opportunities. Corrections would be welcome but AIUI:

* There are still no analogue /outputs/ - which I would have thought
would have been cheap and easy to provide.

* Although there are now 3 PIO units each one still has only 32 words of program memory (which was very limiting in the Pico). I assume that
because the RP2350 is supposed to be software compatible meaning, among
other things, that it should run RP2040 PIO code.

Unfortunately, IIRC the RP2040 had absolute jumps rather than relative
ones meaning jump targets had to be in the range 0 to 31. If the new
chip has to be binary compatible then jump targets will still have to be 5-bit.

Of course, it could be possible to run into more PIO memory than 32
words as long as the requisite jumps were back to the initial 32-word
space but that would be awkward to use, and limiting.

Any corrections to the above?

Any other omissions, IYO?
--
James Harris

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

James Harris <james.harris.1@gmail.com> wrote:

I have been looking forward to the Raspberry Pi Pico 2 for a while. The increased speed will be welcome for one project I want to use it for.

However, according to what I've read there seem to be some missed opportunities. Corrections would be welcome but AIUI:

* There are still no analogue /outputs/ - which I would have thought
would have been cheap and easy to provide.

I suspect the analogue drive circuit is not that simple - would take
area and may compromise power, especially idle power.

You can get some of the way by using PWM and an external R-C network to low pass filter the PWM. Depends what kind of frequency you need. Or there are I2C DACs if you need a more accurate output.

* Although there are now 3 PIO units each one still has only 32 words of program memory (which was very limiting in the Pico). I assume that
because the RP2350 is supposed to be software compatible meaning, among other things, that it should run RP2040 PIO code.

That does look to be the case. Looks like the original RP2040 design
optimised them into a corner that's difficult to get out of.

Theo
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Thu, 15 Aug 2024 17:47:51 +0100, James Harris wrote:

Of course, it could be possible to run into more PIO memory than 32
words as long as the requisite jumps were back to the initial 32-word
space but that would be awkward to use, and limiting.

Or, you could bring back the old PDP-8 trick, of having the jump address
be in the *current page*. That means the upper bits are taken from the
current program counter.

There was actually a separate mode bit that indicated whether the address
was in the current page or page 0. And another bit to indicate whether the access was indirect (i.e. don’t take the contents of that address, take
the contents of the contents).
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 15/08/2024 18:05, Theo wrote:

James Harris <james.harris.1@gmail.com> wrote:

I have been looking forward to the Raspberry Pi Pico 2 for a while. The
increased speed will be welcome for one project I want to use it for.

However, according to what I've read there seem to be some missed
opportunities. Corrections would be welcome but AIUI:

* There are still no analogue /outputs/ - which I would have thought
would have been cheap and easy to provide.

I suspect the analogue drive circuit is not that simple - would take
area and may compromise power, especially idle power.

I would have thought that such a circuit could be gated to reduce/remove
power consumption. DAC needs far less circuitry (and no iteration) than ADC.

You can get some of the way by using PWM and an external R-C network to low pass filter the PWM. Depends what kind of frequency you need. Or there are I2C DACs if you need a more accurate output.

I was hoping for analogue output pins initially in order to drive a VGA display. Would PWM work for that, do you think? My guess is that it
would be too slow or jittery.

I have seen Pico set up to drive VGA through five resistors per colour.
It may be a Pico reference design but there's a great version of it at

https://vanhunteradams.com/Pico/VGA/VGA.html

The problem is that for three colour guns it takes fifteen pins!

Of course, external DACs increase the chip count and add latency and
cost but I take your point.

* Although there are now 3 PIO units each one still has only 32 words of
program memory (which was very limiting in the Pico). I assume that
because the RP2350 is supposed to be software compatible meaning, among
other things, that it should run RP2040 PIO code.

That does look to be the case. Looks like the original RP2040 design optimised them into a corner that's difficult to get out of.

Agreed. The curse of upwards compatibility. Though they could still have supported two different modes.
--
James Harris


--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 2024-08-18, James Harris <james.harris.1@gmail.com> wrote:

* There are still no analogue /outputs/ - which I would have thought
would have been cheap and easy to provide.

I suspect the analogue drive circuit is not that simple - would take
area and may compromise power, especially idle power.

I would have thought that such a circuit could be gated to reduce/remove power consumption. DAC needs far less circuitry (and no iteration) than ADC.

I suspect it takes (quite) some design effort to get it right (see the ADC
on the RP2040), and requires analogue circuitry which is more difficult to implement in a given process than digital.

Also, on-chip DACs are not too common in competitor parts - there are some
that have it, but it is not standard.

I was hoping for analogue output pins initially in order to drive a VGA display.

That requires a *really fast* DAC. IIRC, standard VGA was ~25MHz pixel
clock.

For comparison, the STM32F407 DAC has a settling time of 3us (typical),
meaning you can't do anything above ~300kHz.

Getting a DAC to VGA speed (even at reduced resolution) requires quite some more design effort (and probably also chip area), and aside from analog VGA, there are probably few use cases.

Would PWM work for that, do you think? My guess is that it
would be too slow or jittery.

I agree.

I have seen Pico set up to drive VGA through five resistors per colour.
It may be a Pico reference design but there's a great version of it at

https://vanhunteradams.com/Pico/VGA/VGA.html

The problem is that for three colour guns it takes fifteen pins!

Well, the new RP2350B has 48 instead of 30 GPIO pins available, so that
should be anough for 6 bits / colour ;-)

cu
Michael
--
Some people have no respect of age unless it is bottled.
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 17/08/2024 08:22, Lawrence D'Oliveiro wrote:

Or, you could bring back the old PDP-8 trick, of having the jump address
be in the *current page*. That means the upper bits are taken from the current program counter.

That must be damn annoying to program in assembler.
Probably slows compilers down a fair but too.
--
Brian Gregory (in England).
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 21/08/2024 23:43, Brian Gregory wrote:

On 17/08/2024 08:22, Lawrence D'Oliveiro wrote:

Or, you could bring back the old PDP-8 trick, of having the jump address
be in the *current page*. That means the upper bits are taken from the
current program counter.

That must be damn annoying to program in assembler.
Probably slows compilers down a fair but too.

IIRC 8086 was the same for conditional jumps.

In fact the whole small model thing was coding for a 64k page.

There were a few instructions that worked across pages...but my memory
is dim.
--
"When a true genius appears in the world, you may know him by this sign,
that the dunces are all in confederacy against him."

Jonathan Swift.

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Thu, 2024-08-22 at 09:17 +0100, The Natural Philosopher wrote:

IIRC 8086 was the same for conditional jumps.

In fact the whole small model thing was coding for a 64k page.

There were a few instructions that worked across pages...but my
memory is dim.

FAR and NEAR specifiers used with JMP were often used for intra segment
calls. Data could also be accessed with the same specifiers too, hence
there were five different memmory models, tiny, small, medium, large
and huge with different code and data accesses.
--
Tactical Nuclear Kittens
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 22/08/2024 11:00, Single Stage to Orbit wrote:

On Thu, 2024-08-22 at 09:17 +0100, The Natural Philosopher wrote:

IIRC 8086 was the same for conditional jumps.

In fact the whole small model thing was coding for a 64k page.

There were a few instructions that worked across pages...but my
memory is dim.

FAR and NEAR specifiers used with JMP were often used for intra segment calls. Data could also be accessed with the same specifiers too, hence
there were five different memmory models, tiny, small, medium, large
and huge with different code and data accesses.

Yes, that all sounds vaguely familiar. All that forgotten knowledge that
I will take to the
grave with me, where, arguably, it belongs...

It was a horrible processor to do assembler on, but I made a living out
of it for several years.

Thank Clapton for 'C' and Unix/Linux/Gnu and the 386 series at which
point one no longer had to...
--
No Apple devices were knowingly used in the preparation of this post.

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Thu, 22 Aug 2024 11:00:26 +0100
Single Stage to Orbit <alex.buell@munted.eu> wrote:

FAR and NEAR specifiers used with JMP

The obscenity was these qualifiers making their way into C source
code - try writing (or even reading) the declaration for a near pointer to a function returning a far pointer to an array of functions returning near pointers to integers.

Then realise that you *alos* wanted this source code to be portable.
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
For forms of government let fools contest
Whate're is best administered is best - Alexander Pope
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Thu, 2024-08-22 at 11:57 +0100, Ahem A Rivet's Shot wrote:

FAR and NEAR specifiers used with JMP

The obscenity was these qualifiers making their way into C
source
code - try writing (or even reading) the declaration for a near
pointer to a function returning a far pointer to an array of
functions returning near pointers to integers.

Then realise that you *alos* wanted this source code to be
portable.

Which was why one used macros to conditionally compile code on MSDOG
and other platforms. And there were macros for far pointers, MK_FP()
for example. I think I have the remains of a hex disk editor somewhere
in my archives written in C with some assembler using Zortech C.
Fun times(!)
--
Tactical Nuclear Kittens
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Thu, 2024-08-22 at 12:09 +0100, Single Stage to Orbit wrote:

Which was why one used macros to conditionally compile code on MSDOG
and other platforms. And there were macros for far pointers, MK_FP()
for example. I think I have the remains of a hex disk editor
somewhere in my archives written in C with some assembler using
Zortech C.

So I've had a rummage around, and the original diskedit sources isn't
with us anymore, but it looks like I ported it to windows 95 and threw
out all the MSDOGisms.
I do wish I still had the original sources though, but it's lost in the
mists of time.
--
Tactical Nuclear Kittens
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 22/08/2024 12:25, Single Stage to Orbit wrote:

On Thu, 2024-08-22 at 12:09 +0100, Single Stage to Orbit wrote:

Which was why one used macros to conditionally compile code on MSDOG
and other platforms. And there were macros for far pointers, MK_FP()
for example. I think I have the remains of a hex disk editor
somewhere in my archives written in C with some assembler using
Zortech C.

So I've had a rummage around, and the original diskedit sources isn't
with us anymore, but it looks like I ported it to windows 95 and threw
out all the MSDOGisms.

I do wish I still had the original sources though, but it's lost in the
mists of time.

What happened to backups?

;)
--
Chris

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Thu, 2024-08-22 at 13:40 +0100, Chris Townley wrote:

So I've had a rummage around, and the original diskedit sources
isn't with us anymore, but it looks like I ported it to windows 95
and threw out all the MSDOGisms.

I do wish I still had the original sources though, but it's lost in
the mists of time.

What happened to backups?

I think they must have been on these Travan tape backups that I threw
out decades ago. :(
--
Tactical Nuclear Kittens
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 2024-08-22, Ahem A Rivet's Shot <steveo@eircom.net> wrote:

On Thu, 22 Aug 2024 11:00:26 +0100
Single Stage to Orbit <alex.buell@munted.eu> wrote:

FAR and NEAR specifiers used with JMP

The obscenity was these qualifiers making their way into C source
code - try writing (or even reading) the declaration for a near pointer to
a function returning a far pointer to an array of functions returning near pointers to integers.

Then realise that you *alos* wanted this source code to be portable.

A bloody pain in the ass, all of it. Forget the 640K barrier -
I was much more concerned with the 64K barrier. I wound up
writing pointer normalization routines and all sorts of other
hacks to handle large tables - and still keep it compatible
with *n*x. I only recently stripped out all that crap.
Good riddance.
--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Thu, 2024-08-22 at 19:18 +0000, Charlie Gibbs wrote:

FAR and NEAR specifiers used with JMP

  The obscenity was these qualifiers making their way into C
source
code - try writing (or even reading) the declaration for a near
pointer to a function returning a far pointer to an array of
functions returning near pointers to integers.

  Then realise that you *alos* wanted this source code to be
portable.

A bloody pain in the ass, all of it.  Forget the 640K barrier -
I was much more concerned with the 64K barrier.  I wound up
writing pointer normalization routines and all sorts of other
hacks to handle large tables - and still keep it compatible
with *n*x.  I only recently stripped out all that crap.
Good riddance.

Huge pointers for code + data for up to 1MB, oh the Ghods, much slower
than using using tiny pointers limited to 64KB segments. But yes,
playing games with segment registers and splitting data into 64KB
segments was significantly quicker and generated smaller binaries.
--
Tactical Nuclear Kittens
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 22/08/2024 11:57, Ahem A Rivet's Shot wrote:

On Thu, 22 Aug 2024 11:00:26 +0100
Single Stage to Orbit <alex.buell@munted.eu> wrote:

FAR and NEAR specifiers used with JMP

The obscenity was these qualifiers making their way into C source
code - try writing (or even reading) the declaration for a near pointer to a function returning a far pointer to an array of functions returning near pointers to integers.

Then realise that you *also* wanted this source code to be portable.

I don't recall them ever appearing in C source. They are not part of the
C language.
AIR you could compile for 'small model' or 'large model'

And with the early compilers I used, no attempt was made to think about whether a jump was near or far.

I think you got an assembler or linker error if a target was 'out of range'
--
I would rather have questions that cannot be answered...
...than to have answers that cannot be questioned

Richard Feynman



--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 23/08/2024 10:17, The Natural Philosopher wrote:

On 22/08/2024 11:57, Ahem A Rivet's Shot wrote:

On Thu, 22 Aug 2024 11:00:26 +0100
Single Stage to Orbit <alex.buell@munted.eu> wrote:

FAR and NEAR specifiers used with JMP

    The obscenity was these qualifiers making their way into C source
code - try writing (or even reading) the declaration for a near
pointer to a
function returning a far pointer to an array of functions returning near
pointers to integers.

    Then realise that you *also* wanted this source code to be portable. >>

I don't recall them ever appearing in C source. They are not part of the
C language.
AIR you could compile for 'small model' or 'large model'

And with the early compilers I used, no attempt was made to think about whether a jump was near or far.

I think you got an assembler or  linker error if a target was 'out of range'

No I remember the joy of using NEAR and FAR in C for 8086 code. I can
remember being forced to use them in zORLAND C/Zortech C++ and Borland C
on 8086 code for PCs running DOS and in embedded 80186EB code.

https://www.geeksforgeeks.org/what-are-near-far-and-huge-pointers/ https://en.wikipedia.org/wiki/Digital_Mars

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Fri, 23 Aug 2024 10:17:56 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

On 22/08/2024 11:57, Ahem A Rivet's Shot wrote:

On Thu, 22 Aug 2024 11:00:26 +0100

I don't recall them ever appearing in C source. They are not part of the
C language.

No they are not - but they did appear as extensions in every
8086/80286 compiler I ever used.

AIR you could compile for 'small model' or 'large model'

There were several models available (tiny had one segment shared for code and data, small had separate code and data then there were mixed small code large data and vice versa). These set the memory mapping and the
default sizes of pointers but the near and far keywords could override
those defaults in some models.

It was *horrible*, the 80386 was a breath of fresh air.
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
For forms of government let fools contest
Whate're is best administered is best - Alexander Pope
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 23/08/2024 11:12, Ahem A Rivet's Shot wrote:

On Fri, 23 Aug 2024 10:17:56 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

On 22/08/2024 11:57, Ahem A Rivet's Shot wrote:

On Thu, 22 Aug 2024 11:00:26 +0100

I don't recall them ever appearing in C source. They are not part of the
C language.

No they are not - but they did appear as extensions in every
8086/80286 compiler I ever used.

Dint appea as extensions in ANY of the ones I used. You compiled for
small model or for large model.
Small model couldnt exceed 64k program space

AIR you could compile for 'small model' or 'large model'

There were several models available (tiny had one segment shared for code and data, small had separate code and data then there were mixed small code large data and vice versa). These set the memory mapping and the
default sizes of pointers but the near and far keywords could override
those defaults in some models.

Not in any compiler I used.

It was *horrible*, the 80386 was a breath of fresh air.

I'll grant you that.
--
"Strange as it seems, no amount of learning can cure stupidity, and
higher education positively fortifies it."

- Stephen Vizinczey


--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 23/08/2024 13:38, The Natural Philosopher wrote:

Not in any compiler I used.

It was in 16bit MS C Compiler, Watcom C, Borland C, Zorland/Zortech
C/C++. In fact the availability of memory models exceeding small and
large was a desirability of 8086 compilers. Such large code small data,
small code, large data and huge (large code and large data). In fact the legacy of NEAR and FAR keywords lived on for a long time.

Certainly MS Visual Studio 2019 includes header files for code designed
for Windows (windef.h) with the following legacy definitions still:

#ifndef pascal
#define pascal __ONLY_IN_WINELIB(__stdcall)
#endif
#ifndef _pascal
#define _pascal __ONLY_IN_WINELIB(__stdcall)
#endif
#ifndef __export
#define __export __ONLY_IN_WINELIB(__stdcall)
#endif
#ifndef near
#define near __ONLY_IN_WINELIB(/* nothing */)
#endif
#ifndef far
#define far __ONLY_IN_WINELIB(/* nothing */)
#endif
#ifndef _near
#define _near __ONLY_IN_WINELIB(/* nothing */)
#endif
#ifndef _far
#define _far __ONLY_IN_WINELIB(/* nothing */)
#endif
#ifndef NEAR
#define NEAR __ONLY_IN_WINELIB(/* nothing */)
#endif
#ifndef FAR
#define FAR __ONLY_IN_WINELIB(/* nothing */)
#endif

Segment registers still exist on x86-64 CPUS.

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Fri, 23 Aug 2024 14:15:33 +0100
mm0fmf <none@invalid.com> wrote:

On 23/08/2024 13:38, The Natural Philosopher wrote:

Not in any compiler I used.

It was in 16bit MS C Compiler, Watcom C, Borland C, Zorland/Zortech
C/C++.

Also Lattice C and the compiler in XENIX-286.
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
For forms of government let fools contest
Whate're is best administered is best - Alexander Pope
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 2024-08-23, Ahem A Rivet's Shot <steveo@eircom.net> wrote:

On Fri, 23 Aug 2024 10:17:56 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

I don't recall them ever appearing in C source. They are not part of the
C language.

No they are not - but they did appear as extensions in every
8086/80286 compiler I ever used.

AIR you could compile for 'small model' or 'large model'

There were several models available (tiny had one segment shared for code and data, small had separate code and data then there were mixed small code large data and vice versa). These set the memory mapping and the
default sizes of pointers but the near and far keywords could override
those defaults in some models.

It was *horrible*, the 80386 was a breath of fresh air.

Not if you were stuck programming for MS-DOS or Windows, unfortunately.
--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Fri, 23 Aug 2024 17:49:42 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

Not if you were stuck programming for MS-DOS or Windows, unfortunately.

I briefly programmed for MS-DOS at the same time as XENIX but I
have managed to avoid ever writing anything for Windows - I've almost
managed to avoid ever having to even use Windows but Dell scupppered that record by buying a PPOE, putting the B in org and making us all use Dells running Windows - so I left.
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
For forms of government let fools contest
Whate're is best administered is best - Alexander Pope
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Fri, 23 Aug 2024 11:12:41 +0100, Ahem A Rivet's Shot wrote:

It was *horrible*, the 80386 was a breath of fresh air.

Sure it was. Except it was only giving the Intel market what the users of other CPUs (Motorola, NatSemi) had been enjoying for years.
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Sat, 24 Aug 2024 07:31:32 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Fri, 23 Aug 2024 11:12:41 +0100, Ahem A Rivet's Shot wrote:

It was *horrible*, the 80386 was a breath of fresh air.

Sure it was. Except it was only giving the Intel market what the users of other CPUs (Motorola, NatSemi) had been enjoying for years.

Sure there's always plenty of fresh air in the fields but this was
in the sewer.
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
For forms of government let fools contest
Whate're is best administered is best - Alexander Pope
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 23/08/2024 19:14, Ahem A Rivet's Shot wrote:

On Fri, 23 Aug 2024 17:49:42 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

Not if you were stuck programming for MS-DOS or Windows, unfortunately.

I briefly programmed for MS-DOS at the same time as XENIX but I
have managed to avoid ever writing anything for Windows - I've almost
managed to avoid ever having to even use Windows but Dell scupppered that record by buying a PPOE, putting the B in org and making us all use Dells running Windows - so I left.

You are lucky. Sadly my employers have customers (mainly in Asia) that
insist we provide the same software for both Linux and Windows. Quite
often we have issues making stuff as reliable on Windows as on Linux and
then we find that the customers ran up the Windows version once to check
it worked and then use the Linux versions. But they *must* have a
Windows version. And now we have the clusterfuck that is Win11 and lots
and lots of stuff that no longer works and driver signing issues and....
Still it keeps me fed and off the streets.

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Sat, 24 Aug 2024 10:48:26 +0100, mm0fmf wrote:

Sadly my employers have customers (mainly in Asia) that
insist we provide the same software for both Linux and Windows. Quite
often we have issues making stuff as reliable on Windows as on Linux and
then we find that the customers ran up the Windows version once to check
it worked and then use the Linux versions. But they *must* have a
Windows version.

I don’t see why that should be “sad”. I would describe it as a “revenue
opportunity” ...
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Sat, 24 Aug 2024 09:13:56 +0100, Ahem A Rivet's Shot wrote:

On Sat, 24 Aug 2024 07:31:32 -0000 (UTC) Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

On Fri, 23 Aug 2024 11:12:41 +0100, Ahem A Rivet's Shot wrote:

It was *horrible*, the 80386 was a breath of fresh air.

Sure it was. Except it was only giving the Intel market what the users
of other CPUs (Motorola, NatSemi) had been enjoying for years.

Sure there's always plenty of fresh air in the fields but this was
in the sewer.

And then it took the Windows/DOS world about another decade to transition
to properly 32-bit APIs.

And there it seems to have got stuck: even on today’s 64-bit machines, Windows programs still use “Win32”.
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 26/08/2024 03:43, Lawrence D'Oliveiro wrote:

Windows programs still use “Win32”.

Win32 is the name of the API.

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Mon, 26 Aug 2024 15:06:52 +0100, mm0fmf wrote:

On 26/08/2024 03:43, Lawrence D'Oliveiro wrote:

Windows programs still use “Win32”.

Win32 is the name of the API.

Why is it not “Win64”?
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 27/08/2024 05:31, Lawrence D'Oliveiro wrote:

On Mon, 26 Aug 2024 15:06:52 +0100, mm0fmf wrote:

On 26/08/2024 03:43, Lawrence D'Oliveiro wrote:

Windows programs still use “Win32”.

Win32 is the name of the API.

Why is it not “Win64”?

The 64bit version is the same API compiled for 64bit instead of 32bit.

IIRC Win32 API first appeared 30 years ago and the name stuck as it differentiated it from other APIs. Now there are no new 32bit Windows
versions on sale the name quietly changed in MS docs to Windows API.

If you say Win32 to people who develop for Windows then they know what
you mean.
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Tue, 27 Aug 2024 08:36:18 +0100, mm0fmf wrote:

On 27/08/2024 05:31, Lawrence D'Oliveiro wrote:

On Mon, 26 Aug 2024 15:06:52 +0100, mm0fmf wrote:

On 26/08/2024 03:43, Lawrence D'Oliveiro wrote:

Windows programs still use “Win32”.

Win32 is the name of the API.

Why is it not “Win64”?

The 64bit version is the same API compiled for 64bit instead of 32bit.

That’s the trouble. It hasn’t really adapted to the availability as standard of 64-bit integers, for example.

Compare the POSIX APIs, where they were careful to use generic types like “size_t” and “time_t”, so that the same code could be compiled, unchanged,
to work on both 32-bit and 64-bit architectures. Not something Windows
code can manage.
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 28/08/2024 00:30, Lawrence D'Oliveiro wrote:

On Tue, 27 Aug 2024 08:36:18 +0100, mm0fmf wrote:

On 27/08/2024 05:31, Lawrence D'Oliveiro wrote:

On Mon, 26 Aug 2024 15:06:52 +0100, mm0fmf wrote:

Win32 is the name of the API.

Why is it not “Win64”?

The 64bit version is the same API compiled for 64bit instead of 32bit.

That’s the trouble. It hasn’t really adapted to the availability as standard of 64-bit integers, for example.

Compare the POSIX APIs, where they were careful to use generic types like “size_t” and “time_t”, so that the same code could be compiled, unchanged,
to work on both 32-bit and 64-bit architectures. Not something Windows
code can manage.

You can do this on Windows too, but they had to bastardise their C
compiler for people that hadn't. It's the only one that on a 64 bit
platform that has long as 32 bits.

Windows:-

int=32 bits, long=32 bits, long long=64 bits

Everyone else in the bloody world:-

int=32 bits, long=64 bits, long long=64 bits

---druck

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 28/08/2024 21:29, druck wrote:

On 28/08/2024 00:30, Lawrence D'Oliveiro wrote:

On Tue, 27 Aug 2024 08:36:18 +0100, mm0fmf wrote:

On 27/08/2024 05:31, Lawrence D'Oliveiro wrote:

On Mon, 26 Aug 2024 15:06:52 +0100, mm0fmf wrote:

Win32 is the name of the API.

Why is it not “Win64”?

The 64bit version is the same API compiled for 64bit instead of 32bit.

That’s the trouble. It hasn’t really adapted to the availability as
standard of 64-bit integers, for example.

Compare the POSIX APIs, where they were careful to use generic types like
“size_t” and “time_t”, so that the same code could be compiled,
unchanged,
to work on both 32-bit and 64-bit architectures. Not something Windows
code can manage.

You can do this on Windows too, but they had to bastardise their C
compiler for people that hadn't. It's the only one that on a 64 bit
platform that has long as 32 bits.

Windows:-

int=32 bits, long=32 bits, long long=64 bits

Everyone else in the bloody world:-

int=32 bits, long=64 bits, long long=64 bits

---druck

The original PDP on which C was written had int 16 bits and long 32 bits
K & R specifically said that no size should be inferred for int. It was
the length of a native word on the machines
--
"The great thing about Glasgow is that if there's a nuclear attack it'll
look exactly the same afterwards."

Billy Connolly

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

druck <news@druck.org.uk> writes:

You can do this on Windows too, but they had to bastardise their C
compiler for people that hadn't. It's the only one that on a 64 bit
platform that has long as 32 bits.

Windows:-

int=32 bits, long=32 bits, long long=64 bits

Everyone else in the bloody world:-

(Almost everyone; Cray had 64-bit int.)

int=32 bits, long=64 bits, long long=64 bits

THe Windows approach is well within what the C language spec allows, and simplified the adaptation of existing Windows application code to 64-bit platforms. The equivalent exercise in Linux needed attention to anything
that made (sometimes invisible) assumptions about the definition of
long.

I don’t think I’d fault either decision though the fact that we’ve ended up with two conventions does make writing/maintaining portable code a
bit more annoying, though not really any more so than the slightly
different set of things compilers warn about or the lack of GCC
compatibility from MSVC. I think MS should bow the inevitable and
replace cl with Clang.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Thu, 29 Aug 2024 09:32:49 +0100
Richard Kettlewell <invalid@invalid.invalid> wrote:

I don’t think I’d fault either decision though the fact that we’ve ended
up with two conventions does make writing/maintaining portable code a
bit more annoying,

Portable code should only rely on the standards not
implementations, some very weird possibilities are legal within the
standard.

There are always the int<n>_t types for when size matters.
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
For forms of government let fools contest
Whate're is best administered is best - Alexander Pope
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 29/08/2024 10:28, Ahem A Rivet's Shot wrote:

On Thu, 29 Aug 2024 09:32:49 +0100
Richard Kettlewell <invalid@invalid.invalid> wrote:

I don’t think I’d fault either decision though the fact that we’ve ended
up with two conventions does make writing/maintaining portable code a
bit more annoying,

Portable code should only rely on the standards not
implementations, some very weird possibilities are legal within the
standard.

There are always the int<n>_t types for when size matters.

Yes, from what I remember of the 90s, Microsoft code used typedefs,
Int32, Int64 or maybe even Macros for types. Big projects sometimes used
their own typedefs. I never liked it. I used int and long, but I
recognised my code was suboptimal.

Then I moved to Csharp and Java and stop worrying :-).

C was shit, for not making types explicit, subsequent OS software
developers were just polishing the turd.



--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 29/08/2024 09:32, Richard Kettlewell wrote:

druck <news@druck.org.uk> writes:

You can do this on Windows too, but they had to bastardise their C
compiler for people that hadn't. It's the only one that on a 64 bit
platform that has long as 32 bits.

Windows:-

int=32 bits, long=32 bits, long long=64 bits

Everyone else in the bloody world:-

(Almost everyone; Cray had 64-bit int.)

int=32 bits, long=64 bits, long long=64 bits

THe Windows approach is well within what the C language spec allows, and simplified the adaptation of existing Windows application code to 64-bit platforms. The equivalent exercise in Linux needed attention to anything
that made (sometimes invisible) assumptions about the definition of
long.

I don’t think I’d fault either decision though the fact that we’ve ended
up with two conventions does make writing/maintaining portable code a
bit more annoying, though not really any more so than the slightly
different set of things compilers warn about or the lack of GCC
compatibility from MSVC. I think MS should bow the inevitable and
replace cl with Clang.

Most code that cares seems to use things like int_32 or long_64 where it matters and macro expand that on a per target hardware basis
--
Climate Change: Socialism wearing a lab coat.

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

Ahem A Rivet's Shot <steveo@eircom.net> writes:

Richard Kettlewell <invalid@invalid.invalid> wrote:

I don’t think I’d fault either decision though the fact that we’ve
ended up with two conventions does make writing/maintaining portable
code a bit more annoying, though not really any more so than the slightly
different set of things compilers warn about or the lack of GCC
compatibility from MSVC. I think MS should bow the inevitable and
replace cl with Clang.

Portable code should only rely on the standards not implementations,
some very weird possibilities are legal within the standard.

There are always the int<n>_t types for when size matters.

Life is not always that simple and declaring how things ‘should’ be does not fix a single line of code.

One of the public APIs we support largely uses ‘long’ and ‘unsigned long’ for integral values, which causes occasional issues with our cross-platform code. For example ‘unsigned long’ has the same size as ‘size_t’ on Linux, but not on 64-bit Windows.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Thu, 29 Aug 2024 13:43:11 +0100
Richard Kettlewell <invalid@invalid.invalid> wrote:

Ahem A Rivet's Shot <steveo@eircom.net> writes:

There are always the int<n>_t types for when size matters.

Life is not always that simple and declaring how things ‘should’ be does not fix a single line of code.

Very true - horse, water, drink.

One of the public APIs we support largely uses ‘long’ and ‘unsigned long’ for integral values, which causes occasional issues with our cross-platform code. For example ‘unsigned long’ has the same size as ‘size_t’ on Linux, but not on 64-bit Windows.

Which is why putting assigning the value of a size_t to an unsigned long or vice-versa is wrong. But hey early C programmers used to store
pointers in ints (there's a moan about it in first edition K&R *that*
early).
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
For forms of government let fools contest
Whate're is best administered is best - Alexander Pope
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

Ahem A Rivet's Shot <steveo@eircom.net> writes:

Richard Kettlewell <invalid@invalid.invalid> wrote:

Ahem A Rivet's Shot <steveo@eircom.net> writes:

There are always the int<n>_t types for when size matters.

Life is not always that simple and declaring how things ‘should’ be
does not fix a single line of code.

Very true - horse, water, drink.

One of the public APIs we support largely uses ‘long’ and ‘unsigned
long’ for integral values, which causes occasional issues with our
cross-platform code. For example ‘unsigned long’ has the same size as
‘size_t’ on Linux, but not on 64-bit Windows.

Which is why putting assigning the value of a size_t to an unsigned
long or vice-versa is wrong.

No, it’s not necessarily wrong. If the value fits in the destination
type there’s nothing wrong with it. The results are well-defined and do
not change the value. You can look up the rules in the C standard.

The common case (for users of this API) is passing the size of a
relatively small object, of fixed size. There is no practical issue
there. The less common case is where the value is unknown at compile
time, meaning an extra check and an explicit conversion are needed. It’s
not remotely difficult to deal with, it’s just an annoyance (as I
previously wrote).
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Thu, 29 Aug 2024 16:13:42 +0100
Richard Kettlewell <invalid@invalid.invalid> wrote:

No, it’s not necessarily wrong. If the value fits in the destination
type there’s nothing wrong with it. The results are well-defined and do
not change the value. You can look up the rules in the C standard.

What is wrong is making assumptions about the relative size of long
and size_t - AFAIK the standard makes no guarantees about that. Note that
it's only "wrong" if you care about portability - long experience suggests
that not caring about portability is a good way to get bitten on the arse.
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
For forms of government let fools contest
Whate're is best administered is best - Alexander Pope
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

In article <20240829102839.5bb67af25e568ebabc65ede6@eircom.net>, steveo@eircom.net says...

On Thu, 29 Aug 2024 09:32:49 +0100
Richard Kettlewell <invalid@invalid.invalid> wrote:

I don?t think I?d fault either decision though the fact that we?ve ended
up with two conventions does make writing/maintaining portable code a
bit more annoying,

Portable code should only rely on the standards not
implementations, some very weird possibilities are legal within the
standard.

Heh, yes. I worked for several years on a machine where a null pointer
wasn't all bits zero, and where char* was a different size to any other pointer.
--
John
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Thu, 29 Aug 2024 18:57:57 +0100
John Aldridge <jpsa@cantab.net> wrote:

In article <20240829102839.5bb67af25e568ebabc65ede6@eircom.net>, steveo@eircom.net says...

On Thu, 29 Aug 2024 09:32:49 +0100
Richard Kettlewell <invalid@invalid.invalid> wrote:

I don?t think I?d fault either decision though the fact that we?ve
ended up with two conventions does make writing/maintaining portable
code a bit more annoying,

Portable code should only rely on the standards not
implementations, some very weird possibilities are legal within the standard.

Heh, yes. I worked for several years on a machine where a null pointer wasn't all bits zero, and where char* was a different size to any other pointer.

That rings vague bells, what was it ?
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
For forms of government let fools contest
Whate're is best administered is best - Alexander Pope
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 29/08/2024 19:13, Ahem A Rivet's Shot wrote:

On Thu, 29 Aug 2024 18:57:57 +0100
John Aldridge <jpsa@cantab.net> wrote:

In article <20240829102839.5bb67af25e568ebabc65ede6@eircom.net>,
steveo@eircom.net says...

On Thu, 29 Aug 2024 09:32:49 +0100
Richard Kettlewell <invalid@invalid.invalid> wrote:

I don?t think I?d fault either decision though the fact that we?ve
ended up with two conventions does make writing/maintaining portable
code a bit more annoying,

Portable code should only rely on the standards not
implementations, some very weird possibilities are legal within the
standard.

Heh, yes. I worked for several years on a machine where a null pointer
wasn't all bits zero, and where char* was a different size to any other
pointer.

That rings vague bells, what was it ?

24 bit pointers were I think quite common, but isn't the 'null pointer' *defined* to be
(Char *)0 ?
Otherwise how could you test for it?
--
Canada is all right really, though not for the whole weekend.

"Saki"

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

The Natural Philosopher <tnp@invalid.invalid> writes:

24 bit pointers were I think quite common, but isn't the 'null
pointer' *defined* to be (Char *)0 ?
Otherwise how could you test for it?

The null pointer you get from (char *)0 (or similar constructions)
doesn’t have to be all bits 0.

https://c-faq.com/null/index.html
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

Ahem A Rivet's Shot <steveo@eircom.net> writes:

Richard Kettlewell <invalid@invalid.invalid> wrote:

No, it’s not necessarily wrong. If the value fits in the destination
type there’s nothing wrong with it. The results are well-defined and do
not change the value. You can look up the rules in the C standard.

What is wrong is making assumptions about the relative size of long
and size_t - AFAIK the standard makes no guarantees about that.

Nobody is making any such assumption here. Everyone involved knows
perfectly well that size_t could be a different size to long.

Note that it's only "wrong" if you care about portability - long
experience suggests that not caring about portability is a good way to
get bitten on the arse.

The API in question is essentially fixed in this respect. Changing these details would break all the applications that the API supports. We just
have to live with its infelicities regardless of how much anyone
involved may care about portability.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 29/08/2024 13:09, The Natural Philosopher wrote:

Most code that cares seems to use things like int_32 or long_64 where it matters and macro expand that on a per target hardware basis

Yes stdint.h is your friend

---druck
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 2024-08-29, Richard Kettlewell <invalid@invalid.invalid> wrote:

There are always the int<n>_t types for when size matters.

Life is not always that simple and declaring how things ‘should’ be does not fix a single line of code.

What a mess - Much simpler on Fortran, you just need to remember
which variable name spellings are floats.

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

Am 30.08.24 um 03:13 schrieb crn:

On 2024-08-29, Richard Kettlewell <invalid@invalid.invalid> wrote:

There are always the int<n>_t types for when size matters.

Life is not always that simple and declaring how things ‘should’ be does >> not fix a single line of code.

What a mess - Much simpler on Fortran, you just need to remember
which variable name spellings are floats.

GOD is real unless declared integer.
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 29/08/2024 20:26, Richard Kettlewell wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

24 bit pointers were I think quite common, but isn't the 'null
pointer' *defined* to be (Char *)0 ?
Otherwise how could you test for it?

The null pointer you get from (char *)0 (or similar constructions)
doesn’t have to be all bits 0.

https://c-faq.com/null/index.html

Ah, thanks.

Hadn't apprecaied the level of mapping going on during compilation.
--
In theory, there is no difference between theory and practice.
In practice, there is.
-- Yogi Berra

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

In article <20240829191334.570e88c7507598ffe5b28d87@eircom.net>, steveo@eircom.net says...

Portable code should only rely on the standards not
implementations, some very weird possibilities are legal within the standard.

Heh, yes. I worked for several years on a machine where a null pointer wasn't all bits zero, and where char* was a different size to any other pointer.

That rings vague bells, what was it ?

Prime. It was word, not byte, addressed, so a char* had to be bigger.
--
John
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Fri, 30 Aug 2024 14:28:06 +0100
John Aldridge <jpsa@cantab.net> wrote:

In article <20240829191334.570e88c7507598ffe5b28d87@eircom.net>, steveo@eircom.net says...

Portable code should only rely on the standards not implementations, some very weird possibilities are legal within the standard.

Heh, yes. I worked for several years on a machine where a null
pointer wasn't all bits zero, and where char* was a different size to
any other pointer.

That rings vague bells, what was it ?

Prime. It was word, not byte, addressed, so a char* had to be bigger.

Thank you, that was indeed the bell it rang. I only heard about it, never met it.
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
For forms of government let fools contest
Whate're is best administered is best - Alexander Pope
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 30/08/2024 14:28, John Aldridge wrote:

In article <20240829191334.570e88c7507598ffe5b28d87@eircom.net>, steveo@eircom.net says...

Portable code should only rely on the standards not
implementations, some very weird possibilities are legal within the
standard.

Heh, yes. I worked for several years on a machine where a null pointer
wasn't all bits zero, and where char* was a different size to any other
pointer.

That rings vague bells, what was it ?

Prime. It was word, not byte, addressed, so a char* had to be bigger.

I used a Prime750 at Uni. But only undergrad tasks in Prime BASIC and
some Fortran. It seemed quite fast at the time in timeshare mode with
plenty of undergrads using it. But the CPU was only as fast as an 8MHz
68000!

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 30/08/2024 15:39, mm0fmf wrote:

On 30/08/2024 14:28, John Aldridge wrote:

In article <20240829191334.570e88c7507598ffe5b28d87@eircom.net>,
steveo@eircom.net says...

    Portable code should only rely on the standards not
implementations, some very weird possibilities are legal within the
standard.

Heh, yes. I worked for several years on a machine where a null pointer >>>> wasn't all bits zero, and where char* was a different size to any other >>>> pointer.

    That rings vague bells, what was it ?

Prime. It was word, not byte, addressed, so a char* had to be bigger.

I used a Prime750 at Uni. But only undergrad tasks in Prime BASIC and
some Fortran. It seemed quite fast at the time in timeshare mode with
plenty of undergrads using it. But the CPU was only as fast as an 8MHz 68000!

That is the staggering thing. CPU performance in the mini era wasn't
that hot at all.

I see someone has made a Pi PICO emulate a range of 6502 based computers
- apple II etc.

I am fairly sure a PI Zero could outperform a 386 running SCO Unix...and
that was pretty comparable with - if not better than - a PDP 11.
--
“There are two ways to be fooled. One is to believe what isn’t true; the other is to refuse to believe what is true.”

—Soren Kierkegaard

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 30/08/2024 15:45, The Natural Philosopher wrote:

On 30/08/2024 15:39, mm0fmf wrote:

On 30/08/2024 14:28, John Aldridge wrote:

In article <20240829191334.570e88c7507598ffe5b28d87@eircom.net>,
steveo@eircom.net says...

    Portable code should only rely on the standards not
implementations, some very weird possibilities are legal within the >>>>>> standard.

Heh, yes. I worked for several years on a machine where a null pointer >>>>> wasn't all bits zero, and where char* was a different size to any
other
pointer.

    That rings vague bells, what was it ?

Prime. It was word, not byte, addressed, so a char* had to be bigger.

I used a Prime750 at Uni. But only undergrad tasks in Prime BASIC and
some Fortran. It seemed quite fast at the time in timeshare mode with
plenty of undergrads using it. But the CPU was only as fast as an 8MHz
68000!

That is the staggering thing. CPU performance in the mini era wasn't
that hot at all.

I see someone has made a Pi PICO emulate a range of 6502 based computers
- apple II etc.

I am fairly sure a PI Zero could outperform a 386 running SCO Unix...and that was pretty comparable with - if not better than - a PDP 11.

The 386 slaughtered most of the Unix Minis of the time.

The PDP 11 was already a legacy predecessor of the Vax, did they even
have demand paging? PDP 11s were around in some of the companies I
worked for, but they were for the old codger programmers (i.e. 30+).
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 29/08/2024 18:57, John Aldridge wrote:

In article <20240829102839.5bb67af25e568ebabc65ede6@eircom.net>, steveo@eircom.net says...

On Thu, 29 Aug 2024 09:32:49 +0100
Richard Kettlewell <invalid@invalid.invalid> wrote:

I don?t think I?d fault either decision though the fact that we?ve ended >>> up with two conventions does make writing/maintaining portable code a
bit more annoying,

Portable code should only rely on the standards not
implementations, some very weird possibilities are legal within the
standard.

Heh, yes. I worked for several years on a machine where a null pointer
wasn't all bits zero, and where char* was a different size to any other pointer.

The follow question to the non-zero NULL pointer, is what OS didn't
protect memory address 0, so you could dereference a NULL pointer
without a hardware exception?

I never saw it myself, but we were always cautioned that such an OS
existed. Maybe it was an old wives' tale?
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

In article <vasliu$hgao$1@dont-email.me>, mm0fmf <none@invalid.com> wrote:

I used a Prime750 at Uni. But only undergrad tasks in Prime BASIC and
some Fortran. It seemed quite fast at the time in timeshare mode with
plenty of undergrads using it. But the CPU was only as fast as an 8MHz >68000!

I used Primes at uni too - starting with the 550 in 1980 but it was
woefully underpowered for us - I think we might well have been the first
intake of students who'd already had 1 or 2 years experience of micros
at school by then (Apple II in my case). I felt that the Apple II could
have run rings round the Prime. We were doing mostly COBOL, Pascal and
FORTRAN. Also some assembler.

Their systems were archaic - we had to write the programs on coding forms,
it was typed in by "the girls" then submitted to the batch system and
if we were lucky we'd get it back the following day.

Eventually they relented and hooked up a room of TTY33s for us to do
our own edits on.. But really that just made it worse. Upgraded to a
750 then eventually 9950s but by then it was really too late...

Fortunately I also found a PDP11/40 tucked away in a little room running Unix...

Gordon
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 30/08/2024 15:45, The Natural Philosopher wrote:

On 30/08/2024 15:39, mm0fmf wrote:

On 30/08/2024 14:28, John Aldridge wrote:

In article <20240829191334.570e88c7507598ffe5b28d87@eircom.net>,
steveo@eircom.net says...

    Portable code should only rely on the standards not
implementations, some very weird possibilities are legal within the >>>>>> standard.

Heh, yes. I worked for several years on a machine where a null pointer >>>>> wasn't all bits zero, and where char* was a different size to any
other
pointer.

    That rings vague bells, what was it ?

Prime. It was word, not byte, addressed, so a char* had to be bigger.

I used a Prime750 at Uni. But only undergrad tasks in Prime BASIC and
some Fortran. It seemed quite fast at the time in timeshare mode with
plenty of undergrads using it. But the CPU was only as fast as an 8MHz
68000!

That is the staggering thing. CPU performance in the mini era wasn't
that hot at all.

I see someone has made a Pi PICO emulate a range of 6502 based computers
- apple II etc.

I am fairly sure a PI Zero could outperform a 386 running SCO Unix...and that was pretty comparable with - if not better than - a PDP 11.

The CPUs may not have had stunning performance but were generally quite
a bit quicker than the Z80/6502s of the day. The real performance came
from having disks and ISTR hardware assisted IO. i.e. the CPU didn't
have to poll or handle IRQs from each UART but there was something
helping. It's all so long ago now I forget the details. What I do
remember was it was around 1985 when someone lit the blue touch paper
and the performance of micros started rocketing. Though if you started
10 years before me there will have been something that was when
performance took off for you. I think everyone has some point in their
memory when things started to go whoosh!

In 1989 I was writing Z80 assembler to control medical gear. All the
code took about 45mins to cross assemble and link on a Unix system
running on a Vax 11/730. In 1990 we got a 25MHz 80386 running DOS and
the same source took under 3mins to cross assemble and link. The
bottleneck went from the time to build the code to the time to erase,
download and burn the EPROMS.

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 30/08/2024 20:50, mm0fmf wrote:

On 30/08/2024 15:45, The Natural Philosopher wrote:

On 30/08/2024 15:39, mm0fmf wrote:

On 30/08/2024 14:28, John Aldridge wrote:

In article <20240829191334.570e88c7507598ffe5b28d87@eircom.net>,
steveo@eircom.net says...

    Portable code should only rely on the standards not
implementations, some very weird possibilities are legal within the >>>>>>> standard.

Heh, yes. I worked for several years on a machine where a null
pointer
wasn't all bits zero, and where char* was a different size to any >>>>>> other
pointer.

    That rings vague bells, what was it ?

Prime. It was word, not byte, addressed, so a char* had to be bigger.

I used a Prime750 at Uni. But only undergrad tasks in Prime BASIC and
some Fortran. It seemed quite fast at the time in timeshare mode with
plenty of undergrads using it. But the CPU was only as fast as an
8MHz 68000!

That is the staggering thing. CPU performance in the mini era wasn't
that hot at all.

I see someone has made a Pi PICO emulate a range of 6502 based
computers - apple II etc.

I am fairly sure a PI Zero could outperform a 386 running SCO
Unix...and that was pretty comparable with - if not better than - a
PDP 11.

The CPUs may not have had stunning performance but were generally quite
a bit quicker than the Z80/6502s of the day. The real performance came
from having disks and ISTR hardware assisted IO. i.e. the CPU didn't
have to poll or handle IRQs from each UART but there was something
helping. It's all so long ago now I forget the details. What I do
remember was it was around 1985 when someone lit the blue touch paper
and the performance of micros started rocketing.   Though if you started 10 years before me there will have been something that was when
performance took off for you. I think everyone has some point in their memory when things started to go whoosh!

In 1989 I was writing Z80 assembler to control medical gear. All the
code took about 45mins to cross assemble and link on a Unix system
running on a Vax 11/730. In 1990 we got a 25MHz 80386 running DOS and
the same source took under 3mins to cross assemble and link.  The bottleneck went from the time to build the code to the time to erase, download and burn the EPROMS.

Yes. I was writing C and assembler for a 6809 cross complied on a PDP/11.
We had PCS as serial terminals and text editors.

Compile was very slow compared to on a PC.

The thing was that until the 386 Intel CPUs didn't have the big boy
features. After that they did.

Even an old IBM mainframe could be emulated under AIX on a PC.
I did some work on a Vax running Unix too. Better, but still pretty awful
--
I would rather have questions that cannot be answered...
...than to have answers that cannot be questioned

Richard Feynman



--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 30/08/2024 22:53, The Natural Philosopher wrote:

On 30/08/2024 20:50, mm0fmf wrote:

On 30/08/2024 15:45, The Natural Philosopher wrote:

On 30/08/2024 15:39, mm0fmf wrote:

On 30/08/2024 14:28, John Aldridge wrote:

In article <20240829191334.570e88c7507598ffe5b28d87@eircom.net>,
steveo@eircom.net says...

    Portable code should only rely on the standards not
implementations, some very weird possibilities are legal within the >>>>>>>> standard.

Heh, yes. I worked for several years on a machine where a null
pointer
wasn't all bits zero, and where char* was a different size to any >>>>>>> other
pointer.

    That rings vague bells, what was it ?

Prime. It was word, not byte, addressed, so a char* had to be bigger. >>>>>

I used a Prime750 at Uni. But only undergrad tasks in Prime BASIC
and some Fortran. It seemed quite fast at the time in timeshare mode
with plenty of undergrads using it. But the CPU was only as fast as
an 8MHz 68000!

That is the staggering thing. CPU performance in the mini era wasn't
that hot at all.

I see someone has made a Pi PICO emulate a range of 6502 based
computers - apple II etc.

I am fairly sure a PI Zero could outperform a 386 running SCO
Unix...and that was pretty comparable with - if not better than - a
PDP 11.

The CPUs may not have had stunning performance but were generally
quite a bit quicker than the Z80/6502s of the day. The real
performance came from having disks and ISTR hardware assisted IO. i.e.
the CPU didn't have to poll or handle IRQs from each UART but there
was something helping. It's all so long ago now I forget the details.
What I do remember was it was around 1985 when someone lit the blue
touch paper and the performance of micros started rocketing.   Though
if you started 10 years before me there will have been something that
was when performance took off for you. I think everyone has some point
in their memory when things started to go whoosh!

In 1989 I was writing Z80 assembler to control medical gear. All the
code took about 45mins to cross assemble and link on a Unix system
running on a Vax 11/730. In 1990 we got a 25MHz 80386 running DOS and
the same source took under 3mins to cross assemble and link.  The
bottleneck went from the time to build the code to the time to erase,
download and burn the EPROMS.

Yes. I was writing C and assembler for a 6809 cross complied on a PDP/11.
We had PCS as serial terminals and text editors.

Compile was very slow compared to on a PC.

The thing was that until the 386 Intel CPUs didn't have the big boy features.  After that they did.

Even an old IBM mainframe could be emulated under AIX on a PC.
I did some work on a Vax running Unix too. Better, but still pretty awful

Vaxen were much better running VMS!
--
Chris

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 31/08/2024 00:26, Chris Townley wrote:

On 30/08/2024 22:53, The Natural Philosopher wrote:

On 30/08/2024 20:50, mm0fmf wrote:

On 30/08/2024 15:45, The Natural Philosopher wrote:

On 30/08/2024 15:39, mm0fmf wrote:

On 30/08/2024 14:28, John Aldridge wrote:

In article <20240829191334.570e88c7507598ffe5b28d87@eircom.net>,
steveo@eircom.net says...

    Portable code should only rely on the standards not
implementations, some very weird possibilities are legal within >>>>>>>>> the
standard.

Heh, yes. I worked for several years on a machine where a null >>>>>>>> pointer
wasn't all bits zero, and where char* was a different size to >>>>>>>> any other
pointer.

    That rings vague bells, what was it ?

Prime. It was word, not byte, addressed, so a char* had to be bigger. >>>>>>

I used a Prime750 at Uni. But only undergrad tasks in Prime BASIC
and some Fortran. It seemed quite fast at the time in timeshare
mode with plenty of undergrads using it. But the CPU was only as
fast as an 8MHz 68000!

That is the staggering thing. CPU performance in the mini era wasn't
that hot at all.

I see someone has made a Pi PICO emulate a range of 6502 based
computers - apple II etc.

I am fairly sure a PI Zero could outperform a 386 running SCO
Unix...and that was pretty comparable with - if not better than - a
PDP 11.

The CPUs may not have had stunning performance but were generally
quite a bit quicker than the Z80/6502s of the day. The real
performance came from having disks and ISTR hardware assisted IO.
i.e. the CPU didn't have to poll or handle IRQs from each UART but
there was something helping. It's all so long ago now I forget the
details. What I do remember was it was around 1985 when someone lit
the blue touch paper and the performance of micros started
rocketing.   Though if you started 10 years before me there will have >>> been something that was when performance took off for you. I think
everyone has some point in their memory when things started to go
whoosh!

In 1989 I was writing Z80 assembler to control medical gear. All the
code took about 45mins to cross assemble and link on a Unix system
running on a Vax 11/730. In 1990 we got a 25MHz 80386 running DOS and
the same source took under 3mins to cross assemble and link.  The
bottleneck went from the time to build the code to the time to erase,
download and burn the EPROMS.

Yes. I was writing C and assembler for a 6809 cross complied on a PDP/11.
We had PCS as serial terminals and text editors.

Compile was very slow compared to on a PC.

The thing was that until the 386 Intel CPUs didn't have the big boy
features.  After that they did.

Even an old IBM mainframe could be emulated under AIX on a PC.
I did some work on a Vax running Unix too. Better, but still pretty awful

Vaxen were much better running VMS!

Were they?
I dont think they got any faster..
--
"Anyone who believes that the laws of physics are mere social
conventions is invited to try transgressing those conventions from the
windows of my apartment. (I live on the twenty-first floor.) "

Alan Sokal

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Wed, 28 Aug 2024 21:29:03 +0100, druck wrote:

On 28/08/2024 00:30, Lawrence D'Oliveiro wrote:

Compare the POSIX APIs, where they were careful to use generic types
like “size_t” and “time_t”, so that the same code could be compiled, >> unchanged, to work on both 32-bit and 64-bit architectures. Not
something Windows code can manage.

You can do this on Windows too, but they had to bastardise their C
compiler for people that hadn't. It's the only one that on a 64 bit
platform that has long as 32 bits.

I know. This is why you have “LP64” (long and pointers both 64-bits) versus “LLP64” (only long long and pointers are 64 bits, long is still 32 bits). I think LP64 is pretty much universal outside the Windows world.
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Thu, 29 Aug 2024 21:33:28 +0100, druck wrote:

Yes stdint.h is your friend

Unless you have an elderly code base that still hasn’t caught up with
C99 ...
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Thu, 29 Aug 2024 10:41:55 +0100, Pancho wrote:

C was shit, for not making types explicit ...

Back then, there were still machines with word lengths like 12, 18, 24, 36 bits and even 60 bits.

Not byte-addressable, of course.
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 01/09/2024 08:50, Lawrence D'Oliveiro wrote:

On Thu, 29 Aug 2024 21:33:28 +0100, druck wrote:

Yes stdint.h is your friend

Unless you have an elderly code base that still hasn’t caught up with
C99 ...

Or you were programming in C on an Analog Devices SHARC were char was 32
bits.

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Sun, 1 Sep 2024 11:07:17 +0100
mm0fmf <none@invalid.com> wrote:

On 01/09/2024 08:50, Lawrence D'Oliveiro wrote:

On Thu, 29 Aug 2024 21:33:28 +0100, druck wrote:

Yes stdint.h is your friend

Unless you have an elderly code base that still hasn’t caught up with
C99 ...

Or you were programming in C on an Analog Devices SHARC were char was 32 bits.

I'll bet that broke a lot of bad code :)

Stll even in that environment a compliant compiler should still
provide int<n>_t types. They'd probably have to have horrendously
inefficient implementations not dissimilar to the bitfields in structs but
they should exist. Woe betide anyone who thought they could put a char into
an int16_t safely though.
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
For forms of government let fools contest
Whate're is best administered is best - Alexander Pope
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 01/09/2024 11:53, Ahem A Rivet's Shot wrote:

On Sun, 1 Sep 2024 11:07:17 +0100
mm0fmf <none@invalid.com> wrote:

On 01/09/2024 08:50, Lawrence D'Oliveiro wrote:

On Thu, 29 Aug 2024 21:33:28 +0100, druck wrote:

Yes stdint.h is your friend

Unless you have an elderly code base that still hasn’t caught up with
C99 ...

Or you were programming in C on an Analog Devices SHARC were char was 32
bits.

I'll bet that broke a lot of bad code :)

Stll even in that environment a compliant compiler should still
provide int<n>_t types. They'd probably have to have horrendously
inefficient implementations not dissimilar to the bitfields in structs but they should exist. Woe betide anyone who thought they could put a char into an int16_t safely though.

Ah yes. I was cross compiling C for a 6809 (on a PDP/11) when I
discovered that to do anything with a char it was promoted into a 16 bit
int, which on an 8 bit microprocessor results in a shit load of code.

Needless to say there ended up being a lot of #asm statements..
--
Religion is regarded by the common people as true, by the wise as
foolish, and by the rulers as useful.

(Seneca the Younger, 65 AD)


--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 01/09/2024 11:53, Ahem A Rivet's Shot wrote:

On Sun, 1 Sep 2024 11:07:17 +0100
mm0fmf <none@invalid.com> wrote:

On 01/09/2024 08:50, Lawrence D'Oliveiro wrote:

On Thu, 29 Aug 2024 21:33:28 +0100, druck wrote:

Yes stdint.h is your friend

Unless you have an elderly code base that still hasn’t caught up with
C99 ...

Or you were programming in C on an Analog Devices SHARC were char was 32
bits.

I'll bet that broke a lot of bad code :)

Stll even in that environment a compliant compiler should still
provide int<n>_t types. They'd probably have to have horrendously
inefficient implementations not dissimilar to the bitfields in structs but they should exist. Woe betide anyone who thought they could put a char into an int16_t safely though.

ISTR the compiler was a custom version of gcc 1.xx. 26 years ago so the
exact version has evaporated from my memory. The compiler did understand
the hardware funnies well, floats were 32bits or 40bits, it understood
the zero overhead loops and circular buffer support. But all the fixed
point multiply and accumulate stuff we did in inline assembler. All the performance stuff was in hand optimised assembler as you could do a DMA
in, integer operation, multiply&accumulate, float operation and a DMA
out all the in one cycle. There was dual access on chip RAM too, you
could read and then write the same location in the same clock cycle.

Careful programming meant you could get quite amazing levels of DSP
processing run on what was only a 66MHz device.

--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Sun, 2024-09-01 at 15:47 +0100, mm0fmf wrote:

STR the compiler was a custom version of gcc 1.xx. 26 years ago so
the exact version has evaporated from my memory.

Your dates are slightly off. These gcc 1.x versions were between 1987 -
1993. I do remember using 2.7.2.3 with Linux 2.0 in 1997.
--
Tactical Nuclear Kittens
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Fri, 30 Aug 2024 01:13:30 -0000 (UTC), crn wrote:

On 2024-08-29, Richard Kettlewell <invalid@invalid.invalid> wrote:

There are always the int<n>_t types for when size matters.

Life is not always that simple and declaring how things ‘should’ be
does not fix a single line of code.

What a mess - Much simpler on Fortran, you just need to remember which variable name spellings are floats.

Which ones are double precision?
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Sun, 1 Sep 2024 11:07:17 +0100, mm0fmf wrote:

Or you were programming in C on an Analog Devices SHARC were char was 32 bits.

I was watching a video clip the other day which talked about the Symbolics 3600 Lisp Machine from the 1980s. This one had core Lisp constructs like garbage collection and arbitrary-precision integers programmed into its microcode.

When they came to implement a C compiler, they didn’t bother defining finite-precision integers for it: they just had it use the arbitrary-
precision ones, since they were already available in the machine
instruction set. The “sizeof” operator did return small, fixed values for types, but for integers, they were essentially meaningless.

Somebody wrote a test program to determine how large an integer was, by initializing a variable to 1 and left-shifting it until it overflowed and
went to zero.

The program ran for over an hour, exhausted all the available memory, and crashed.
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On 01/09/2024 21:36, Single Stage to Orbit wrote:

On Sun, 2024-09-01 at 15:47 +0100, mm0fmf wrote:

STR the compiler was a custom version of gcc 1.xx. 26 years ago so
the exact version has evaporated from my memory.

Your dates are slightly off. These gcc 1.x versions were between 1987 -
1993. I do remember using 2.7.2.3 with Linux 2.0 in 1997.

I'd agree that gcc main line release would be around 2.7 in 1998. I can remember I started writing software for a Strongarm based video security system in 2001. By then ARM kernels were compiled/cross-compiled with
gcc 2.95.x. Then gcc 3.0 / 3.1 came out which was better for userland
code but kernels compiled with it would not run so we stayed with 2.95
for some time.

However, the SHARC stuff was definitely derived from gcc 1.x in 1998 as
it struck me as very old as 2.x had been out for a while by then. This
was the version of the compiler that ran on Windows. ISTR I used a PII
200MHz probably running WinNT to develop on. The Unix systems were
reserved for ADA, Occam and other esoteric stuff ;-)
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Mon, 2 Sep 2024 13:10:38 +0100
mm0fmf <none@invalid.com> wrote:

However, the SHARC stuff was definitely derived from gcc 1.x in 1998 as
it struck me as very old as 2.x had been out for a while by then.

I recall that gcc 1.6.3 was considered something of a golden
version of the original C compiler and IIRC 2.0 brought in a lot of the structure that converted it from the GNU C Compile to the GNU Compiler Collection.
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
For forms of government let fools contest
Whate're is best administered is best - Alexander Pope
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Fri, 30 Aug 2024 22:53:58 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

[]

The thing was that until the 386 Intel CPUs didn't have the big boy features. After that they did.

Even an old IBM mainframe could be emulated under AIX on a PC.

Just at the cusp there was
https://en.wikipedia.org/wiki/XT/370

That ran a style of CP/CMS.
--
Bah, and indeed Humbug.
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Mon, 2024-09-02 at 13:10 +0100, mm0fmf wrote:

On 01/09/2024 21:36, Single Stage to Orbit wrote:

On Sun, 2024-09-01 at 15:47 +0100, mm0fmf wrote:

STR the compiler was a custom version of gcc 1.xx. 26 years ago
so the exact version has evaporated from my memory.

Your dates are slightly off. These gcc 1.x versions were between
1987 - 1993. I do remember using 2.7.2.3 with Linux 2.0 in 1997.

I'd agree that gcc main line release would be around 2.7 in 1998. I
can remember I started writing software for a Strongarm based video
security system in 2001. By then ARM kernels were compiled/cross-
compiled with gcc 2.95.x. Then gcc 3.0 / 3.1 came out which was
better for userland code but kernels compiled with it would not run
so we stayed with 2.95 for some time.

Now, this I do definitely do remember. Stuck on 2.95.3 for years for
the kernel, whilst we were able to use newer compilers just for the
userspace. Linus kept running into code generation bugs and his rants
were gold! :-D
Also the great libc5 / glibc2 switch over which caused me a few
nightmares :-)

However, the SHARC stuff was definitely derived from gcc 1.x in 1998
as it struck me as very old as 2.x had been out for a while by then. 
This was the version of the compiler that ran on Windows. ISTR I used
a PII 200MHz probably running WinNT to develop on. The Unix systems
were reserved for ADA, Occam and other esoteric stuff ;-)

Yeah, that'd be right. Some people do keep old toolchains around
because it's the only way to build code for platforms that have gone
the way of the Dodo.
--
Tactical Nuclear Kittens
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Mon, 2 Sep 2024 13:10:38 +0100, mm0fmf wrote:

By then ARM kernels were compiled/cross-compiled with
gcc 2.95.x. Then gcc 3.0 / 3.1 came out which was better for userland
code but kernels compiled with it would not run so we stayed with 2.95
for some time.

This would have been the time of the great EGCS schism. The GNU people (*cough* Stallman *cough*) were being overly control-freaky as per usual,
so a bunch of GCC contributors forked off the code into a new project
called “EGCS”. This soon became known for generating better code than the original GCC.

Eventually the GNU folks realized the error of their ways. Their existing “GCC” project was taken out back and put out of its misery, and the EGCS project took over the “GCC” name.

I thought this began with GCC 3.0, but according to this <https://gcc.gnu.org/wiki/History#EGCS> it was actually 2.95.
--- Synchronet 3.19b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.raspberry-pi

On Fri, 30 Aug 2024 16:20:51 +0100, Pancho wrote:

The 386 slaughtered most of the Unix Minis of the time.

True, but the coming of RISC in 1989 or so completely turned the tables;
it wasn’t until about 1995 or thereafter that Intel was able to
successfully fight back.

The PDP 11 was already a legacy predecessor of the Vax, did they even
have demand paging?

No. The entire 64kiB address space was covered by just 8 page table
entries.
--- Synchronet 3.19b-Win32 NewsLink 1.113