[Simh] SIMH performance

[Michael Bloom]

On 03/05/2012 06:30 AM, Mark Pizzolato - Info Comm wrote:
> Comments in the pdp11_cpu code suggest that Bob added Idle support. 
> I'm not a pdp11 user so I don't have direct experience there, but I 
> suspect he probably didn't test with 2.11BSD. Please suggest what 
> might be appropriate for this operating system....

The 2.11BSD idle routine sets priority to zero,  issues a wait 
instruction, then restores the original priority. (**1)

So the appropriate thing would be for the CPU to just do nothing until 
interrupted.

(and as I write that last sentence, I see your points more clearly than 
ever.  (Even though the "wait" is supposed to do "nothing" until 
interrupted,  the device interrupting it is not atomic from it's own 
viewpoint.  It has a lot of work to do to in preparation for generating 
the interrupt! . . . so it is actually that the simulated device(s) 
needs a way to idle efficiently until it has work to do) )

Once again, on a tangent . . .

I think that PDP-11 implementors might find 2.11BSD to be a useful tool, 
if they were to start using it, as it exercises the PDP-11 in ways that 
other systems either don't exercise,  or it does so without source code, 
the latter making it harder to ascertain whether a problem is in the 
kernel or in the "hardware".

One example might be that networking runs in supervisor mode(**2), in 
contrast some with other PDP-11 operating systems which use the mode to 
support larger user programs.

That may involve much different usage patterns than, say RSX-11M when a 
user mode program utilizes a supervisor mode library written and 
compiled by the programmer at the same time as the main program

As another example,  both the kernel and any user mode program may each 
have up to 15 overlays.  Programs too large for split I/D can be built 
with overlays & there is now an optimizing overlay makefile generator, 
"mkovmake", which helps to make overlays be nearly transparent to user 
programs.(**3)  Here again,  if there was some obscure bug with 
simulating a segment register,  having the 2.11BSD source can make it 
easier to distinguish what the PDP11 is actually doing with that 
register from what the kernel code intends for it to do.

- Michael

Notes:
(**1) "Just for amusement" and for the benefit of models with a front 
panel,  the idle routine also rotates a bit pattern on the front panel 
lights once every few times it is called.  A comment in the code reads: 
" /* If the system is very active the display  will appear blurred. */  
".   SIMH coderd shouldn't care about that, which is why I moved it to 
down to a note..

(**2) Moving the network from kernel space to supervisor freed up a lot 
of room for making the system look more like 4.3BSD.  So much stuff 
ranging from kernel internals and aspects of the filesystem to the 
system call API to the C library and user mode programs has been brought 
over or ported from 4.3BSD, that, except for the limitations imposed by 
the word size, it really does look like a 4.3BSD systrm. Programs 
cross-port very easily between 4.3BSD and 2.9 BSD.  The only real coding 
issues  occur when the coder assumes int to be 32 bits.  The usual 
problems of this type occur when man pages are ignored (for example, the 
coder uses passes an int rather than an off_t as the second argument to 
lseek() )

(**3) As an example of"near transparency":
2.11BSD comes with the source to the game "rogue".  When I tried to 
build it, I got a "text overflow" message from ld.   After a very little 
digging,  I discovered "mkovmake".  I ran it, following the mkovmake man 
page, and was given a new Ovmakefile that built a binary with eight 
overlays.
I started it up, and immediately ran into what I thought was a Kobold 
(letter K) and found that it was now called a "Kestrel".

    size rogue
    text    data    bss     dec     hex
    25856   18384   10556   54796   d60c    total text: 88192
    <<-------------
             overlays: 8192,7936,7936,8192,7552,7488,6976,8064

Note that this is a pdp11 binary with an 88192 text size.

Just for the hell of it, here's the kernel, using a total 108288 of text:

    size /unix
    text    data    bss     dec     hex
    55424   6340    41960   103724  1952c   total text: 108288
             overlays: 7744,7488,7872,7296,2240,7104,4992,5696,2432

That is without networking. The kernel separately loads  /netnix to 
supervisor space:

    size /netnix
    text    data    bss     dec     hex
    60864   2362    38448   101674  18d2a




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20120307/51d7c680/attachment-0002.html>