RP2350 and Pico 2 - things missing

Vaxen were much better running VMS!

Were they? I dont think they got any faster..

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.

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

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

Not byte-addressable, of course.

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 s*it load of code.

Needless to say there ended up being a lot of #asm statements..

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.

Your dates are slightly off. These gcc 1.x versions were between 1987 -

Which ones are double precision?

I was watching a video clip the other day which talked about the Symbolics

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.

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

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.

Just at the cusp there was

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 :-)

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.

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

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.

No. The entire 64kiB address space was covered by just 8 page table entries.