Chapter 11. x86 Assembly Language Programming(FreeBSD)やnetbsd assembly(NetBSD)を読めば良いよね、ではあるのですが。

int 0x80を行う際のスタックの状況が、以下のようになっている必要があるという点に注意が必要です。

esp + 0x00の「任意」というのが曲者で。分かってしまえば簡単なのですが…

• 引数を積んだ後eaxレジスタにファンクション番号をセットし、int 0x80を呼び出すだけのサブルーチン(syscall)をcall syscallで呼ぶ
• 引数を積んだ後にさらにダミーの引数を一つ積み、eaxレジスタにファンクション番号をセットしてint 0x80を呼ぶ

単に引数を積むだけでは動かない、という罠に引っかかっておりました。あと、よく分からないのですがretだけのコードだとSegmentation Faultを起こすので、プログラムの終了はきちんとexitを呼び出さないとダメなんですよね。何故なんだろう…

とりあえずNetBSD, FreeBSDではアセンブラでHello, world!できたので、コード置いときます（OpenBSDでは「ld: error: relocation R_386_32 cannot be used against local symbol; recompile with -fPIC」と言われてリンクできなかったので、放置します）。

なお、Linuxの場合はスタックに積まずレジスタ越しにパラメータを渡すので、これも注意が必要です。56.4kg(23:20)

三総通三海通の公式回答が出ているので、早速答え合わせ。法規93/100、英語101/105なので、電気通信術が失敗しているとか、豪快にマークミスをしていなければ合格できるのかも。

・法規A問題

A-3 「船舶の航海船橋に通常設置する無線設備には、その(A)筐体の見やすい箇所に、当該設備の発する磁界が(B)磁気羅針儀の機能に(C)障害を与えない最小の距離を明示しなければならない。」を答えさせる問題。正解の選択肢は4番ですが、迷った挙句3番の(A)設備の外部・(B)他の電気的設備・(C)障害を与えない最小の距離を選んでしまい、不正解。

・法規B問題

B-3 オ「海岸局は、船舶局がデジタル選択呼出装置を使用して送信した遭難警報又は遭難警報の中継を受信した場合においては、当該遭難警報又は遭難警報の中継を受信した周波数と関連する無線局運用規則第70条の2（使用電波）第1項第2号に規定する周波数で聴取を行わなければならない」が正(1)か否(2)かを問う問題。正解は1。おそらく、聴取はともかくまずは海上保安庁に連絡なんじゃね？みたいな理由で2を選んだのだと思います。

B-5 イ「無線局の通信の相手方、通信事項又は無線設備の設置場所の変更の命令を受けた免許人は、その命令に関わる措置を講じたときは、速やかに、その旨を総務大臣に報告しなければならない。」が正(1)か否(2)かを問う問題。正解は2。変更の命令を受けたらそりゃあ対処しましたって報告はするでしょ普通？と思って1を選びましたが、そもそも

• 免許人は、無線局の目的、通信の相手方、通信事項、放送事項、放送区域、無線設備の設置場所若しくは第六条第二項第六号に掲げる事項の変更（総務省令で定める軽微な事項を除く。）をし、又は無線設備の変更の工事をしようとするときは、あらかじめ総務大臣の許可を受けなければならない。（電波法第十七条第一項）
• 総務大臣は、免許人又は第八条の予備免許を受けた者が識別信号、電波の型式、周波数、空中線電力又は運用許容時間の指定の変更を申請した場合において、混信の除去その他必要があると認めるときは、その指定を変更することができる。（電波法十九条）
• 総務大臣は、電波の規整その他公益上必要があるときは、無線局の目的の遂行に支障を及ぼさない範囲内に限り、当該無線局（登録局を除く。）の周波数若しくは空中線電力の指定を変更し、又は登録局の周波数若しくは空中線電力若しくは人工衛星局の無線設備の設置場所の変更を命ずることができる。（電波法第七十一条第一項）

ということで、「総務大臣は通信の相手方、通信事項、無線設備の設置場所の変更を命令しない」ため、設問の答えは2になります。

・英会話と英語A問題（英文解釈）

なんとここは全て正答していたので、書くことがありません。

・英語B問題（和文英訳）

B-1 日本の海運会社が、東京の造船所で建造中のLNG燃料フェリーの命名・進水式を行った。進水時には同じくLNG燃料を使うタグボートが曳航作業を支援した。その会社は、カーボンニュートラル社会の先駆けとして低炭素燃料であるLNGの利用促進に熱心である。

→A Japanese shipping company has (ア)held the naming and launching celemony for an LNG-fueled ferry (イ)under construction at a shipbuilder in Tokyo. A tugboat, also fueled by LNG, assisted with (ウ)towing operations during the launch. The company is eager to (エ)promote the use of LNG, a low-carbon fuel, as a (オ)pioneer of a carbon-neutral society.

(エ)、promoteなんですよね…emphasizeをなぜか選んじゃいまして。

B-3 船舶局の開局中、当直の無線通信士は、一般通信を行うことが見込まれる海岸局の通信圏に入る時、そしてそこを離れ次第すぐに航行報告(TR)を送信し、さらに船長の指示に従って船位通報を送信すべきである。

→While the ship station is open, the radio operator (ア)on watch should send a traffic report when entering and (ア)on leaving the service area of a coast station from which general communications might be (イ)expected and transmit reports to ship reporting systems in (ウ)accordance with the (エ)instructions of the (オ)master.

(オ)、なーぜofficer選んじゃったかなあ。船長はcaptainかmasterなのに。

法規は対策してもこの程度、英語は運良くここまで取れた（しかし次があったら同じように得点できると思うなよ？）、という評価でしょうか。とりあえず、9月期を受けずに済むようお祈りしておきます。56.3kg(23:05)

29-Mar-2025補足：三海通と書くべきところを三総通と書いてしまっていたので、直しました。ここまで来たら、総通を目指さないとだめなのでしょうか？（実際、三海通の法規と英語をもうちょっと頑張って、地理を覚えて死ぬ気で欧文・和文電信に取りかかれば見えそうな気がしています…気のせいかもしれませんが）

シンプルなエレキーの製作記事（キーイングの極性を問わず、省電力をウリとしていた、両面基板を用いるもの）をいつか作るぞ、と思っていたのですがその記事をどこかへやってしまったようです。一体どんなものだったっけ…？と適当に検索をしてみると、JO1LZXさんの過去に製作した事がある幾つかのエレキーおよびエレキー回路の歴史・その2がヒントになり、おそらくTed Theroux(N9BQ)考案の"A Digital CMOS Iambic Keyer"の派生で、キーイング部分をプラス/マイナスキーイング両対応に改変したものではないかと想像しています。

エレキー、現在はCMOSロジックICを使って組むよりもワンチップマイコンで実装する方が安価ですし、様々な付加機能を容易に実現することも可能です。しかし、技術の源流に近いものに触れたことが未だに無いので、恥ずかしながら「そもそもエレキーとは一体どういう動きをするものなのか」が分かりません（「和文電信の受信試験をパスした世代の1アマがこれでは何とも情けない」というお叱りを受けそう…和文どころか欧文電信の受信すら、今はとっても怪しいんですけどね！）。

そういえばCurtis 8044シリーズのキーヤーICというものも歴史にはあり、これも触れてみる必要のあるものの一つに今後はなるのかもしれませんが…2018年にチップの開発者は死去しており、チップ自体もとうの昔に製造中止になっているというのが現状のようで。2010年の時点で入手に困っているなんて話が掲示板に出ているのを見るに、これよりも前の時点で製造は止まっていたのでしょう。掲示板ではK1EL Systemsを訪ねると良い、という話があり、こちらは今でも（8044系ではないがワンチップのキーヤーICを）販売しているようですが。

ワンチップキーヤーの話は置いといて、N9BQキーヤーを作るにしても基板を起こすという面倒な作業があります。ありがたいことに、PCBWayのshare projectにそのものズバリの基板があるのでこれを使ってみることにします。最小発注量が5枚…そんなに要らないとしても、無ければ何も始まらないのでとりあえず発注してしまいました。

CMOSロジックIC(4001, 4011, 4027)はともかく、キーイング部分の三つのトランジスタの入手(2N4124, MPSA92, 92PU10)が厄介そうです。全く同じ物を購入することはまだ可能そうですし、実際MPSA92は若松通商で入手済みですが、2N4124はmouserやDigiKeyで入手できるにしても送料がやたらと高く、92PU10に至ってはeBayくらいしか手段が無さそうです。

これらを入手性の良い部品で代替することはできないものでしょうか。とりあえず、

2N4124

データシートにはGeneral Purpose Transistorsと銘打ってるので、2SC1815辺りの類で対応できそうな気がするのですが、ピン配置が違うとなると…2N3904と2N3906を買ってみたを参考に、秋月電子で2N3904辺り？

92PU10

単体のデータシートは無いようですが、データブックにはMedium Powerというカテゴリに掲載されており、P_C=0.75W, V_CEO=300Vという点を考慮する必要があります。秋月電子にはMPSA42がありますね。

ピン配列がなるべく同じで、h_FEが大きくかけ離れておらず、各種定格（V_CEOやI_C, P_C）が下回らなければ何を使っても動くんじゃないかなとゆっるーく考えているのですが、どうなんでしょうかねえ。ピン配置については届いた基板を見てから判断しても良いかもしれません。57.0kg(23:50)

31-Mar-2025補足：そのものズバリの基板、シルク面とパターン面の画像を合成して回路図と比較してみましたが…トランジスタはすべてEBCのピン配置です（型番面が見える状態において）。2N4124→2N3904, 92PU10→MPSA42、試してみる価値はありそうです。

英語、海通の問題だけでは足りない気がするので、一総通の問題を覗いてみました。過去3年分（令和4年3月期〜令和6年9月期）の問題を見比べてみましたが…これでは足しになりません。

• 長文読解(A-1〜A-5)は同一
• 無線通信業務に関する国際文書の規定文の解釈(A-6〜A-9)はA-9のみ異なる (5点×1)
• 和文英訳(B-1〜B-3)はB-3のみ異なる (2点×5)
• 英会話(Q-1〜Q-7)は共通

海通は当然海上関係の業務に特化されている一方で、一総通は航空関係の業務も含むため、A-9とB-3で違いを出していると思われます。英会話が共通になっている（英会話では航空に関する問題は出ない）のと、A-9/B-3の15点分を捨てても90点は取れる（これでも合格ラインの60点は超える）ので、三海通の英語がちゃんとできるなら一総通の英語もクリアできるという話は確かそうです。

昨日行われた三海通の英語、長文読解をgenspark.ai上のGPT-4oに食わせる際に間違ってGoogleに食わせてしまったところ、これは元ネタがありそうだということが分かりました。ということは、過去問の元ネタ、どういう領域から拾ってきているかが分かれば何かが見える…？ということで、ちょっと調べてみました。

(※)AP Newsの記事はWestern states will not lose as much Colorado River water in 2024, despite long-term challengesになりますが、試験問題の内容とだいぶ異なっているためにThe Denver Postに配信されたものを引いています。

こうして列挙してみると、三つの特徴がありますね。

• ソースはAP News
• 海洋・水産系の話題が多い
• 試験実施時期からそんなに離れていない（1〜2年以内）

AP(Associated Press)が扱うニュースは多いため、出題者が配信先というフィルタを通して問題のネタとする記事を絞り込む可能性があり、どこの配信先から得ているかが分かればより効果的な対策が行える気がします。とはいえ、これについてはあまりこだわらず素直にAP Newsを見る方が良いかもしれません。

和文英訳の一問と無線通信業務に関する（中略）の解釈については法規にある範囲…海通なら無線通信規則(RR)・SOLAS条約・STCW条約・SAR条約で、さらに一総通ではICAO条約が追加されます。法規の科目を（日本語で）しっかり勉強しながら、対応する英単語を覚えていく感じになるのでしょうか。和文英訳の残りの三問に関しても何らかの元ネタがありそうな気はしますが、これを調べるのはちょっと厳しそうですね…56.1kg(23:10)

26-Mar-2025補足：AP Newsの記事は、13-Jun-2023辺りから記事タイトルの前にカテゴリ（ClimateやU.S. Newsなど）が付き、HTML内ではgtm-dataLayer変数でprimary_sectionが記述されるようになっています（これより前の記事においては、primary_sectionがなくsecondary_sectionsしかありません）。時期に関わらずtag_arrayは使われているので、これに列挙されたタグの一番最後に書かれている項目を備考欄に追記します。

こうして見てみると、圧倒的にClimate（Science内のサブカテゴリ）が多いです。次点はU.S. News。BusinessおよびそのサブカテゴリTechnologyの記事も目を通すと良いかもしれません。

20日に法規、21日に英語/電気通信術、受けてきました。英語は9月期に回すはずだったのですが、「素の実力を知ることが大事なんじゃないんですか？」という妻の一言により受験することに。ほんとにノー勉（全く勉強してない状態）、こんな状態で挑みたくはなかったです。玉砕すればものすごくヘコみますし、万全の準備をしてから受ける方が安心…合格するかしないかのギリギリのスリルを楽しむような趣味は持っていません。

電気通信術、電話の送話/受話と直接印刷電信、そんなに難しくないだろうと思いきや、意外に足をすくわれる部分があるのでメモしておきます。

受話、練習の定番である無線電話練習用CD（欧文）よりも若干速かったです。ちゃんと比較はしていませんが、練習用CD×1.1〜×1.2の速度という印象です。送話の練習は練習用CDで受話の答え合わせをする際に読み上げれば良いとしても、本番は他の受験者の送話が聞こえる状態で自分もやらないといけないので結構混乱します。送話前に問題用紙を読む時間が十分に与えられるので、よく確認してから「始めます 本文」（本文、の後から時間計測を始めます）で読み始めれば良いのではないでしょうか。読み終わった後の「終わり」も忘れずに。

直接印刷電信、試験用のPCの脇に置いてある電文を入力するというものです。電文は練習用と試験用があり（表裏になっている）、どちらも全て大文字、空白は△、改行は↵で示されています。入力の際は自動的に大文字で入力されるので、Caps Lockを操作するだのShiftを押しっぱなしだのをする必要は無いです。タイプミスをしてもベル（ということにしておきます）が鳴り、正しいキーを押すまでは進みません。Backspace等で修正する必要は無いですし、電話や電信のように減点対象にはならないので遠慮せずとにかくがしがし打って制限時間内に入力を完了させれば良いです。

練習用の電文はTHE QUICK BROWN FOXなアレと0〜9の数字、()=+-:,.辺りの記号だったと記憶しています。試験用の電文は、NAVTEXで流れているようなものです（ZCZCは無かったものの、NNNNで終わっていました）。後述の理由により、いくらタイピングに自信があっても、練習用の電文を入力してから試験本番に挑むことを勧めます。

自分の場合、案の定（いわゆるjp106キーボード）であるという点が自分にとって厄介ですという問題に引っかかっただけでなく、ノートPC特有のキー配列に悩まされました。試験用PCはNECのLAVIEを使っていたようですが（LAVIE Directの類？）、キーの配列が[？][＿][↑][Shift]となっており、右Shiftと思って上カーソルキーを押してしまうためにいくら頑張っても記号が全く入力できないことが練習時にありました。また、日頃小文字で入力することに慣れている身だと、大文字を見た途端どうしてもShiftを押したくなります。とにかく、キー配列を確認するためにも練習は省略しない方が良い、と記しておきます。

電気通信術の試験全体の流れとしては、受話→直接印刷電信→送話の順で、受話は一斉、それ以外は受験番号順に呼ばれて試験を行います。試験申請の受付開始と同時に申請を出したので割と最初の方に呼ばれたのですが、受験番号が後になればなるほど待たされることになると思います。

さて、どういう結果になるんでしょうかね。発表の日まで全く落ち着きません。55.9kg(24:30)

大晦日の深夜に申請しちゃった三海通の試験、20日に工学/法規、21日に英語/電気通信術ということで…もうそんな時期なのかと。工学は一陸技による免除を使い、英語は次回以降とするにしても、残った二科目がどちらも難しい。

電気通信術、受話はともかく送話は正しいNATOフォネティックコードを言えば良いだけとはいえアマチュア無線上がりだとItaly（正しくはIndia）だのJapan（正しくはJuliet）だのといった正しくない言い回しをうっかり言いそうになるのが非常に怖いです。直接印刷電信は普段キーボードに触れて文字を入力していれば何とかなるらしいですが、電気通信術の試験方法にある鍵盤配列は、日本工業規格（Ｘ6002）「情報処理系けん盤配列」によるもの（いわゆるjp106キーボード）であるという点が自分にとって厄介です。仕事場ではjp106、家ではus101なので対応はできると思いますが…多分できるんじゃないかなあ、記号類の入力が試験に出てこないことを祈るしかないかも。

法規は、平成27(2015)年9月期〜令和6(2024)年9月期の過去問に幾度か目を通してはいますが、いやらしい引っ掛けによる失点をどこまで防げるかが合否を分けそうな気がします。あと、国際法規がかなり広い範囲から出てくるので（自分の見た範囲の過去問では、やさしく学ぶ第三級海上無線通信士試験だけでは足りない印象があります）これもヘンなのが出てこないようお祈りです。四海通の方がまだ素直に見えるとはいえ、こちらもこちらでしれっと引っ掛けてきますよね…

まあ今回落としたとしても、9月期にまた試験場へ行くことになるのでその時に拾えば良いと考えてはいます。面倒なので英語だけで済ませたいですけど。

こんな状況にありながら、電気通信術、折角なので電信のリハビリをしてみようかなとか考えていたりします。LCWO、Koch法によるモールスの習得ということでちょっと触ってみましたが、20WPM（実効15WPM）の2文字(K, M)ですらロクに取れない…マトモにできるようになるには相当な時間が必要そうです。

押し入れに仕舞っていた電鍵達も引っ張り出して簡単に叩いてみましたが、HK-705旧モデルと常熟電訊器材廠制造のもの(K4)を比べるに、自分は手首を机の上に置いたままで打てるK4の方が打ち易いと思いました。とはいえ、手首を机の上に置く米式電鍵は和文には不利という話もあり、本格的にやるならエレキーもしくはもう少しグレードの高い電鍵の導入も考えておかないといけないのかもしれません。考えるのは三海通が取れた後にしたいところですが、新品で入手可能なハイモンド・エレクトロ社の最上位機種がHK-704しかないという現状を見るに（業務用高精度電鍵であるHK-807、防衛庁でも使われていたと言われるHK-808、大理石台のHK-702、どれも販売終了しています）、のんびりしている余裕は無いのかもしれません。55.9kg(23:15)

bzuncomp（昨日作ったやつ）のテストとして、OpenBSDの/usr/sbinにあるファイルを片っ端から$(BD)/etc/bzcompを使って圧縮→bzuncompで展開→元のファイルと比較、を考えていたのですが…bzcomp自体が何故かSIGSEGVで落ちてしまいます。どうやら、/usr/sbinにあるファイルを書き込み禁止のまま食わせたためにchar *strerror()でエラーメッセージを表示させる際に問題が起こったということで、直します。

これに加え、超漢字開発環境自体がgcc-2.95辺りの時代のC言語で書かれているので、イマドキのコンパイラだと警告は当然としてもエラーを起こしてビルドできない状況だったりします。databox.cは03-Feb-2009にあるdiffを使うとして、bzcomp.cの他comp.h, mkbtf.cについても手を入れないと駄目な時代になっています。mkbtf.c、gccでは大丈夫そうですがclangではmain()の引数が(void)か(int, char**)でないと駄目です（たとえば（unsigned int, unsigned char**)はエラーになります）。

bzuncompも、memcpy()みたいなことをする処理を見直しています。おそらく心配は要らないのでしょうが、最適化により出力結果が変わるかもしれないというのも嫌なので…流石にmemcpy()のままで良い部分まで置き換えちゃうのはやり過ぎかもしれませんが（#include <string.h>を削れるなーと思ったからです）。56.2kg(23:05)

$(BD)/tool/tool/bzcomp.c（実行プログラムの圧縮）があるのに、圧縮されたものを復元する手段が無いのででっち上げた話(06-Dec-2023)の続き。

i386-elfなbzuncomp.oをlibg.aから取ってくるのは流石に使い勝手が悪いので、$(BD)/tool/tool/src/comp.hにある圧縮部分の本体を読み解いてこれに対応するコードを書くことにしました。comp.hの「P (1 〜 4095) バイト前の位置から (L + 1) バイトを出力」に対する処理、これはmemcpy()を使っちゃ駄目ですし、memmove()でも正しい結果が出ないという…これに気付くのに結構時間を使ってしまいました。main.cについては何も手を加えずに使い回しています。

とりあえずファイルを一つ二つ展開してオリジナルのbzuncomp.oを使用した場合と結果が変わらないことを確認した程度なので、何らかの問題が残っている可能性はあります。また、こちらで実装したbz_uncompress()は

• 展開の際にエラーが発生した場合は、-1を戻り値とする
• dst = NULLの場合はdlenの値を無視し、展開後のサイズを戻り値とする
• dst != NULLの場合、展開後のサイズがdlenを越えた場合はエラーとする

という作りにしていますが、ここは異なるかもしれません。本当はきちんと調べてから作るべきなのでしょうが、まずは展開ができれば十分ですし、オリジナルに動作を合わせるのはその必要が生じた際に行えば良いと考えています。56.2kg(23:15)

09-Mar-2025補足：bzuncomp.cのmemcpy()回りを少し見直しました。詳細は09-Mar-2025を参照。

動作確認がてらFreeCOMのビルドを。残っていたOpenWatcomの修正を行った後に*BSDへの対応を追加してみたものの、動作するcommand.comはまだ得られていません。

FreeCOMのビルドに使うCコンパイラは

• DOS用のバイナリを生成するためのOpenWatcom（ia16-elf-gcc等他のコンパイラも使用できるようです）
• FreeCOMのビルドに使用するツールを生成するためのホストOS用コンパイラ

があり、LinuxにおいてはDOS/ホストOS共にOpenWatcomを使います。一方、OSXにおいてはDOS向けのOpenWatcomに加えホスト向けにclangを使います。*BSDについてはOSXと同様の対応を行うことにより、途中で生成されるcommand.exeまではLinuxと同様のバイナリが得られることを確認しています。ここから先、何らかの加工を行った後に出来上がるcommand.comが動かないので、何らかの加工に問題があるだろうということで調べているところです。

とはいえFreeCOMはまだ良い方で、FreeDOSカーネルはDOS/ホスト共にOpenWatcomで通すことを前提としているようです。これを*BSD上でビルドできるようにするにはどうしたものか…OSX上でFreeCOMのビルドを行うのと同様に、DOS/ホスト側で使用するコンパイラをきちんと分離するのが現実的な解となるのでしょうか。

生成AIを使用したコーディングが話題になっているので、10-Feb-2025の試作品をこんな感じのプロンプトにしてGensparkのClaude-3.7 Sonnetに食わせてみました。

得られた結果はなかなか興味深いです。文字列はargv[0]で与えると指示したにも関わらずargv[1]で指定することになっていたり、環境変数PATHを使用してサーチする場合もrealpath()を通しているとか。それはともかく、得られたコードのコンパイルがきちんと通り（エラーが出ないだけでなくwarningも出ない）、実行したら（argv[0]についてはともかく）動いたのが一番の驚きです。

生成AIによりプログラマーが不要になるかどうかは、まだ分かりません。現時点ではCコンパイラの登場した初期…Cのコードが適切にアセンブラに翻訳されたかどうかを見守りながらCのコードを書く、そんな時期と似ているように思われます。プロトタイプをざっくり作ったり、コードをレビューしてもらったり、より良いコードを書くためのアイデアを得るための相談相手として使うには、良いのかもしれません。

AI主体でコードを書く日が遠くない未来にやってきたとしても、コードが適切に書かれているか/動作するかを判断するヒトはおそらく必要とされるのではないかと思いますが…どうでしょうかね？56.8kg(24:05)