[Simh] TOPS-10: Nested indirect address limit exceeded

[Cory Smelosky]

On Wed, 13 May 2015, Timothe Litt wrote:

> The hardware has no such limit; it's a SimH artifact.  The hardware
> would loop (taking interrupts).  A user mode bug can stop the simulation
> - which is a SimH bug that I suppose I should fix someday.  It's not a 1
> line fix.
>

Ahhh.

> .r ddt
> 1/ movei 0, at 1
> 1 $g
> should not stop timesharing!
>

Yeah, definitely not!

> The simh pc history buffer should trace how we get there.  Some examines
> should tell us whether it's in fact in user mode.
>

I discovered the issue disappears when mic isn't being started twice. 
(Unsure why it was there twice? I recall a stock SYSJOB.INI)

> My guess is that this case a bug in MIC.  It would be easier to fix when
> the CPU does the right thing, which is to more or less match the hardware.
>

Yeah.

> SimH internals make it hard to exactly do that, but here's an approach
> that should work without too much disruption.  We keep a limit -
> anything over a few dozen is unlikely in real life; a few thousand
> should be safe.  But we should treat the condition more like a page fail
> than a simulator STOP condition: it can longjmp back (as currently), but
> instead of stopping the simulation, do this:
>     a) check for user mode.  If user mode, check for interrupts & the
> timer queue & restart (the infinite looping) instruction.  That will
> burn CPU, but then it can be found and debugged under the OS.  From
> SimH's point of view, it's just an internally handled pagefail.
>

That makes sense, user-mode loops shouldn't generally stop "hardware" 
execution. ;)

>    b) If in exec mode, treat it as a hardware error - say a PF code 36,
> hard memory error.  That would cause a trap to the monitor, and with
> EDDT (or a dump when EDDT isn't loaded) it's trivial to figure out who's
> doing a bad thing.  This would actually be easier to deal with than the
> real hardware.  Doesn't change the SImH structure, but reports the error
> in a way that will get logged and can be debugged.
>

Alternatively, do what I think KLH10 does and make it a toggle. Trap to 
monitor/stop simulation toggle.

> I can push this onto my queue, unless Bob (who created this "feature")
> gets there first :-)
>

Alright.

> Meantime, it seems to hurt if you run MIC.  So for now, don't.
>

Now I have an issue where my monitor + mic no longer crashes, but not all 
GALAXY jobs start up - that should be a simple fix.

>
>

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects