I wonder how many of you remember the days when a computer filled a large room? The room itself had to be air conditioned to keep the system from over-heating. The ‘core’ of the computer was a board of tiny ferrite rings threaded onto a network of wires. One kilobyte was about all the RAM a computer had available. If the system ‘crashed’, the core would be dumped to a file. From this, an engineer could work out why it crashed(?).
‘CORE’ BLIMEYby Nick Ward
I have recently been writing a program on a Psion series 3. When it’s finished, it will be left to run continuously, but at present it fails ‘randomly’ after one to two hours. I can’t just wait to catch the error, so it’s a bit of a mystery. On the Psion, there is a simple error handler, which jumps to a label anywhere in the program for processing. This ‘jump’ ruins the structure of the program, so all you can really do is close down and exit safely. Obviously, this routine allows one to do ones own ‘dump’ of debugging data. I wanted to record the ‘procedure calling path’ up to the error. This seemed at first to be too difficult, but then I had an idea…
To ‘track’ the program I merely made the first line of the procedure a call to ‘push’ its own name on a ‘stack’ and increment the pointer. The last line of the procedure (before the RETURN) then became a ‘pop’ which decremented the pointer back to its original value. The stack held the exact path of the program at the time of the error. When an error occurs, the handler dumps to a file all the error details together with the procedure ‘stack’; also any GLOBAL variables which give useful information can also be logged. All this info gives much needed debugging information to the programmer. Now I have my own ‘system dump’ which is invaluable for debugging. The speed overheads of the system are not too high, though it does slow it down a bit, I now don’t have to sit and watch the Psion as it runs.
Unfortunately the Psion also has ‘panics’ for which there is no handler - the system just stops. To deal with these, if they cause problems, one can get the ‘push’ routine to store the ‘name’ of the called procedure in a file; effectively using the ‘file’ as the stack, but I think the overheads with this would slow the system down too much? If I have problems with these ‘panics’ then that is what I’ll do. I may even set a ‘TRACK’ variable with ‘0’ for OFF; ‘1’ for DUMP and ‘2’ for the stack in a file. I’ll only have to change the program in the ‘push’ routine to make it all work.
None of this is original, as the compiler probably does the same thing with both procedures and variables, all slung on some kind of stack. If I was a true ‘nerd’, I’d be doing it all in assembler…. Not a hope!