[Simh] SLowing up simh

[Greg Johnson]

I've been kind of thinking about this since I would like to keep my VAX
simulator running all the time but, on a notebook, the host cpu can get
quite hot...  In fact I think my notebook can second as a hair dryer
when I get the vax simulator running...

I would think we could have some sort of 'idle loop' detection in the
main cpu simulation processing loop.  Something where the specific cpu
code would call a 'ok nothing interesting happened during this cycle'
routine.  After a certain number of these cycles the processing loop
would start entering short sleeps between cycles -- freeing up your
host's cpu for other things.  This way if the simulated cpu is busy it
gets the necessary cycles it needs while if it is doing 'nothing' it
dozes off between cycles.  Once something happens the processing picks
up again....

Some simulated device interrupts might be considered 'idle' (for example
a line frequency clock interrupt).  While others (like input from the
keyboard or ethernet) would not and would 'wake up' the simulator.

Would need two configurable values - the number of 'idle' cycles before
the simulator gets 'sleepy' and the amount of time it sleeps between cycles.

Would not have to make the change in all the different simulated
processors at the same time since, if the 'unchanged' specific cpu
simulator code does not call the 'idle' routine it will still work the
way it does now.

--- Greg

Tim Riker wrote:
> Sterling Garwood wrote:
> 
>>is there a way to slow down the simulation? I am running PDP11 
>>simulations using RSTS and RT-11 and the simulator never seems to  drop
>>into a real wait state (my real processor stays pegged out even  if
>>nothing is going on in RT-11). Since I am running on Mac OS X on  an
>>iBook I'd like to trade off simulation speed for battery life and  less
>>heat. I have a 1.3 GHz laptop so a bit of a slow up of simh  wouldn't be
>>too bad :-). My assumption is that either (or both) RSTS  and RT-11
>>actually use a wait state.
>>I looked at the code and thought about putting a nanosleep just  before
>>IFetch but I thought I'd ask before I do that.
> 
> 
> This has been discussed before, but nothing has yet been done.
> 
> I patched my local simh to use select on stdin before doing the read and
> I have it wait in the select briefly. This works fairly well as simh
> still respond immediately to a keypress. It does run significantly
> slower though,
> 
> I assert that we could somehow watch for real tight loops in the
> simulator and adjust the sleep times based on whether we are in one or
> not. That way trivial loops in the hosted machine would result it more
> cpu being given to the host. This would need some tweaking.
> 
> I would think we could at least start with a configurable wait time that
> defaults to 0. This way the default behavior would mirror the current,
> and folks that want to slow things down, could without having to patch
> and recompile.
>