Rumor has it that early space shuttles (or perhaps earlier) used magnetic core memory, and the procedure after getting into orbit was to load the landing program into core and shut down the computer. That covered the crew from failure of the tape reader during the flight.
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.
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.
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?
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
3,myret" in the code with myret being at the *END* of the routine if you needed AC3 in the code. Then you'd return with "jmp @myret" ISTR.
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?
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.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
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.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
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
1,100 bytes. On a modern Unix-like system, the stack is given by default 8 mibibytes.
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.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.