RP2350 and Pico 2 - things missing

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

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.

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 ?

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

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

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.

Yes stdint.h is your friend

---druck

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

Am 30.08.24 um 03:13 schrieb crn:

GOD is real unless declared integer.

Ah, thanks.

Hadn't apprecaied the level of mapping going on during compilation.

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.

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

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

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?

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

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

Gordon

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

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.