Nekonomicon - gxemul with ultrix

foetz
Moderator
Who joined April 14, 2003, 4:34 a.m.

Wrote the following at Oct. 3, 2014, 10:54 p.m...

yesterday was a holiday here so i figured why not spending some time with ultrix

compiled and fired up gxemul on osx and went ahead ...

all fine except for the constant 100% cpu load caused by gxemul. maybe anyone else encountered that?

r-a-c.de

ClassicHasClass
From Sunny So Cal
Who joined July 25, 2012, 7:12 p.m.

Wrote the following at Oct. 4, 2014, 11:21 a.m...

gxemul does use a lot of CPU. It's just a very heavyweight emulator with no dynamic code compilation that I know of.

smit happens.

:Fuel:

bigred , 800MHz R16K, 4GB RAM, V12, 6.5.30
:Indy:

indy , 150MHz R4400SC, 256MB RAM, XL24, 6.5.10
:Indigo2IMP:

purplehaze , R10000, Solid IMPACT
probably posted from

bruce , Quad 2.5GHz PowerPC 970MP, 16GB RAM, Mac OS X 10.4.11
plus IBM POWER6 p520 * Apple Network Server 500 * HP C8000 * BeBox * Solbourne S3000 * Commodore 128 * many more...

foetz
Moderator
Who joined April 14, 2003, 4:34 a.m.

Wrote the following at Oct. 4, 2014, 4:46 p.m...

so you mean it using 100% all the time is how it is?

r-a-c.de

ClassicHasClass
From Sunny So Cal
Who joined July 25, 2012, 7:12 p.m.

Wrote the following at Oct. 4, 2014, 6:12 p.m...

That's exactly what I mean. That's exactly what it's doing on my G5 right now (it's spreading it over four cores, but it's clearly pegging one).

smit happens.

:Fuel:

bigred , 800MHz R16K, 4GB RAM, V12, 6.5.30
:Indy:

indy , 150MHz R4400SC, 256MB RAM, XL24, 6.5.10
:Indigo2IMP:

purplehaze , R10000, Solid IMPACT
probably posted from

bruce , Quad 2.5GHz PowerPC 970MP, 16GB RAM, Mac OS X 10.4.11
plus IBM POWER6 p520 * Apple Network Server 500 * HP C8000 * BeBox * Solbourne S3000 * Commodore 128 * many more...

robespierre
From Boston
Who joined Sept. 12, 2011, 2:28 p.m.

Wrote the following at Oct. 4, 2014, 6:34 p.m...

When emulating a computer, there is usually no upper limit to the amount of CPU consumed.
The emulator works on a "best-effort" basis, and runs the virtual CPU as fast as it can. This is not related to the useful work on the virtual CPU, since it probably busy-waits for something to happen (interrupts). In hardware you would keep the clock running all the time, and be ready to service an interrupt as soon as it happened. The only way to limit the (useless) consumption of host CPU resources is to engineer a completely new virtual "device" that does not exist in the original hardware at all, which stops the clock and everything else until something happens. This almost always requires a new device driver in the emulated OS.

foetz
Moderator
Who joined April 14, 2003, 4:34 a.m.

Wrote the following at Oct. 4, 2014, 7:15 p.m...

oh yeah very nice explanation, thanks :-)

r-a-c.de

Alver
From Zele, Belgium
Who joined Dec. 7, 2005, 4:46 p.m.

Wrote the following at Oct. 22, 2014, 6:24 a.m...

robespierre wrote: When emulating a computer, there is usually no upper limit to the amount of CPU consumed.
The emulator works on a "best-effort" basis, and runs the virtual CPU as fast as it can. This is not related to the useful work on the virtual CPU, since it probably busy-waits for something to happen (interrupts). In hardware you would keep the clock running all the time, and be ready to service an interrupt as soon as it happened. The only way to limit the (useless) consumption of host CPU resources is to engineer a completely new virtual "device" that does not exist in the original hardware at all, which stops the clock and everything else until something happens. This almost always requires a new device driver in the emulated OS.

I'm afraid (and foetz will be happy) that this statement is simply not true

I have ultrix running in SIMH on Linux (ULTRIX V4.0 (Rev. 161) - and yes, SIMH exists on OSX as well) and it doesn't consume 100% CPU. It all comes down to how the emulator implements the idle instructions of the emulated OS/chip. I'm far from an expert on how these things get implemented, but rest assured, I've made sure none of my emulated VAXen had the 100% CPU issue before setting them loose 24/7.

while (!asleep()) sheep++;

foetz
Moderator
Who joined April 14, 2003, 4:34 a.m.

Wrote the following at Oct. 22, 2014, 7:27 a.m...

indeed that's good news

grabbed simh already and will give it a try ...

r-a-c.de

Alver
From Zele, Belgium
Who joined Dec. 7, 2005, 4:46 p.m.

Wrote the following at Oct. 22, 2014, 7:56 a.m...

foetz wrote: indeed that's good news
grabbed simh already and will give it a try ...

Make sure to get the "beta" 4.x simh, it's massively improved since the "old" 3.9 branch.

My ultrix simh vax.ini:

Code: Select all


   LOAD -r /srv/vax/ka655x.bin
   

   ATTACH nvr /srv/vax/CASTOR/nvram.bin
   

   

   SET RQ0 RA90
   

   SET RQ1 RA90
   

   ATTACH RQ0 /srv/vax/CASTOR/VMS-RQ0.dsk
   

   ATTACH RQ1 /srv/vax/CASTOR/VMS-RQ1.dsk
   

   

   SET CPU 32M
   

   SET CPU IDLE
   

   SET CPU CONHALT
   

   

   SET RL DISABLE
   

   SET TS DISABLE
   

   

   SET TQ TK50
   

   ATT TQ0 /srv/vax/CASTOR/Ultrix_4.0_Supported.tap
   

   ATT TQ1 /srv/vax/CASTOR/Ultrix_4.0_Unsupported.tap
   

   

   SET XQ MAC=AA:00:04:1F:0D:69
   

   ATTACH XQ tap:tap-castor
   

   

   DEP BDR 0
   

   

   BOOT CPU
   

   EXIT

The disk and network stuff is specific, but you get the idea

while (!asleep()) sheep++;

robespierre
From Boston
Who joined Sept. 12, 2011, 2:28 p.m.

Wrote the following at Oct. 24, 2014, 4:37 p.m...

Alver wrote: I have ultrix running in SIMH on Linux (ULTRIX V4.0 (Rev. 161) - and yes, SIMH exists on OSX as well) and it doesn't consume 100% CPU. It all comes down to how the emulator implements the idle instructions of the emulated OS/chip. I'm far from an expert on how these things get implemented, but rest assured, I've made sure none of my emulated VAXen had the 100% CPU issue before setting them loose 24/7. :D

Indeed, it is a rare CPU that has "idle instructions". That isn't how hardware works: Even when the system is waiting "idle" for an event, it is still running code, and it still needs to update counters/timers.

See these links for some insight into how brittle and unreliable the heuristics used by SIMH are:
http://github.com/simh/simh/issues/80
http://www.mail-archive.com/simh@traili ... 01231.html
This approach is very VAX-like. "We've got so many instructions, we'll never have to use each one more than once!" Expecting it to work on a more rational architecture is a pipe dream.

miod
From Orgerus (France)
Who joined Oct. 9, 2009, 2:44 a.m.

Wrote the following at Oct. 25, 2014, 5:20 a.m...

robespierre wrote: Indeed, it is a rare CPU that has "idle instructions".

Actually, the vax doesn't have an idle instruction. But Ultrix and VMS' idle loop perform an ``unnatural'' and easy to identify sequence of instructions, which is easy to detect in an emulator to know that it is harmless to suspend emulation until an interrupt occurs.