バージョン 1.0 Linux以前: 40年前のRTOSをAIで読み解く @noborutkhs 2026/04/24
発見 ギリギリ「昭和」 1986 - 1988
Spec - CPU : 68000 開発ホスト: Sun-2 Unix 4.2BSD コンパイラ:Whitesmiths C ICE アンリツ MC-4501A ソース管理: SCCS サイズ 約4.5 KBytes
参照環境(情報源) 1986頃 - リアルタイムシステムの教科書 - 先輩のコード(カーネルとアプリが未分離) - OSSなし - インターネットなし - 商用RTOSドキュメントのみ (VRTX / pSOS)
教科書 - STEPHEN SAVITZKY - Zilog Inc. - 1985 - Chapter 8に一部ソース が載っていた
CHARM-II - 本棚から発掘 - 教科書のコード ↓ VRTX, pSOSの仕様 ↓ 実用RTOS
ソースファイル一覧 User’s Guideより
プロセススイッチ - 教科書にも具体的に書かれていない - 先輩のコードを参考にした - 68000で動作実績あり - 68000で何をやる必要があるかを読み解いた
アプリ開発 -- 商社向け国際通信システム 国際通信網 専用線 受信 送信 モデム x 5 ドットプリンタ モデム 電話網 プリンタ以外は全て RS-232C
アプリ構造 - Polling handler TX Modem1 Modem2 RX Modem3 Printer … Multi-process State machine Message passing
コンペ 会社 町工場 CPU 68000 80186 方式 イベント駆動 (RTOS) ポーリング中心 (割り込み+ポーリング) 応答速度 数十mS 数百mS vs 速い 1桁 ■ 結果は総合評価で引き分け Kxx子会社
No Tuning - 特別な最適化をしていない。 - アセンブラはプロセススイッチと割り込みエントリのみ - Cのコードは遅くならないようには気をつけていた - - 当時のコンパイラはほぼオプティマイズほぼなし それでも速かったのは、構造の影響が大きい
Sun-2 Debug - Sun-2: 68010 / ターゲット: 68000 - Unixのプロセスの中にRTOSを疑似的に実装 - 今で言うマルチスレッド的に動かし、Sun-2で大部分をデバッグ
Low frequency bug - 一番大変だったのは再現しないバグ - 原因特定に時間がかかる - 当時の解析はプロトコルアナライザ ↓ - 今ならAIでソース解析とかできそう
AI解析: Queue-centric / Event-driven PROCESS (状態管理) Application (通信アプリ /FSM群) メッセージ / イベント EVENTBOX (イベント) EXCHANGE (通信) TIMER (timeout) QUEUE (中核構造) MEMORY (free管理) READY QUEUE INTERRUPT (最小処理のみ) メッセージ投入 PROCESS起床
AI解析: 教科書 vs CHARM-II 教科書 (Chapter 8) QUEUE Application TIMER SERVICE (それぞれ独立)
AI解析: Interrupt → Message - 割り込みで処理せず、メッセージでプロセスに渡している INTERRUPT メッセージ投入 PROCESS起床
AI解析: iTRON(1987)との比較 (1/2) 共通点 1. 2. 3. 4. プロセスモデル 状態を持つタスク(プロセス) 通信モデル メッセージで同期する 同期・イベント イベントで起きる 割り込みとの関係 割り込みで完結しない
AI解析: iTRON(1987)との比較 (2/2) 違い 1. 2. 3. CHARM-II レベル 汎用性 構造の中心 iTRON 実装 設計仕様 特定用途(通信システム) 汎用組込みOS queue中心 タスク中心 当時はiTRONの実装を参照できる状態ではなかったが、構造はかなり近い
AI解析: 自分のコードを AIで読む - 40年前の自分のコードを、 今になってAIと一緒に読み解いている感じ。 当時は意識していなかった構造が見えてくる。 「自分が書いたコードなのに、AIに解説してもらって理解し直してる」
次回予告 - 80s RTOS - 90s Graphics (プログラミング利用)
付録:システムコール User’s Guideより
付録:プロセス状態遷移図 User’s Guideより