SIMHのPDP-11エミュレータのメモリ参照は、16bitアドレス? 18bitアドレス? 22bitアドレス?

SIMHのPDP-11エミュレータを利用し、PDP-11/40上で動作するUNIXv6について学ぼうと考えています。まずは「m40.s」のラベル「start」から起動するプロセスを見ていこうと思います。ここではMMUが無効になっていますが、管理レジスタを設定し、MMUを有効にするための準備をおこないます。

 

「mov    $77406,(r1)+」のような箇所でMMUのレジスタに値を設定しています。ここでR1には「KISD0」が入っており、具体的には「172300」です。これは16bitアドレスとしての表現です。PDP-11/40のメモリ管理装置である「KT11-D」では、マニュアルの「Table 3-1 PAR/PDR Address Assignments」において「772300」のように定義されています。これは18bitアドレスです。ところがSIMHのPDP-11エミュレータでは、「17772300」のような22bitアドレスで参照しなければならないようなのです。

 

デバッガ機能を利用してメモリを参照した例を以下に示します。このように、16bitや18bitアドレスではMMUレジスタを参照できず、22bitアドレスで参照すると、格納されている値が参照できます。

Step expired, PC: 003370 (MOV #77406,(R1)+)
sim> s
Step expired, PC: 003374 (ADD R4,R2)
sim> e R1
R1:     172302
sim> e 172300
172300: 000000
sim> e 772300
772300: 000000
sim> e 17772300
17772300:       077406 

 

ちなみに、CPUは次のように定義しています。

sim> sh cpu
CPU, 11/40, NOFIS, idle enabled, stability wait = 20s, autoconfiguration enabled, 256KB 

エミュレーションするモデルを11/70としているのであれば、22bitアドレスでも納得するところです。しかし11/40として設定しているはずなの、22bitアドレスなのは、ちょっと不可解です。ただしSIMHが、そのような挙動なのは、そうなのですから、それを受け入れるしかありません。

外部セキュリティーキーは「パスキー対応」で使えないのだろうか

2026年4月14日に「Yahoo! JAPAN ID、安全性・利便性向上を目的としてログイン方法を「パスキー」に一本化へ」という発表がありました。Yahoo以外でも、ログイン時にパスキーが使えるというサイトは増えている印象です。

 

普段使用しているWindows11のデスクトップPCには、スマホのような生体認証デバイスがありません。どうしたら良いのかと悩んでいたら、USBポートで使える「外部セキュリティーキー」というものがあるようです。Amazonで調べると、値段が高いものも安いものもあり、何がどう違うのか分からないので、Geminiに相談してみました。安いのでも構わないだろうと判断し、TrustKeyのT110を購入しました。Geminiからバックアップ用も必要とのアドバイスを得たので、2つあります。

 

さっそく幾つかのサイトでログインでパスキー認証をするように設定してみましたが、うまくいっているようです。ところが、サイトによっては、使用環境が厳しいところがあり、WindowsではEdgeかChromeと明記され、Firefoxが対象外になっている場合があります。対象外でも実は大丈夫ではないかと試してみましたが、エラーになってしまいました。

 

EdgeかChromeなら良いとあるので、Chromeで試してみたところ、パスキーの登録先を外部セキュリティーキーにしたら、やはりエラーになってしまいました。そのサイトではエラーになった場合の対処方法として、「何度か試してみる」とか、「キャッシュをクリアする」などが書かれているので、何度か試してみましたが、全くうまくいきません。Geminiに「キャッシュをクリアする」のは有効だろうかと質問してみましたが、それでうまくいく可能性は低いとの回答を得ました。Geminiの推測によれば、サイト側で「外部セキュリティーキー」や「Firefox」を対象外としてロジックを組んでいるのではないかとことです。

 

できれば「外部セキュリティーキー」を使用し、「Firefox」でパスキーの登録ができるようになってもらえるとありがたいのですが。そうでないままに、「ログイン方法をパスキーに一本化」されるのは、とても困ります。 

またしてもGNUSでサマリー表示が「[nobody](1970-01-01 09:00)(none)」になった

メールを読む環境はFreeBSD/amd64上に構築しています。プロバイダからfetchmailでローカルに取り込み、procmailで振分け、GNUSで読んでいます。GNUSサマリー表示が「[nobody](1970-01-01 09:00)(none)」になってしまうのは気がついていましたが、最近になってGeminiに相談して、解決に至ったと思っていました。

 

ところが、再び同様の現象になりました。若干違うのは、全く同様の現象のメールと、日付だけは正しく表示されるメールがあることです。再びGeminiに助けを求めました。こちらから情報を提供し、Geminiからは、あれを確認しろとか、これを設定してみろとか指示が飛びます。基本的にはGeminiの指示に従うのですが、方向性が解決から逸れているんじゃないかと思うところもあり、軌道修正を図ります。Gemini（というか生成AI一般に）との向き合い方は、一方的に妄信するのではなく、こちらも相応の技術背景を持ったうえで、対話に臨む必要があると感じます。

 

閑話休題。今回の問題メールは、なんとGoogleが発信元なのです。結論として、Googleが送信時に付加する「X-」で始まるヘッダに問題がありそうだということになりました。ローカルに持ってきた問題メールをエディタで編集し、「X-」のヘッダを全て削除したところ、サマリー表示が正常になるのを確認しました。

 

まさかGoogleが送ってきたメールなのにと思わないでもありません。Geminiに言わせれば、（本当かどうかわかりませんが）、GNUSはヘッダの解釈が厳密で、Googleが送信するメールも完璧ではないので、こういうこともあり得るとのことでした。少なくともこちらでできることはないので、Google側が何とかしてくれる（そもそも気づいているのか）のを待ちたいと思います。 

TiddlyWikiｇ 5.4.0がリリースされたけど・・・

TiddlyWiki 5.4.0が2026年4月21日にリリースされました。新しいバージョンがリリースされると、いつも手持ちのTW5ファイルを更新しているのですが、今回は控えようと思います。いつも利用しているTW5ファイルを更新したら不具合が出たからです。

 

TW5ファイルは、基本的にはWindows11上のFirefoxで利用しています。あまり凝ったことはしていませんが、「Calendar - a simple calendar macro」というプラグインを入れています。これが動かなくなりました。具体的には「<」や「>」で前後の月に移動できなくなりました。TW5.3.8なら問題なかったのです。

 

またNetBSD/i386 9.0上のFirefox 52.9.0では、Internal Errorが表示され、全く動きません。「TypeError: result.mqList.addEventListener is not a function」というメッセージが出ています。Firefoxのバージョンが旧いですが、NetBSD/i386で動作するFirefoxは、これしかないのです。しかもTW5.3.8では問題なかったのです。

 

TW5.4.0がリリースされたばかりなので、もしかすると近日中にTW5.4.1が出るかもしれません（出ないかもしれませんが）。手持ちのTW5ファイルが数多くあるのですが、更新は当面見合わせるつもりです。

GNUSでサマリーが「[nobody](1970-01-01 09:00)(none)」と表示される

メールをFreeBSD/amd64上で管理しています。プロバイダに届いたメールを、fetchmailで取り込み、procmailで振分け、Emacs上のGNUSで読んでいます。Emacsでメールを扱うのは昔からで、元々はWonderlustを使っていましたが、十数年前にGNUSに変更しました。しかし送信の設定ができていないので、メールを送る時はmew（もしくはWindows11上のThunderbird）を使っています。

 

最近（と言っても数年たっていますが）になって、GNUSのサマリーモードで表示が「[nobody](1970-01-01 09:00)(none)」となるメールがあるのに気付きました。すべてそうなるわけではなく、送信者、送信時刻、サブジェクトが表示されているものもあります。以前はこんなことにならなかったので、てっきりGNUSのバグだと思っていました。そのうち直るだろうと高をくくっていました。それなのに、いつまでたっても直らず、そもそもGNUSを使っている人がいないんじゃないか、だから直らないんじゃないかと、あらぬ疑いをかけていました。

いつまで待っても修正されないならば、自分で対処しようと思いましたが、Emacs Lispは不慣れですので、Geminiにお願いしようと考え、Geminiに相談を持ち掛けました。いきなりEmacs Lispについて相談したわけではなく、GNUSの現象を示して回答を求めたのですが、なんとGNUSの問題ではなく、fetchmailかprocmailが怪しいとの診断が出ました。

Geminiとの対話を繰り返した結果、設定ファイル「~/.fetchmailrc」の中で「mda "/usr/local/bin/procmail -f- -d %T"」とある「-f-」が原因ではないかというのがGeminiの見立てでした。procmailのオプション「-f-」というのは、PROCMAIL(1)によれば、「If fromwhom consists merely of a single `-', then procmail will only update the timestamp on the `From ' line (if present, if not, it will generate a new one).」と書かれています。このオプションが指定されていることで、メールの先頭にある「From」の次に「>From」という行が生成されてしまうようなのです。このような行があると、GNUSがメールヘッダをハンドリングしようとして失敗するので「[nobody](1970-01-01 09:00)(none)」となってしまうようです。

 

若干疑問なのは、届いたメールは全てprocmailを通すので、全メールが「>From」のようになっています。それでもサマリーモードが問題なく表示されるものもあるのです。この点についてGeminiに尋ねたら、何か説明してくれましたが、読み飛ばしてしまいました。

 

ちなみにmewを使った場合、サマリーモードでも全く問題ありませんでした。

PDP-11のハードウェアTRAPにおけるモデル差異

PDP-11/40で動作するUNIXv6を、Lions本を頼りに学んでみようと考えています。まず手始めに「low.s」を調べています。この中でトラップベクタが定義されていますが、PDP-11のモデルによって違いがあるのではないかと気になりました。カーネルの動作環境は、SIMHのPDP-11エミュレータを使用するつもりですが、PDP-11/40を想定しています。しかし、PDP-11/45とかPDP-11/70という環境を考えることも、できなくはありません。PDP-11のモデルは他にもありますが、まずは11/40、11/45、11/70を考えると、モデルによる差異はどうなっているのでしょうか。

 

調査した資料は、PDP-11/40、11/45、11/70の『Processor Handbook』です。

 

まず、4番地から34番地にある7つのTRAPは、どのモデルにも存在します。また240番地と244番地の2つのTRAPも、どのモデルにもあります。しかし250番地のTRAPは、PDP-11/45、11/70にしかないようですし、114番地のTRAPは、PDP-11/70だけにしか存在しません。「low.s」では、これらのTRAPが全て定義されていますが、定義されていても別に無駄にはならないので、問題ではないのでしょう。

 

また各トラップベクタでは「trap; br7+5」のように記述されています。PDP-11のトラップベクタは、2ワード(4バイト)で構成されており、第1ワードが飛び先アドレス、第2ワードがPSWです。そして「br7」というのは割り込みのプライオリティを示していますが「+5」は何でしょうか。「low.s」の中では「br7+0」から「br7+9」まであります。

 

「trap」とは、「m40.s」の中にあるラベル「trap」のことで、Lions本の0755行にあります。この中で更に制御が移り、「trap.c」の「trap()」が呼ばれます。これはLions本の2693行にあります。ここで「+5」などを処理するために、switch-caseがあります。ただし「br7+4」と「br7+7」に相当するcase文はありません。これらはdefault文で処理されることになります。

 

しかも「low.s」には「br7+7」となっているトラップベクタが2つあります。Lions本の0538行と0547行です。これらは、「trap()」でも対応するロジックがありませんから、UNIXv6としては、未対応で十分という判断なのだと思います。今回UNIXv6のカーネルを学ぶに際しても、それ以上の調査は行いません。ただし将来的には、これらのTRAPの扱いがどうなっているのか、調べてみたい気がします。UNIXv7とかBSD2.11などでは、改良されているのでしょうか。それとも手付かずのままなのでしょうか。 

「4」とは？

PDP-11/40で動作するUNIXv6を学び始めました。カーネルを学ぶ入口は様々かと思いますが、まずは起動する過程を追いかけていこうと考えています。参考書はLions本で、オンラインで参照できる様々な資料も使います。実行環境は、実機があればよかったのですが（よくない？）、SIMHのPDP11エミュレータを使います。

 

カーネルの0番地に関連するのは、「low.s」です。Lions本では500行から599行までです。508行の0番地には「br 1f」があり、522行には「1: jmp start」があるので、カーネルの起動処理は、実質的には「start」から始まっているようです。

 

ここで509行目に目を移すと「4」とあります。これは何でしょうか？PDP-11の命令ではないし、疑似命令でもありません。何かの定数宣言でもなさそうですし、コメントが入っていないので、意図も分かりません。

 

『PDP-11/40 processor handbook』の「APPENDIX B MEMORY MAP」 には「INTERRUPT VECTORS」として、0番地から300番地あたりまでに定義されている割り込みベクターが記載されています。これらは、2ワード(4バイト)を組みとして、第1ワードが飛び先アドレス、第2ワードがPSWの設定内容となっています。ただし0番地は「RESERVED」となっているため、ここが割り込みベクターとはなっていないし、実際に「br 1f」という命令が置かれているわけです。仮に割り込みベクターと考えたとしたら、PSWが入るはずの場所に「4」があるわけですが、そもそも割り込みベクターではないので、PSWに設定する値ではないはずです。

 

「low.s」では、512行から「trap; br7+0」のように、PDP-11/40が定義した割り込みベクターが並んでいます。これらは4番地から始まるので、0番地の「br 1f」だけでは番地がずれてしまうので、何か埋め草が必要です。それが「4」のように見えるのです。

 

この「4」には、何か意味があるのでしょうか。「0」でも構わないのではないでしょうか。もしくは「4」を記述せずに、「. = 4^.」を明示した方が良かったのではないでしょうか。この疑問には答えがありません。強いて言えば開発者本人に聞くしかありませんが、もう60年くらい前のことですし、強いて思い出してもらわなければならないほど重要な問題でもありません。