Is it a lost cause?

But there isn't only one kind of CPU in the world. There are many from the ARM to Z13, including such oddities as Tilera and not forgetting PowerPC, Renesas, Freescale and many others.

{snip}

Writing system software in COBOL was awkward. Translating DEC-10 assembler to PDP-11 is difficult and to ARM worse - it can take months. Write in C and it is less than a days work.

I accept C is a little too abbreviated and needs a much better array handling system.

I do run into compiler bugs every now and then, most recently with GCC and the relatively new ARM64 support, albeit rarely.

Long walk, short pier perhaps.

Do you have any clue how GCC has been developed, how the state-of-the art in code-generation and optimization has changed, how processor architectures have become much more complex (e.g. out-of-order execution) or how many folks have contributed expertise to the Gnu Compiler Collection over the last 25 years?

If you did, you wouldn't be nervous.

I have never made such a claim. Are you making this up as you go along?

No-one can insult you unless you give your full approval to be insulted

I'm not putting anyone down; merely observing that as in all walks of life there are different degrees of competence.

Perhaps you talk about yourself , there?

There's nothing obnoxious about me. You. however, amy well be a different matter.

That group of "save areas" allocated... amounted to a stack. It was *not* allocated the same way as a stack pointer allocates things, but it *is* a stack nonetheless.

As I said, I can't remember the bootloader anymore and I toggled it in "many" times! :-) Yes, it was stashed in AC3 and then you'd do a "sta

I thought I still had some manuals and tapes but they had been lost before I last moved house 16 years back. I forgot I'd looked for them so I could donate them to a museum. It all starts to come back to me now. Well it's 33 years since I last used one. One for those people who study how memory (human) works... if I sat at the front panel and was given the first few words of the bootloader, would it come back to me?

Nope, but looking at the code it produced, they were pretty good coders!

I'm not anyway :-)

The last 2900 I used were the Beeb's 2966s. Initially they were running CME because there was still some live 1900 code awaiting replacement/ conversion. That needed two OPERs - one for G3 and one for VME/B. The stuff I did there all involved COBOL + IDMSX databases.

BTW, one of the visiting gurus told us that the microcode was all running on a 2MHz 6809. I imagine that drove a fairly impressive set of hardware prosthetics but even so it does explain the quoted PLI execution speeds.

Which leaves you no way to programmaticly detect the overflow. The end user could add memory to the job if he got an informative message.

It's somewhat ironic, you put all that coding in for malloc failure and end up being unable to detect stack allocation failure.

Or: sta 3,@sp isz sp

I'm pretty sure that the Wyse terminals cost more per user (ajusted for inflation) than a typical entry-level PC does today.

I believe that there were 6809 and similar chips running Shuttle software, but the Apollo landers had ferrite core memory in massive- looking, machined alloy chassis. I was working in NYC during 1976 and one of the fun things to do every so often was to take a walk past the IBM building on 6th Ave and see what was in the display windows. At one point Apollo Lander computer was in the window. They put a lot of interesting stuff there: one the entire window was filled with every type and version of memory they'd ever used and on another they displayed every model of disk drive starting from RAMAC.

While I've never done it, it should be a SMOP to trap the SEGV exception, and write a handler (using a private area of memory set aside for its own stack) to at least report the problem. That'd be some tricky 'battling with the compiler' to get the execution environment set up, but no more than a day of hair extraction.

Hysterical Raisins, I think ... At some reference point in history, stack overflow just "never happened" and running out of arena happened all the time.

A "stack heavy" algorithm like walking a balanced tree only uses O(log2(N)) levels of stack -- I can walk a billion element tree using 31 stack frames.

Twenty years ago, I had cause to instrument a moderately complex system in C, with much recursive code, and the stack never grew to more than

Lots of things can cause a SEGV. You can't just trap SEGV and send a message to the user to increase memory space.

Coming up with nothing on mibibytes. I have:

home> ulimit -a ... stack size (kbytes, -s) 8192 ...

Admittedly hard to use up.

In practice, a program would have to be *very* badly coded to run out of stack. Most modern stack-based systems use a stack that runs down from the top of virtualy memory, and it's extended automatically if one reaches the end of it.

Yes, 'infinite' recursion will use it all up, but we are usually talking a gigabyte or two even on a 32 bit system.

I find that hard to believe, but perhaps it's true. I'll ask the guys who are restoring a 2966.

I never used VME/B. I did use VME/K for three years, until we dumped it for a home grown operating system.