🚀 go-pugleaf

I too, had a program that seemed 'stuck' on one address.
The machine was a Data General Nova 3 (remember them?) and
I was writing some kind of diagnostic program in assembler.  
The way to debug such a program was by using the single step
toggle switch on the front panel and watching the lights to
follow your code as it executed one instruction at a time.

The problem I had was that the program kept jumping to location
zero instead of location 1000 (octal).  I kept reloading the
program and single stepping up the the jump, displaying each of
the accumulators (not registers) on the front panel to no avail.
The program kept on jumping to location zero instead of 1000.

After many minutes of this the answer dawned on me.  I toggled the
lamp test switch (which turned on all of the lights) and sure enough,
the light at octal 1000 was burned out.  The program *was* jumping
to 1000 all along, but with that light burned out the front panel
only showed zero.

What ever happened to front panels anyway?  I miss them.

					Andrew MacRae
					Sun Microsystems

>I too, had a program that seemed 'stuck' on one address.
Alas, the address in question was zero, so its was reboot-time whenever
this occured. Real quick!

  I and two collegaues had been writing a program that ran stand-alone on an
IBM 303x (well, actually virtual standalone, we were using vm to debug it).
One of the things it had to do was dispatch interrupts, which on a /360 was
something of a giant pain.  Instead of writing the world's longest case
statement, we checked the manual for the supposed behavior of the channels
and sure enough, the channel control program counter pointed to the next
instruction after the end of the channel program.  So I decided that the
channel programs would:
	1) consist of single instructions
	2) not modify themselves, and
	3) be immediatly followed by the interrupt handler for that
	   program.
  This worked perfectly as we started single-stepping through the program.
The first interrupt came in, the common handler set up a frame and called
the address in the channel's pc, it ran, detected that this was the first
time the device (an input pretending to be a cardreader) had been called and
this was just a "acknowlege startup" interrupt, returned, did an RTI and
all was well.  Then I handed it a "card".  
	Reboot.  
	Trace it again, plant a breakpoint in the interrupt handler, hand it
a card.
	Reboot.
	Trace it AGAIN, plan a breakpoint in the common handler, hand it a
card, watch it pick up the channel pc and branch to it.
	Reboot.

  What!!!!!  I just saw it work properly. It branched to the correct
location:  Er... it branched to the pc, anyway... 

 Yes, it branched to the contents of the channel pc, which were zero. Thats
the cause of the reboot.
  It seems like the channel pc was never used under VM, DOS & MVS unless
there was an error, so it was never set by VM unless the interrupt was due
to an error, startup interupt or other unusual event.  If it was a
non-excepional i/o interrupt the channel pc was zeroed. To this day I don't
know if the bare iron would do the same thing: we never got time on a
stand-alone machine to try it.

  Ah well, I never liked the /3sickly, anyway.

--dave


-- 
David Collier-Brown,  | davecb@yunexus, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave 
Willowdale, Ontario,  | Joyce C-B:
CANADA. 416-223-8968  |    He's so smart he's dumb.

|>I too, had a program that seemed 'stuck' on one address.

Speaking of being stuck on one address, my professor once told this
tale of misoptimization, quite possibly apocryphal. It seems these
computer architects were looking to speed up their machine. They looked
at their dynamic instruction counts and picked a branch instruction
that was heavily used. After fixing the microcode they started up the
system again and noticed NO improvement in speed. Turns out the branch
was used by the idle loop in the scheduler. All they did was make the
CPU spin its wheels faster.