[Simh] several SIMH instances

[Paul Hardy]

"Vince Mulhollon" said:
... in response to a post about idle loop detection:
> A better idea would be a cap for the execution rate.
> If the simulated CPU has executed 10 million instructions over the
> elapsed time of the simulator (at this moment, perhaps, 100 seconds)
> that means no more processing, sleep until the ratio drops due to
> larger elapsed time.

That is a good idea, but an answer to a different problem. I (and I suspect 
most SIMH users) don't want to slow down the simulation, but be able to have 
it share a host machine without hogging resources.

I'd like SIMH to use as much resources as are freely available (e.g. boot 
and run faster than any VAX that actually existed), but continue to run in 
the background if largely idle, while I get on with 'real work' on the same 
host machine (in my case a Windows laptop).

The idle loop detection idea seems perfect for that and I'd like to see it 
in the standard pre-built executables as soon as possible! Has there been 
any recent progress towards this?

Regards,

-- 
Paul  Hardy
Email: paul at the hardy.demon.co.uk domain
Exiled in Redlands, CA, USA


----- Original Message ----- 
From: "Vince Mulhollon" <vlm at mulhollon.com>
To: <Simh at trailing-edge.com>
Sent: Sunday, December 03, 2006 7:32 AM
Subject: Re: [Simh] several SIMH instances


> On Thu, Nov 30, 2006 at 07:17:06PM +0100, Michael Unger wrote:
>> On 2006-11-30 16:44, "Kevin Handy" wrote:
>>
>> > Patches are being worked on that will monitor the
>> > emulated CPU, and when it detects it in an idle loop,
>> > will cause the emulation to sleep. This can
>>
>> Which mechanism is used to detect an "idle loop"? In the "MicroVAX 3900
>
> A better idea would be a cap for the execution rate.
>
> If the simulated CPU has executed 10 million instructions over the
> elapsed time of the simulator (at this moment, perhaps, 100 seconds)
> that means no more processing, sleep until the ratio drops due to
> larger elapsed time.
>
> Possible config parameter:
> set instructions_per_second = 10000
>
> Bad psuedocode:
> next_run_time = total_executed_instructions/instructions_per_second;
> while (next_run_time < total_elapsed_seconds_function()) {
>  sleep;
> }
>
> Seconds is probably too granular.  But the general idea stands.
>
> Also there's no need to do floating point math to check each and every
> instruction execution vs elapsed time.  However, it's probably fair to
> have this regulation code outside a for loop that runs 1000 or maybe
> 10000 instructions.
>
> Execution would look like this:
>
> Run 1000 instructions
> Wait for real time to catch up to emulated time
> Run 1000 instructions
> Wait for real time to catch up to emulated time
> repeat ....
>
> For a machine thats "too slow" to run at real speed, it will never
> wait.
>
> This would have the benefit of being simple, applicable to any OS or
> emulated hardware, and also possibly reusable code for I/O devices.
>
> Also, the speed of the host machine would have no effect on the speed
> of the emulated machine, which I found quite a hassle when I was trying
> to use kermit on an emulated pdp-8 (the timers in the emulated kermit
> ran so fast that it essentially instantly timed out).  I vaguely remember
> successfully doing this on my 386 but it won't work due to the timeout
> issue on my new AMD64...  The idle loop patch would not fix this
> problem.
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>