[Coco] Re: optimizing

[KnudsenMJ at aol.com]

In a message dated 12/10/03 2:32:41 PM Eastern Standard Time, 
gene.heskett at verizon.net writes:

> You've not heard of that?  Amazing.  You build it into your os9boot 
>  file, usually right after os9p3, which is right after os9p2, and then 
>  use it as a subroutine in your program.

OK, no, I don't recall it.  Not sure that I even have an os9p3 in my boot -- 
ISTR that was for putting in some odd leftover initialization parameters, not 
debugging.

By then I was doing most of my work in C, and debugging was with the "pile of 
printfs" method.

FWIW, I've never had Shell+ either, though that was for technical reasons.  I 
suspect almost all OS-9 users run it today.
 
>  os9p3 is an error interceptor, taking any error return and reading its 
>  description from defs/error.h or some such, thereby relieving you 
>  from wearing out the manuals looking up the error codes.  It makes 
>  the manuals last a lot longer :-)

OS-9 had an "Error" command that you executed just once, and after that for 
the duration of the session (boot), you'd get English error messages instead of 
the numbers.  But I think that was Level 1 only, and went away in L2.  Sounds 
like os9P3 was a replacement for that.
  
>  os9p4 is a register dumper, adding the call f$regdmp to the os.  Save 
>  the CC on the stack, call it from anyplace in your program and the 
>  registers will be dumped to stdout.

OK, much like the firmware monitor in the KIM-1.  I did build that capability 
into a custom computer I built at Bell Labs as part of a big signal 
processing network, so I do like the concept.  Trouble is, you often need contents of 
memory, not just registers, to figure out why your program went into the weeds.
  
>  When it returns, pop the CC off the stack and continue on your merry 
>  way with nothing changed.  Its CC output is correct as printed to std 
>  out, but will not be correct by the time it returns, hence the pushs, 
>  pulls to save it for your program.  Its a great troubleshooter.

And could you hack, er, modify the register contents before you resumed?

I remember that's how interactive user input worked onthe KIM-1 -- when you 
wanted to prompt for an input, put a breakpoint.  User keys the desired value 
into a register and resumes.  --Mike K.