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,@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
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh

Reply via email to