Aphonlab.210
net.bugs.2bsd
utcsrgv!utzoo!decvax!ucbvax!ucsfcgl!sdcarl!sdcattb!sdcsvax!phonlab!donn
Tue Mar 9 03:50:07 1982
2.8 on the 11/34
Hello. I'm a novice kernel hacker who has taken on the job of
getting Berkeley 2.8 Unix running on a pair of PDP11/34s and I
have some technical questions about Unix's innards and 11/34
hardware. If you think small 11s are boring then feel free to
skip to the next message...
1) Speed. We are using one of our 11s as a single-user system to
which we've attached an Evans & Sutherland Picture System II
graphics unit. We have molecular modelling software for the PS2
that was developed under Version 6 and it seems to run fine under
V7, except that actual display manipulation runs some 5-10%
slower under V7 than under V6. (Thanks to Berkeley's big disk
blocks, database manipulation runs 10-45% faster.) I'm curious
about where the lost time has gone and what can be done about it.
One of the first things I noticed about Berkeley 2.8 is that
large 11s benefit from an "ed" script that turns calls to the
priority level functions "spl[0-7]" in the assembler output of
the kernel C compilation into actual SPL instructions. While the
11/34 has no SPL instruction, it can set priority with MFPS and
MTPS, instructions which are equivalent to a MOV with a source
(resp. destination) of the low byte of the processor status word.
>From my reading of the DEC Processor Handbook for PDP's, it
appears that a call to one of the "spl" routines should take some
25-30 mu-sec, whereas a corresponding MFPS and/or MTPS takes 4-7
mu-sec, a substantial saving. There are lots and lots of calls
to these functions, too; in the source for our currently config-
ured kernel I counted well over 100. I wrote a little C program
that takes "spl[0-7]" and "splx" calls in assembly language and
intelligently turns them into MFPS and MTPS instructions
(incidentally producing a net small saving in space). The kernel
I get from this post-processing boots and seems to run all right
(which is to say I booted it once and ran "fsck" with no ill
effects, but was too nervous to persevere). Has anyone out there
tried this already, or does anyone care to venture an opinion
about whether this is both safe and more efficient? I'm a little
suspicious of this change because if it works, why wasn't it done
before?
2) Time. I noticed that one difference from V6 in 2.8 is that
the priority of the clock routine in "clock.c" is (redundantly)
set to level 6 just before performing callouts, while in V6 it
gets set to level 5. I assume that this is done to block clock
interrupts, since I can't find anything else that interrupts at
that high a priority. The V6 code is written to be re-entrant,
so that a clock interrupt can occur while a previous clock inter-
rupt is still being serviced, with no harm done (as far as I can
tell). Berkeley 2.8 V7 locks out clock interrupts, except at
"lightning bolt" time after load metering is done. Thus a pretty
large amount of code is executed at level 6 at certain times: I
can visualize a clock interrupt being lost when (say) some code
somewhere else in the kernel sets priority level to 6 just before
a clock interrupt wants to arrive; then when the interrupt
finally does get serviced, it may have lots of callouts to do
followed by a lot of load metering to do (say that it's lightning
bolt time), so that by the time an "spl1" is done 34 milliseconds
have been spent at priority level 6... Does this seem reasonable
on an 11/34? And why do so many routines set priority to 6 to
block clock interrupts when if the priority is merely elevated to
1 then the clock routine does almost nothing significant but
decrement the callout timer? The change to the clock routine to
set priority to 6 is not commented, but there are remarks in e.g.
"bk.c" that indicate that this has something to do with clock
interrupt blocking in certain device drivers. The particular
comment in "bk.c" says that "dzrint" should not be executed at
clock interrupt time in certain places so "spl5"'s need to be
"spl6"'s, but the clock routine won't do any callouts at all if
the priority was elevated at interrupt time... What's this all
about? If I don't have any DZ's (I don't) can I change it back
to 5?
3) Size. The bane of nonseparate I/D. The 2.8 distribution
didn't come with "awk", a program I'm fond of using under 4.1 BSD
on our VAXen. I found "awk" source on the 2.8 prerelease tape,
and discovered that I needed "yacc" and "lex" to compile it.
Well, it turns out that the available flavors of "yacc" on the
prerelease tape (MEDIUM and HUGE) are rather too large for my
poor old 11/34; with some hacking I managed to scrunch "yacc"
down to about half of MEDIUM size, and it compiled. This SMALL
"yacc" was sufficient to compile a SMALL "lex", but neither of
these was capable of handling the parser and scanner of "awk"...
I succeeded in compiling a nonseparate I/D "awk" on an 11/44 and
brought it over to my 11/34, but most unfortunately it runs "out
of space in ALLOC" when presented with any but the most trivial
programs. Has anyone in netnews-land solved this problem with
compiling "awk" before (short of buying a bigger machine)?
4) PDP11 long integer brain damage. Our facility has bought and
is buying more VAXen, but we don't yet have enough cash to
replace our PDP11s (partly because of the way our users are
funded). One way to conserve resources and perhaps also to
implement inter-machine communication is to share disks among our
CPUs. We'd like to do this by dual-porting controllers.
Wouldn't it be nice if it were possible to have the same filesys-
tem structure on all our machines? I asked Bill Jolitz about
this at USENIX and he warned me that it would be a tough job,
because although the filesystem structures are superficially
similar, the PDP11 stores long integers the wrong way, with the
high order word at the low address, unlike a VAX. All the places
in the kernel where VAX long integers would be read in from disk
would have to be modified to flip the words into PDP11 order.
Well, I thought of a way to accomplish this indirectly. It turns
out that the most significant part of the funny word order on the
11s has to do with how they are loaded into registers (the high
order word takes the lower-numbered register); instructions like
ASHC, MUL and DIV can only operate on long quantities in regis-
ter. I have munged a version of the C compiler to put long
integers into register the way the PDP11 likes them but to keep
them in memory in the right (VAX) word order. The compiler seems
to work (cross my fingers) and I am about ready to start trying
out programs like "mkfs" to see if they do the right thing.
Before I sink too much more of my time into this, does anyone see
why this wouldn't do what I want?
Sorry for the long opus; I hope people find it interesting enough
to send me suggestions at ucbvax!sdcsvax!sdchema!donn or post
them to the newsgroup.
Donn Seeley
UC San Diego Chemistry Dept.
ucbvax!sdcsvax!phonlab!donn
ucbvax!sdcsvax!sdchema!fred!donn
etc.
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
of
http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.
