page0083
の編集
http://osecpu.osask.jp/wiki/?page0083
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
BracketName
FormattingRules
FrontPage
Fulyn
Fulyn-v2
Fulyn_Samples
Help
InterWiki
InterWikiName
InterWikiSandBox
K
KOR_PIT8254
KWVM.NET
Liva
MANA
MenuBar
OSECPU_FPGA
PG_MANA
PHP
PukiWiki
PukiWiki/1.4
PukiWiki/1.4/Manual
PukiWiki/1.4/Manual/Plugin
PukiWiki/1.4/Manual/Plugin/A-D
PukiWiki/1.4/Manual/Plugin/E-G
PukiWiki/1.4/Manual/Plugin/H-K
PukiWiki/1.4/Manual/Plugin/L-N
PukiWiki/1.4/Manual/Plugin/O-R
PukiWiki/1.4/Manual/Plugin/S-U
PukiWiki/1.4/Manual/Plugin/V-Z
RecentDeleted
SandBox
WikiEngines
WikiName
WikiWikiWeb
YukiWiki
hikalium
hikarupsp
hikarupsp_ELCHNOS
hikarupsp_ELCHNOS_IDE
hikarupsp_FrontEndCode
hikarupsp_WebCPU-VM
hikarupsp_WebCPU-VM_internal
hikarupsp_study_hh4
impressions
impressions0000
jpag0000
jpag0001
jpag0002
jpag0003
jpag0004
jpag0005
lambdalice
mandel59
members
memo0000
memo0001
memo0002
memo0003
memo0004
memo0005
memo0006
memo0007
memo0008
memo0009
memo0010
osask
osecpu4android
page0000
page0001
page0002
page0003
page0004
page0005
page0006
page0007
page0008
page0009
page0010
page0011
page0012
page0013
page0014
page0015
page0016
page0017
page0018
page0019
page0020
page0021
page0022
page0023
page0024
page0025
page0026
page0027
page0028
page0029
page0030
page0031
page0032
page0033
page0034
page0035
page0036
page0037
page0038
page0039
page0040
page0041
page0042
page0043
page0044
page0045
page0046
page0047
page0048
page0049
page0050
page0051
page0052
page0053
page0054
page0055
page0056
page0057
page0058
page0059
page0060
page0061
page0062
page0063
page0064
page0065
page0066
page0067
page0068
page0069
page0070
page0071
page0072
page0073
page0074
page0075
page0076
page0077
page0078
page0079
page0080
page0081
page0082
page0083
page0084
page0085
page0086
page0087
page0088
page0089
page0090
page0091
page0092
page0093
page0094
page0095
page0096
page0097
page0098
page0099
page0100
page0101
page0102
page0103
page0104
page0105
page0106
page0107
page0108
page0109
pagenames
populars
seccamp2013
seccamp2014
seccamp2017
ttwilb
ttwilb-asmi
yao
* OSASKの設計の歴史 -(by [[K]], 2014.06.08) ** (1) 第一世代OSASK -「エミュレータOS」構想 --(1-1)既存のOSはハードウェアの性能を引き出せていない。個性あるハードウェアは個性を生かせない(標準的な機能しか使ってもらえない)。ハードウェアがかわいそうだ。だからハードウェアの性能を引き出せるOSを作る。 --(1-2)既存のOSの設計に当たっては、既存のソフトウェア資産に配慮するあまり、大胆な再設計ができていない。だからハードウェアを生かせない。ハードウェアの設計が生かされるように、過去のソフトウェア資産なんて気にせずに設計すべきだ。本当に良い設計とは何かを考えるべきだ。 --(1-3)既存のソフトウェア資産についてはエミュレータで解決すればよい。したがってOSはエミュレータとの親和性が高くなければいけない。エミュレータが作りやすくなるような設計にするべきだ(例外機構や仮想記憶機構をエミュレータに対して開放しているとか)。自分の旧バージョンとの互換性もエミュレータで解決すればよい。だから何度でも設計は大胆に変更できるし、その際に互換性が絶たれても問題ない。 --(1-4)高度な仮想化を実現する。アプリがドライブやパスを直接指定して任意のリソースに自由にアクセスできるのはおかしい。アプリがどこにアクセスするのかを限定するべきだ。そうすればアンインストールは楽になるし、運用中のアプリ単位のバックアップも楽になる。そしてそのリソースの実体がメモリなのかディスクなのかネットワークの先なのかはユーザが制御できるようにしておけばいい。ディスクもドライブ名で指定するのはおかしい。ボリュームネームやボリュームIDで指定できるべきだ(つまり接続方式を変えてもパスは変わらない)。ネットワークパスも同様で、つまりサイトが引っ越してもURLが変わらないようなイメージ。そういう指定方式が標準で使えるべきだ。 --(1-5)タスクセーブ機能があるべきだ。つまりアプリは任意の時点で保存できなければいけないし、そのデータをもとに再開できなければいけない。 --(1-6)これら全てを満たしてもOSのインストールサイズは1MB以下である。 --これらの設計思想を「エミュレータOS」構想とする。OSASKはエミュレータOSである。 //メモリレスアーキテクチャは(1-2)や(1-4)から導かれた仕様。 ** (2) KHBIOSとkhaba -(2-1)OSASKのデバイスドライバを整備したい。それはOSASK用に限定せずに仕様をまとめたい。拡張汎用BIOSということでKHBIOSと命名された。 -(2-2)KHBIOSのデバイスドライバがCPUに依存することなく記述できれば、それはよりいっそう使いやすいだろう。そういうバイトコードを設計しよう。これはkhabaと名づけられた。この名前はJavaやその簡易版であるwabaにちなんで名づけられた。 -しかしどちらもうまく仕様をまとめることができず、これらのサブプロジェクトは中断してしまう。原因は当時の[[K]]の技術力不足。 ** (3) 「はりぼてOS」 -書籍「30日でできる!OS自作入門」の中で作る教材用OS。難しいことは一切せず、分かりやすさ最優先で書いた。 ** (4) 第二世代OSASK(efg01) -第一世代OSASKを作っているときに気づいたことがある。 --(4-1)もしOSASKが完成すれば、OSASK上で他のOSのアプリケーションは自由に実行できるが、OSASKアプリはOSASK上でしか動かない。それでいいのか?・・・もしよくないのだとしたら、OSASKアプリを他のOS上で動かす仕組みを考えるべきなのではないか?その際はできればエミュレータは使わずに済ませたい。エミュレータは大規模になりがちなので最終手段であるべきだ。 --(4-2)既存のソフトウェアのうち、エミュレータを作ってまでしてOSASK上で実行したいものが果たしてどれほどあるのだろうか(過去のソフトはそんなにいいものだろうか?)。それらをOSASK用に移植する手間の合計は、そんなに大きいのだろうか?・・・もし大きくないのだとしたら、エミュレータで解決する方法ではなく、移植させるという方向で考えてもいはずだ。・・・そもそも過去のソフトが色あせて見えるのなぜだ?そうとも、OSASKアプリがすごく小さくて高速に動くのに、過去のアプリは(エミュレータを使わずに実機で動かしたとしても)ムダに大きくてあまり速くはないからだ。それなら一度OSASK用に移植してしまったほうがいい。 --(4-3)これらから趣味でいろいろなアプリを作っていくに当たって、自分はどのOS用に作るのが一番賢明なのだろうか。Windows用?Linux用?第一世代OSASK用?もしこの予想が外れたら、自分はエミュレータ上で過去の自分のアプリを動かすか、もしくは移植しなければいけない。 --(4-4)第一世代OSASKのタスクセーブは実現していなかったが、しかし仮に実現しても基本的には同じハードウェアでしか再開できない設計だった。もし異なるアーキテクチャ上で再開しようとすれば、エミュレータが必要になってしまう。 -やはり理想はkhabaでアプリを書くことだと思えた。これならCPUの主流が変わっても対処できる。バイトコード方式なので、もちろん少し速度は落ちる。しかしそれでもエミュレータで動かすよりはずっと簡単なはずだ。 --(4-5)まとめると、エミュレータは全てを解決する最高の手段であるのは間違いないが、これに頼り切ってしまうのはよくない。なにしろエミュレータを作るのはそれなりに大変なのだから。エミュレータを使わずに解決できることはエミュレータを使わずに解決すべきだ。それで解決できない問題のためだけにエミュレータを使うべきだ。 -しかしkhabaは一度失敗しているので、まずはCPUアーキテクチャ以外の部分を再設計するこことにした。これが第二世代OSASKである。CPUアーキテクチャに関してはx86のままとした。 --(4-6)特定のハードウェアの性能を出し切るための設計をいったんやめて、既存のハードウェアにとらわれることなく、真に良い設計とは何かを考えた。 --(4-7)Windows上でもLinux上でも、エミュレータなしで実行できるようにした。つまりAPIの呼び出しを間接的にして、コードやデータがメモリ上のどこに配置されても平気なようにした。 -このように第二世代OSASKはエミュレータOSであるとはいえなくなった。しかし性能(特にサイズ)は第一世代よりもずっとよくなった。さらに他のOS上でもアプリを実行できるという特徴も実現した。 --(4-8)もっともエミュレータOSらしくないところはハードウェアの個性を生かそうとしなくなったことである。性能を完全に出し切ることもできない。・・・その代わり他の面ではエミュレータOSの方向性をより極めている。 --(4-9)基本的な方向性としては、「過去の資産をどう生かすか」ということよりも、「これから何を未来に残していくか」に重点を置いていた。 ** (5) blike -「C言語でグラフィックをもっと簡単に扱えるようにしよう、そうすれば初学者はもっと楽しくプログラミングをマスターできるはずだ」という思想のもと、[[K]]はWindows用の簡単なライブラリを書いた。これは有志によってLinuxやMacOSに移植された。 --これは横浜創英短期大学でプログラミングの講義を担当していたときに考えていた構想。 ** (6) 第三世代OSASK -OSECPU-VMのrev1は「第2.8世代OSASK」 --(6-1)いろいろと開発経験を積んでいるうちに、今ならkhabaが作れるかもしれないという感触を持つようになった。しかも(5)のblikeがあるのでグラフィックAPIもWindows上に構築できそうだ。しかし時間がないしきっかけもない。 --(6-2)khaba用にずっと考えていた仮想CPUのアーキテクチャは、実はセキュリティのために生かすことも可能なんだと2011年のセキュリティ&プログラミングキャンプで思いつく。それを確かめるために2013年のセキュリティキャンプで実際にVMとして作ってみた。これがOSECPU-VMのrev1である。rev1ではJITコンパイラも内蔵していた。つまりOSECPU-VMというのはkhabaVMの簡略版である。・・・これは大成功を収める。アプリは他を圧倒して寄せ付けないレベルのコード密度を達成し、それでいてVMは非常にコンパクトだった。 -OSECPU-VMのrev2は「第2.9世代OSASK」 --(6-3)OSECPU-VMのrev1を作ってみていろいろわかったので、その知識をフル活用し、またkhabaVMから省略していた仕様も復活させて、OSECPU-VMのrev2を作った(作っている)。 ** (7) 参考資料 -アプリサイズ比較(単位はバイト) ||「はりぼてOS」|第一世代OSASK|第二世代OSASK|OSECPU-VM rev1|OSECPU-VM rev2| |hello, world|RIGHT:78|RIGHT:141|RIGHT:16|RIGHT:15|RIGHT:15?| |chars|RIGHT:未計測|RIGHT:未計測|RIGHT:13|RIGHT:8|RIGHT:8?| |グラデーション|RIGHT:399|RIGHT:327||RIGHT:17|RIGHT:13| |bball|RIGHT:350|RIGHT:186||RIGHT:71|RIGHT:68?| |インベーダ|RIGHT:1509|RIGHT:1108||RIGHT:507|RIGHT:???| |kcube||RIGHT:1393|||RIGHT:???| ** (8) ここまでの総括 -[Q]エミュレータOSはもう作らないのか? --[A]とんでもない。もちろん作ると思う。ただそれよりも先にハードウェアに依存しない環境を整備するほうが急務だと思ったのでそうしているだけだ(Javaや.NETはアプリがコンパクトにならないし、VMが非常に大きいので自作OS上で使い続けられる気がしない)。これが落ち着けば、それぞれのハードウェアの個性を生かせるエミュレータOSの開発を再開すると思う。そしてエミュレータも作るだろう。 -成功も失敗もあったけど、とにかく作り続けたからこそいろいろわかってきたのだと思う。何もしなければ何もわからない。 * こめんと欄 #comment
タイムスタンプを変更しない
* OSASKの設計の歴史 -(by [[K]], 2014.06.08) ** (1) 第一世代OSASK -「エミュレータOS」構想 --(1-1)既存のOSはハードウェアの性能を引き出せていない。個性あるハードウェアは個性を生かせない(標準的な機能しか使ってもらえない)。ハードウェアがかわいそうだ。だからハードウェアの性能を引き出せるOSを作る。 --(1-2)既存のOSの設計に当たっては、既存のソフトウェア資産に配慮するあまり、大胆な再設計ができていない。だからハードウェアを生かせない。ハードウェアの設計が生かされるように、過去のソフトウェア資産なんて気にせずに設計すべきだ。本当に良い設計とは何かを考えるべきだ。 --(1-3)既存のソフトウェア資産についてはエミュレータで解決すればよい。したがってOSはエミュレータとの親和性が高くなければいけない。エミュレータが作りやすくなるような設計にするべきだ(例外機構や仮想記憶機構をエミュレータに対して開放しているとか)。自分の旧バージョンとの互換性もエミュレータで解決すればよい。だから何度でも設計は大胆に変更できるし、その際に互換性が絶たれても問題ない。 --(1-4)高度な仮想化を実現する。アプリがドライブやパスを直接指定して任意のリソースに自由にアクセスできるのはおかしい。アプリがどこにアクセスするのかを限定するべきだ。そうすればアンインストールは楽になるし、運用中のアプリ単位のバックアップも楽になる。そしてそのリソースの実体がメモリなのかディスクなのかネットワークの先なのかはユーザが制御できるようにしておけばいい。ディスクもドライブ名で指定するのはおかしい。ボリュームネームやボリュームIDで指定できるべきだ(つまり接続方式を変えてもパスは変わらない)。ネットワークパスも同様で、つまりサイトが引っ越してもURLが変わらないようなイメージ。そういう指定方式が標準で使えるべきだ。 --(1-5)タスクセーブ機能があるべきだ。つまりアプリは任意の時点で保存できなければいけないし、そのデータをもとに再開できなければいけない。 --(1-6)これら全てを満たしてもOSのインストールサイズは1MB以下である。 --これらの設計思想を「エミュレータOS」構想とする。OSASKはエミュレータOSである。 //メモリレスアーキテクチャは(1-2)や(1-4)から導かれた仕様。 ** (2) KHBIOSとkhaba -(2-1)OSASKのデバイスドライバを整備したい。それはOSASK用に限定せずに仕様をまとめたい。拡張汎用BIOSということでKHBIOSと命名された。 -(2-2)KHBIOSのデバイスドライバがCPUに依存することなく記述できれば、それはよりいっそう使いやすいだろう。そういうバイトコードを設計しよう。これはkhabaと名づけられた。この名前はJavaやその簡易版であるwabaにちなんで名づけられた。 -しかしどちらもうまく仕様をまとめることができず、これらのサブプロジェクトは中断してしまう。原因は当時の[[K]]の技術力不足。 ** (3) 「はりぼてOS」 -書籍「30日でできる!OS自作入門」の中で作る教材用OS。難しいことは一切せず、分かりやすさ最優先で書いた。 ** (4) 第二世代OSASK(efg01) -第一世代OSASKを作っているときに気づいたことがある。 --(4-1)もしOSASKが完成すれば、OSASK上で他のOSのアプリケーションは自由に実行できるが、OSASKアプリはOSASK上でしか動かない。それでいいのか?・・・もしよくないのだとしたら、OSASKアプリを他のOS上で動かす仕組みを考えるべきなのではないか?その際はできればエミュレータは使わずに済ませたい。エミュレータは大規模になりがちなので最終手段であるべきだ。 --(4-2)既存のソフトウェアのうち、エミュレータを作ってまでしてOSASK上で実行したいものが果たしてどれほどあるのだろうか(過去のソフトはそんなにいいものだろうか?)。それらをOSASK用に移植する手間の合計は、そんなに大きいのだろうか?・・・もし大きくないのだとしたら、エミュレータで解決する方法ではなく、移植させるという方向で考えてもいはずだ。・・・そもそも過去のソフトが色あせて見えるのなぜだ?そうとも、OSASKアプリがすごく小さくて高速に動くのに、過去のアプリは(エミュレータを使わずに実機で動かしたとしても)ムダに大きくてあまり速くはないからだ。それなら一度OSASK用に移植してしまったほうがいい。 --(4-3)これらから趣味でいろいろなアプリを作っていくに当たって、自分はどのOS用に作るのが一番賢明なのだろうか。Windows用?Linux用?第一世代OSASK用?もしこの予想が外れたら、自分はエミュレータ上で過去の自分のアプリを動かすか、もしくは移植しなければいけない。 --(4-4)第一世代OSASKのタスクセーブは実現していなかったが、しかし仮に実現しても基本的には同じハードウェアでしか再開できない設計だった。もし異なるアーキテクチャ上で再開しようとすれば、エミュレータが必要になってしまう。 -やはり理想はkhabaでアプリを書くことだと思えた。これならCPUの主流が変わっても対処できる。バイトコード方式なので、もちろん少し速度は落ちる。しかしそれでもエミュレータで動かすよりはずっと簡単なはずだ。 --(4-5)まとめると、エミュレータは全てを解決する最高の手段であるのは間違いないが、これに頼り切ってしまうのはよくない。なにしろエミュレータを作るのはそれなりに大変なのだから。エミュレータを使わずに解決できることはエミュレータを使わずに解決すべきだ。それで解決できない問題のためだけにエミュレータを使うべきだ。 -しかしkhabaは一度失敗しているので、まずはCPUアーキテクチャ以外の部分を再設計するこことにした。これが第二世代OSASKである。CPUアーキテクチャに関してはx86のままとした。 --(4-6)特定のハードウェアの性能を出し切るための設計をいったんやめて、既存のハードウェアにとらわれることなく、真に良い設計とは何かを考えた。 --(4-7)Windows上でもLinux上でも、エミュレータなしで実行できるようにした。つまりAPIの呼び出しを間接的にして、コードやデータがメモリ上のどこに配置されても平気なようにした。 -このように第二世代OSASKはエミュレータOSであるとはいえなくなった。しかし性能(特にサイズ)は第一世代よりもずっとよくなった。さらに他のOS上でもアプリを実行できるという特徴も実現した。 --(4-8)もっともエミュレータOSらしくないところはハードウェアの個性を生かそうとしなくなったことである。性能を完全に出し切ることもできない。・・・その代わり他の面ではエミュレータOSの方向性をより極めている。 --(4-9)基本的な方向性としては、「過去の資産をどう生かすか」ということよりも、「これから何を未来に残していくか」に重点を置いていた。 ** (5) blike -「C言語でグラフィックをもっと簡単に扱えるようにしよう、そうすれば初学者はもっと楽しくプログラミングをマスターできるはずだ」という思想のもと、[[K]]はWindows用の簡単なライブラリを書いた。これは有志によってLinuxやMacOSに移植された。 --これは横浜創英短期大学でプログラミングの講義を担当していたときに考えていた構想。 ** (6) 第三世代OSASK -OSECPU-VMのrev1は「第2.8世代OSASK」 --(6-1)いろいろと開発経験を積んでいるうちに、今ならkhabaが作れるかもしれないという感触を持つようになった。しかも(5)のblikeがあるのでグラフィックAPIもWindows上に構築できそうだ。しかし時間がないしきっかけもない。 --(6-2)khaba用にずっと考えていた仮想CPUのアーキテクチャは、実はセキュリティのために生かすことも可能なんだと2011年のセキュリティ&プログラミングキャンプで思いつく。それを確かめるために2013年のセキュリティキャンプで実際にVMとして作ってみた。これがOSECPU-VMのrev1である。rev1ではJITコンパイラも内蔵していた。つまりOSECPU-VMというのはkhabaVMの簡略版である。・・・これは大成功を収める。アプリは他を圧倒して寄せ付けないレベルのコード密度を達成し、それでいてVMは非常にコンパクトだった。 -OSECPU-VMのrev2は「第2.9世代OSASK」 --(6-3)OSECPU-VMのrev1を作ってみていろいろわかったので、その知識をフル活用し、またkhabaVMから省略していた仕様も復活させて、OSECPU-VMのrev2を作った(作っている)。 ** (7) 参考資料 -アプリサイズ比較(単位はバイト) ||「はりぼてOS」|第一世代OSASK|第二世代OSASK|OSECPU-VM rev1|OSECPU-VM rev2| |hello, world|RIGHT:78|RIGHT:141|RIGHT:16|RIGHT:15|RIGHT:15?| |chars|RIGHT:未計測|RIGHT:未計測|RIGHT:13|RIGHT:8|RIGHT:8?| |グラデーション|RIGHT:399|RIGHT:327||RIGHT:17|RIGHT:13| |bball|RIGHT:350|RIGHT:186||RIGHT:71|RIGHT:68?| |インベーダ|RIGHT:1509|RIGHT:1108||RIGHT:507|RIGHT:???| |kcube||RIGHT:1393|||RIGHT:???| ** (8) ここまでの総括 -[Q]エミュレータOSはもう作らないのか? --[A]とんでもない。もちろん作ると思う。ただそれよりも先にハードウェアに依存しない環境を整備するほうが急務だと思ったのでそうしているだけだ(Javaや.NETはアプリがコンパクトにならないし、VMが非常に大きいので自作OS上で使い続けられる気がしない)。これが落ち着けば、それぞれのハードウェアの個性を生かせるエミュレータOSの開発を再開すると思う。そしてエミュレータも作るだろう。 -成功も失敗もあったけど、とにかく作り続けたからこそいろいろわかってきたのだと思う。何もしなければ何もわからない。 * こめんと欄 #comment
テキスト整形のルールを表示する