1980s real-time-os update 20260926
>100 Views
September 26, 26
スライド概要
1986年に開発したRTOSを発掘し、2026年版としてgithub公開しようとレビュー中です。
（ダウンロード不可）
関連スライド
Meta XR SDK(V66-74)でQuestアプリを開発
あうぜん
1.2M
各ページのテキスト
バージョン 1.0 1980s real-time-os update @noborutkhs 2026/09/26 osdev-jp https://note.com/noborutkhs https://medium.com/@noborutakahashi
@noborutkhs ● ● ● ● 個人チャンネル 1980s リアルタイムOS～商社向け通信システム開発 1990s Graphic Creatives Photo/Word Mosaic 2000s Smart Phone OS開発 UX PMOとして 2010s～現在 組込み向けHMIツール 展示会デモ開発 note ● ● Series: 1980s Real Time OS Thinking with AI ○ ChatGPTを閉じた後に、アイデアが出てくる――AIに頼らないAIの使い方を、海外掲示板Redditで聞いてみた ○ 「AI活用レベル100」を調べていたら、そもそも100点を目指す必要がないことに気づいた
Karqri ― 現在地 ● ● ● ● ● ● 1986 自分で書いた RTOS CHARM-II のソースとドキュメントを本棚で発見 2026 40年前のコードを解析・復元 Raspberry Pi Picoで再構築 ○ プリエンプティブ RTOSとして再び動作 Karqriとして書き直し ○ 1986年の挙動を baselineとして再現 ○ POSIX / Picoで同じkernelを動かす 現在： github公開前レビュー中（最初のミニマムバージョン） ○ 「なぜ1986年にこの仕様にした？」 ○ 「2026年ならどうする？」 ○ 過去のVRTX / pSOS / iTRONなどとも比較 この先はまだ決め切っていない ○ 外部からのフィードバックも入れながら方向を決める 1986年の RTOSを復刻することがゴールではなく、そこを出発点に 2026年の OSを考える
ゴールを固定しない ― 外部ループを回しながら進める AIは仮のGoalに向かう。 人間は外から新しい問いを拾い、 Goalそのものを変える。 AIが「どう進むか」を変える。 人間＋外部ループが「どこへ向かうか」 まで変える。
setjmp/longjmpでcontext switchできないか？ (1 / 2) ● 前回 (8/2) 髙橋和浩さんの発表より 検討してみた ● ● ● setjmp() で実行コンテキストを保存 longjmp() で別taskのコンテキストへ復帰 POSIX側なら、cooperativeな切替には使えそう でも Karqriでは採用しなかった ● ● ● ● ● jmp_buf の中身は処理系依存で、 新しい taskの初期 contextを自分で構築しにくい 保存される contextの詳細をKarqri側で制御できない Picoでは、割り込みからの preemptionや例外復帰まで含めて扱いたい POSIXとPicoで、context switchの意味を明示的に対応させたい
setjmp/longjmpでcontext switchできないか？ (2 / 2) 結局こうした ● ● POSIX：ucontextでtaskごとのstack/contextを作成 RP2040/Pico：PendSVでcontext switch ○ PSPをtaskごとに保持 ○ R4–R11をsave/restore ○ 初回起動用の exception frameをstack上に構築 ○ SysTick相当のtick → scheduler → PendSV
CHARM-IIのequal-priority schedulingがLIFOっぽい (1 / 2) ● ● ● ● ● ● ● ● ● ● ● ● 40年前のschedulerをレビューしたら …… CHARM-II：同じ priorityのtaskがReadyになると？ 新しく Readyになった taskを、同 priority groupの先頭へ入れる → 同priorityでは newest-first（LIFO的） ただし、time sliceが終了した taskは同priority groupの末尾へ移動するので、単純な「常に LIFO」ではない。 「なんでこんな仕様にしたんだ？」 当時のドキュメントにも明確に書かれている。 1986年当時の自分の設計意図は、 40年後には記憶にない。 当時参考にしていた RTOSを調査。 VRTX User's Guide (1984) CHARM-IIとほぼ同じ！ → CHARM-IIはVRTXのscheduler semanticsを参考にした可能性が高い。
CHARM-IIのequal-priority schedulingがLIFOっぽい (2 / 2) ● ● ● ところが3年後…… VRTX32/68000 User's Guide (1987) 同priorityのtaskは、Readyになった順に実行 FIFO / oldest-first ● ● ● ● ● そこで次の疑問 これは VRTX32で意図的に設計変更されたのか？ なぜ newest-firstをやめたのか？ → iTRONなど他のRTOSも比較 → マニュアルから「変更理由」はまだ見つからない → 当時 VRTXを使っていた人に聞いてみたい → Redditへ
今日のもくもく ● ● VRTXの設計変更の意図を当時を知る人に聞いてみる → Redditへ ○ r/osdev ○ r/retrocomputing ○ r/embedded
投げてみた - r/osdev - - r/retrocomputing - - Why did VRTX change equal-priority scheduling from newest-first to FIFO? I found out that VRTX changed its scheduling behavior just after I used it as a reference in 1986 — does anyone know why? r/embedded - Did anyone here use VRTX in the 1980s? Why did equal-priority scheduling change to FIFO?
つづきは