* OSASK計画のここまでの総括
-(by [[K]], 2018.10.26)
** (1) 歴史的経緯
-結果的に何もリリースできなかった開発や些細なものは全て省略しています。
-[1996年??月〜] FM-TOWNSはNECのPC-98よりも優秀なんだということを言いふらしていた[[K]]が、それを実証するためにV98というエミュレータを作った。フルアセンブラで実行ファイルは60KB程度。
--エミュレータを作っているうちに、もっといろいろなエミュレータを作りたくなり、そのためにはOSから作り直したほうがいいという構想を打ち立てた。これが元祖の「OSASK計画」である。
-[1996年??月〜] OSを作るには書きやすいアセンブラがあったほうがいいということで、[[K]]はASKAというC言語風のアセンブラ仕様を提唱。ODP氏、RisaPapa氏が実装した。
-[2000年04月〜] OSASKの開発が本格化し、毎月どこまでできたかを公開した。
--最終的にインストールサイズが100KB程度の、超軽量型のPC向けのOSができた。
-[2002年02月〜] OSを開発するために普通のx86のアセンブラが必要になったので、開発した。naskと命名。win32版でnask.exeが27,648バイト。第二世代OSASK用のバイナリではnask.g01が22,824バイト。自称で「世界最小x86アセンブラ」を主張している。
-[2003年10月〜] LZMAをベースにした可逆データ圧縮を開発してtek5と命名。デコーダがかなりコンパクト。
-[2005年04月〜] 「30日でできる！OS自作入門」のための教材自作OSを開発。名前は「はりぼてOS」。サイズは30KB程度（.com化してUPXすると17.0KB）。
-[2008年04月〜] 数年かけてプログラミングスキルが上がった[[K]]はOSの作り直しをやりたくなり、「第二世代OSASK」を開発。第二世代OSASKアプリは、WindowsやLinux上からも容易に実行できるように工夫されている。実際efg01.exeという14.5KBのプログラムを使うことで、第二世代OSASKのアプリはWindows上で動作した。そして第二世代OSASKアプリはx86のOSのアプリとしては驚異的な機能密度を達成した。
-[2010年07月〜] Windows上でC言語のプログラミングをするときに、グラフィックを扱うのがとても面倒で、他人に教えるのもとても難しいと感じた。だからblikeというグラフィックライブラリを作った。これもグラフィックライブラリとしては非常にコンパクト。世間のものと比較して1桁くらい違う。Linuxにも移植された。
-[2013年03月〜] アプリケーションを小さくすることが面白くてたまらなくなり、x86の限界を超えるために独自の機械語を考案して、それをエミュレータ実行。イメージとしてはJavaに近い。OSECPU-VM（第三世代OSASK）と命名。osecpu.exeは29.0KBで、これを使うと極小のアプリが問題なく実行できる。圧倒的世界最小。
-[2017年06月〜] インタプリタなプログラミング言語を作りはじめる。途中から速度を上げるためにシンプルなインタプリタからJITコンパイラに変更。最初の一歩である最小の言語は65行！そこから段階的に大きくして行った。TLシリーズ、TJシリーズと呼んでいる。最終的にはEssenという名前にしようと思っている。
-[2018年05月〜] blikeライブラリは初心者向き過ぎて使いにくくなってきたので、アドバンスということでblaライブラリを開発。
** (2) 現時点から見た説明
-結局、基本的に行き当たりばったりで開発している。当初はOSASKというOSを作るためにあれこれ作っているという説明もそれなりに説得力があったが、今となってはそれも適切な説明であるとは言い難い。
-だから今から知る人に対して、OSASK計画とはなんであるか、特徴は何なのかと考えると、「とにかくコンパクトなソフトウェア開発」ということになると思う。
|名称|説明|サイズ|補足|開発時期|
|V98|NEC PC-9801VX2エミュレータ|60KB程度||1996年??月〜|
|第一世代OSASK|PC向けの超軽量OS|100KB程度|ウィンドウシステム、シェル・ドライバを含む|2000年04月〜|
|nask|x86用アセンブラ|27.0KB|第二世代OSASK用なら22.3KB|2002年02月〜|
|「はりぼてOS」|PC向け教材用OS|30KB程度|ウィンドウシステム、シェル・ドライバを含む|2005年04月〜|
|efg01|第二世代OSASKアプリローダ|14.5KB||2008年04月〜|
|OSECPU-VM|第三世代OSASKアプリローダ|29.0KB|Java実行エンジンみたいなもの|2013年03月〜|
|TL-01|シンプルなインタプリタ|65行|C言語で実装|2017年06月〜|
|TJ-03|シンプルなJITコンパイラ|156行|C言語で実装|2018年05月〜|
-小さく作ることがいいことなのか悪いことなのか、それはどちらでも構わない。単にここまで小さく作ることができました、というだけの話である。
-私（＝[[K]]）は小さく作ろうと思って意図的にやっているのかというと、まあそういうこともあるが、たいていは無意識にやっている。自分としてはごく自然に作っているつもりなのだが、そうするとそれだけでもかなり小さくなる。そうすると「じゃあ小ささを極めてみよう」と感じて、そこで初めて小さくすることを意識する。
** (3) 何のために小さくしているのか
-正直今まで小さくする理由はほとんど考えていなかったが、もし私に小さく作るスキルがなかったら、そもそも私はこれらのものを作れなかったのかもしれない。
-たとえばOSECPU-VMはバイトコードの仕様がJava互換ではないことを除けばJREみたいなものだが、JREのインストーラは63MBくらいある。単純に比較すればその比は2千倍だ。OSにしてもこちらでは100KBとか30KBとかになっているが、ご存知の通り普通はそんなサイズではない。
-でももし63MBのプログラムを作れなんてことになったら、それはきっと無理だろう、と、そういうことである。
-世間では大きなものを作るためにソフトウェア工学が研究されているが、私は大きなものを作るために自分が作れる規模まで小さくするという技術を持っているのかもしれない。
-しかし、その技術がどのようなものなのか、まだよくわかっていない。
-まあ他人に伝承するほどの価値がある技術なのかどうかは分からないが・・・。
-uchanさんがこの点について私のプログラミング技法を分析してくれて、以下の点がポイントなのかもしれないということになった。
--普通の人はアプリケーションを作るときにたくさんの関数を作って部品にする。このとき部品は汎用的に作り、他のアプリ開発にも流用できるようにする。
--[[K]]は重複部分をまとめるためや、モジュール化して交換したり拡張可能にするためだけに関数を使う。部品を他のアプリ開発で使うようにすることはめったにない（たまにはある、たとえばblaライブラリとかtek5ライブラリとか）。だから関数として切り出すときも汎用性は追及せず、そのアプリで必要な機能だけを必要最小限で切り出すし、そのアプリ内で使いやすい引数にする。
--部品を作っていくやり方は、なんだか自分の資産が増えていくようないいイメージがあるかもしれないけど、私の立場ではそれは汎用的で非効率な部品であり、それを使いまわせばみんな脂肪たっぷりのアプリになってしまう。・・・というかそもそも自分が作った部品を本当に使いまわしているのか？実は一生懸命に苦労して汎用化したけど、その後一度も使わないなんていうのがたくさんあるんじゃないのか？・・・ということで私は普通のやり方が「よりよい」とは思っていない。でも一つの見識ではあると思う。
* こめんと欄
#comment
![[K Wiki]](k.jpg "[K Wiki]")
