HP/DEC/Compaq

gxemul with ultrix

yesterday was a holiday here so i figured why not spending some time with ultrix :D
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
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 Image 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...
so you mean it using 100% all the time is how it is? :P
r-a-c.de
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 Image 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...
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.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
oh yeah very nice explanation, thanks :-)
r-a-c.de
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. :D
while (!asleep()) sheep++;
indeed that's good news :D
grabbed simh already and will give it a try ...
r-a-c.de
foetz wrote: indeed that's good news :D
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++;
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/[email protected] ... 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.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:
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.
:Indigo: R4000 :Indigo: R4000 :Indigo: R4000 :Indigo2: R4400 :Indigo2IMP: R4400 :Indigo2: R8000 :Indigo2IMP: R10000 :Indy: R4000PC :Indy: R4000SC :Indy: R4600 :Indy: R5000SC :O2: R5000 :O2: RM7000 :Octane: 2xR10000 :Octane: R12000 :O200: 2xR12000 :O200: - :O200: 2x2xR10000 :Fuel: R16000 :O3x0: 4xR16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...