values of β will give rise to dom!
This was noticed by some and is recorded in a WWW page or so, which are mostly copies of the same compilation of rarely encountered and striking error messages from various systems.
The actual source line in mv.c that produced the message was
write(1,"values of \016B\017 will give rise to dom!\n",37);
except that in the real source, the \016B\017 was written with literal ASCII SI and SO control characters. These shifted the Model 37 Teletype into its optional extended character set, and the B printed as the Greek letter beta. See below for more about rendering beta amidst changing hardware and software.
Like most of the messages recorded in these compilations, this one was produced in some situation that we considered unlikely or as result of abuse; the details don't matter. I'm recording why the phrase was selected.
The very first use of Unix in the "real business" of Bell Labs was to type and produce patent applications, and for a while in the early 1970s we had three typists busily typing away in the grotty lab on the sixth floor. One day someone came in and observed on the paper sticking out of one of the Teletypes, displayed in magnificent isolation, this ominous phrase:
values of β will give rise to dom!
It was of course obvious that the typist had interrupted a printout (generating the "!" from the ed editor) and moved up the paper, and that the context must have been something like "varying values of beta will give rise to domain wall movement" or some other fragment of a physically plausible patent application.
But the phrase itself was just so striking! Utterly meaningless, but it looks like what... a warning? What is "dom?"
At the same time, we were experimenting with text-to-voice software by Doug McIlroy and others, and of course the phrase was tried out with it. For whatever reason, its rendition of "give rise to dom!" accented the last word in a way that emphasized the phonetic similarity between "doom" and the first syllable of "dominance." It pronounced "beta" in the British style, "beeta." The entire occurrence became a small, shared treasure.
The phrase had to be recorded somewhere, and it was, in the v6 source. Most likely it was Bob Morris who did the deed, but it could just as easily have been Ken.
I hope that your browser reproduces the β as a Greek beta. It is written here as '& beta ;', which works on MSIE and at least some Linux browsers, but not on Netscape 4.6 (at least mine). Formerly I tried rendering it using 'fontface=symbol b /fontface' with the appropriate angle-brackets, which works on this old Netscape and MSIE, but not recent Mozillas. Sigh. If you are using an old Netscape, with an appropriate fontface, here it is: b.
Every now and then on Usenet or elsewhere I run across a reference to a certain comment in the source code of the Sixth Edition Unix operating system.
I've even been given two sweatshirts that quote it.
Most probably just heard about it, but those who saw it in the flesh either had Sixth Edition Unix (ca. 1975) or read the annotated version of this system by John Lions (which was republished in 1996: ISBN 1-57298-013-7, Peer-to-Peer Communications).
It's often quoted as a slur on the quantity or quality of the comments
in the Bell Labs research releases of Unix. Not an unfair
observation in general, I fear, but in this case unjustified.
The actual code and other commentary surrounding it were precisely this:
/*
* Switch to stack of the new process and set up
* his segmentation registers.
*/
retu(rp->p_addr);
sureg();
/*
* If the new process paused because it was
* swapped out, set the stack level to the last call
* to savu(u_ssav). This means that the return
* which is executed immediately after the call to aretu
* actually returns from the last routine which did
* the savu.
*
* You are not expected to understand this.
*/
if(rp->p_flag&SSWAP) {
rp->p_flag =& ~SSWAP;
aretu(u.u_ssav);
}
/*
* The value returned here has many subtle implications.
* See the newproc comments.
*/
return(1);
The real problem is that we didn't understand what was going on either. The savu/retu mechanism for doing process exchange was fundamentally broken because it depended on switching to a previous stack frame and executing function return code in a different procedure from the one that saved the earlier state. This worked on the PDP-11 because its compiler always used the same context-save mechanism; with the Interdata compiler, the procedure return code differed depending on which registers were saved.
So, for Steve Johnson and me, trying to move the kernel for the first time to a new machine, this code was indeed on the exam. It took about a week of agonizing before we finally convinced each other that the mechanism was wrong and no fiddling with the compiler was useful. We redid the coroutine control-passing primitives altogether, and this code section, and the comment, passed into history.
/
/ 32-bit multiplication routine for fixed pt hardware.
/ Implements * operator
/ Credit to an unknown author who slipped it under the door.
.globl lmul
.globl csv, cret
lmul:
jsr r5,csv
mov 6(r5),r2
sxt r1
sub 4(r5),r1
mov 10.(r5),r0
sxt r3
sub 8.(r5),r3
mul r0,r1
mul r2,r3
add r1,r3
mul r2,r0
sub r3,r0
jmp cret
But I'll carry this one on my conscience for a while.
The division routine included
1:
mov r4,-(sp)
clr r0
div r3,r0
mov r0,r4 /high quotient
mov r1,r0
mov r2,r1
div r3,r0
bvc 1f
sub r3,r0 / this is the clever part
div r3,r0
tst r1
sxt r1
add r1,r0 / cannot overflow!
1:
The spot on the soul is the "this is the clever part" comment.
Amos Shapir of nSOF (and of long memory!) just blackened (or widened) the spot a bit more in a mail message, to wit:
I gather the "almost" here is because this trick almost worked... It has a nasty bug which I had to find the hard way!
The "clever part" relies on the fact that if the "bvc 1f" is not taken, it means that the result could not fit in 16 bits; in that case the long value in r0,r1 is left unchanged. The bug is that this behavior is not documented; in later models (I found this on an 11/34) when the result does fit in 16 bits but not in 15 bits (that is, overflow for signed, but not unsigned types), the overflow bit is set, but the unsigned result does overwrite the original values -- which makes this routine provide very strange results!
Back around 1970-71,
Unix on the PDP-11/20 ran on hardware
that not only did not support virtual memory,
but didn't support any kind of hardware memory mapping or protection,
for example against writing over the kernel.
This was a pain,
because we were using the machine for multiple users.
When anyone was working on a program,
it was considered a courtesy to yell "A.OUT?" before trying it,
to warn others to save whatever they were editing.
1970-71 年頃、
PDP-11/20 の上の Unix では、
仮想記憶をサポートされていないだけではなく、
ハードウェアによるメモリのマッピングと保護が全くサポートされてない、
カーネルを書くのに不利なハードウェアの上で実行していました。
多数のユーザがマシンを使用していたので、
これは苦痛でした。
誰かがプログラムを実行する時には、
他の人間に編集中のものはなんでも保存するよう警告するために、
実行する前に「A.OUT」と叫ぶことが礼儀だとされていました。
[余談: ある時点では、
何人かがその当たりをうろついていましたので、
Bob Morris はほとんど会話調で "ld の引数は何だっけ？" などと尋ね、
誰かが彼に教えました。
思考が浸透し始めてもすぐに脳まで達しないので、
言い換えれば、十分に早くなかったので、
私たちはしばらくタイプし続けました。
手を離せる誰かの前のターミナルの反応が止まり、
「ちょっとまって Bob、何をしようとしている？」
と言います。]
We knew the PDP-11/45,
which did support memory mapping and protection
for the kernel and other processes,
was coming, but not instantly;
in anticipation,
we arranged with Digital Special Systems
to buy a PDP-11/20 with KS-11 add-on.
This was an extra system unit bolted to the processor
that made it distinguish kernel from user mode,
and provided a classical PDP-10 style "hi-seg" "low-seg" memory mapping unit.
I seem to recall that maybe 6 of these had been made when we ordered it.
私たちは
PDP-11/45 が
カーネルとその他のプロセスに使える
メモリのマッピングと保護をサポートしていることを知っていましたが、
それが到着しても、すぐには使えませんでいた。
私たちは前もって Digital Special Systems から
KS-11 を追加した PDP-11/20 を購入する手配をしていました。
これはユーザモードでカーネルを識別し、
古い PDP-10 スタイルの "hi-seg" "low-seg" メモリマッピング
ユニットを提供するための、
プロセッサに固定する追加システムユニットです。
私たちがこれを注文した時に、
恐らく６個作られたと思います。
Those who remember the early PDP-11s remember
that there were no multiply, divide, or shift-by-more-than-1 instructions,
and that they had an optional EAE ("extended arithmetic extension") gadget,
the KE-11A,
that appeared in physical memory in the I/O device space:
one stored the operands here and read back the answer there
(in fact at 777302 and following addresses).
初期の PDP-11 を知る人は
乗算、除算、１ビットより多いシフト演算がなく、
KE-11A というオプショナルの EAE (拡張算術演算拡張) という道具があって、
I/O デバイス空間に物理メモリが現れることを覚えているでしょう。
One problem the KS-11 had to deal with was
that ordinary programs needed to do multiplies and divides,
yet shouldn't be allowed to access the I/O device space.
So it included circuitry that detected just the EAE addresses,
and remapped them to physical,
while all other virtual addresses in user mode were mapped.
KS-11 を取り扱う上での１つの問題は掛け算や割算をする
普通のプログラムには I/O デバイス空間へのアクセスが許されなかったことです。
そのため、ユーザモードにあるその他の全ての仮想アドレスがマップされている間、
EAE アドレスを検出し、物理領域にマップし直す回路が含まれていました。
When we got the KS-11 machine, the EAE just didn't work at all.
With test programming,
we got bus errors, or no action from the EAE unit.
But, in those days
when you bought such things from Digital Special Systems,
you also got the circuit drawings,
so after a lot of headscratching and fiddling,
they were consulted.
私たちが KS-11 マシンを手に入れた時、
EAE は全く動きませんでした。
テストプログラムにより、バスエラーが発生し、
EAE ユニットは何も動いていないことがわかりました。
しかしその当時は、
そのようなものを Digital Special Systems から購入した場合、
回路図も手に入れることができました。
頭を掻きながら時間を浪費した後、
アドバイスを得ました。
It turned out that
on one page of the drawings,
there was an address comparator for the EAE address,
with an out-of-page arrow labelled "EAE ADDRESS DETECTED H".
On another page, there was an in-arrow labelled "EAE ADDRESS DETECTED L".
We couldn't find anything between these.
回路図のあるページには EAE アドレスのためのアドレスコンパレータがあり、
ページの枠外に "EAE ADDRESS DETECTED H" というラベルに
矢印が向けられているが判明しました。
別のページでは "EAE ADDRESS DETECTED L" というラベルからの矢印がありました。
私たちは両者の関係について何も見つけられませんでした。
In the end,
we had a visit from an embarrassed Digital Special Systems
guy who found an unused inverter pin and added some white wires.
結局、
私たちは困惑している Digital Special Systems の人間を訪問し、
使ってないインバータのピンを見つけ、
白い線を追加してもらいました。
These days, such a problem would be harder to fix in the field.
その当時、
このような問題をフィールドで
解決するのは難しかったでしょう。