Is it a lost cause?

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.

--
Robert Riches 
spamtrap42@jacob21819.net 
 Click to see the full signature
Reply to
Robert Riches
Loading thread data ...

Where should he go if he's not allowed obnoxious behaviour in newsgroups? Standing on a roundabout shouting at passing cars?

Reply to
Rob Morley

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.

Reply to
Scott Lurndal

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

Reply to
Andrew Swallow

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

Reply to
Scott Lurndal

Long walk, short pier perhaps.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:>WIN                                      | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

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.

Reply to
Scott Lurndal

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?

Reply to
gareth G4SDW GQRP #3339

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

Reply to
gareth G4SDW GQRP #3339

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.

--

numerist at aquaporin4 dot com
Reply to
Charles Richmond

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?

Reply to
mm0fmf

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

I'm not anyway :-)

--
To ban Christmas, simply give turkeys the vote.
Reply to
The Natural Philosopher

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 
 Click to see the full signature
Reply to
Martin Gregorie

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.

--
Dan Espen
Reply to
Dan Espen

Or: sta 3,@sp isz sp

--

-TV
Reply to
Tauno Voipio

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

Reply to
Raymond Wiker

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 
 Click to see the full signature
Reply to
Martin Gregorie

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.
Reply to
Lawrence Statton NK1G

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.

--
Dan Espen
Reply to
Dan Espen

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: 
 Click to see the full signature
Reply to
Bob Eager

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.