---
title: 1980s real-time-os update 20260926
tags: 
author: [Noboru T](https://www.docswell.com/user/noborutkhs)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/4JQYQDW97P.jpg?width=480
description: 1986年に開発したRTOSを発掘し、2026年版としてgithub公開しようとレビュー中です。
published: September 26, 26
canonical: https://www.docswell.com/s/noborutkhs/KX2N1N-2026-09-26-182533
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/4JQYQDW97P.jpg)

バージョン 1.0
1980s real-time-os update
@noborutkhs 2026/09/26 osdev-jp
https://note.com/noborutkhs
https://medium.com/@noborutakahashi


# Page. 2

![Page Image](https://bcdn.docswell.com/page/K74WNZ1RE1.jpg)

@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点を目指す必要がないことに気づいた


# Page. 3

![Page Image](https://bcdn.docswell.com/page/LJ1Y5RGVEG.jpg)

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を考える


# Page. 4

![Page Image](https://bcdn.docswell.com/page/GJWG51K372.jpg)

ゴールを固定しない ― 外部ループを回しながら進める
AIは仮のGoalに向かう。
人間は外から新しい問いを拾い、
Goalそのものを変える。
AIが「どう進むか」を変える。
人間＋外部ループが「どこへ向かうか」
まで変える。


# Page. 5

![Page Image](https://bcdn.docswell.com/page/4EZLNPZG73.jpg)

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の意味を明示的に対応させたい


# Page. 6

![Page Image](https://bcdn.docswell.com/page/Y76W8MZQ7V.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/G75M9ZW274.jpg)

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を参考にした可能性が高い。


# Page. 8

![Page Image](https://bcdn.docswell.com/page/9J292RQ1ER.jpg)

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へ


# Page. 9

![Page Image](https://bcdn.docswell.com/page/DEY4YDW4JM.jpg)

今日のもくもく
●
●
VRTXの設計変更の意図を当時を知る人に聞いてみる
→ Redditへ
○
r/osdev
○
r/retrocomputing
○
r/embedded


# Page. 10

![Page Image](https://bcdn.docswell.com/page/VJNYP69678.jpg)

投げてみた
-
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?


# Page. 11

![Page Image](https://bcdn.docswell.com/page/YE9P3L2RJ3.jpg)

つづきは