1: 2003-05-21 (水) 14:05:26  |
現: 2024-01-08 (月) 12:59:05 ゲスト |
| | + | * メモリレスアーキテクチャ |
| | + | |
| | + | - 『川合の「ちょっと一言」』 OSASKスレ５の175(コメント書き込み日：2003/05/21) に対する回答の中から引用 |
| | + | -- http://www.imasy.or.jp/~kawai/osask/comment.html#2chosask5 |
| | + | |
| | + | メモリレスアーキテクチャを簡単に言うと、mallocやfreeの下請けとなるようなAPIがない、という事に尽きます(C言語のライブラリとしてmallocやfreeがないというわけではないです。後述の方法で相当するものを作っています)。そもそも「メモリ」という概念がAPIの中にないのです。あるのはファイルに対する操作だけです。 |
| | + | |
| | + | [[OSASK]]のAPIにあるのは、「ファイルを作れ」「ファイルをメモリマップしろ」「ファイルのサイズを変更しろ」などだけです。 100MBのワークエリアがほしいのなら、"WORK.BIN"というファイルを作って、それを100MBにリサイズし、適当にメモリマップして、後はあたかもそこをmallocしたかのように扱えばいいのです。この領域がいらなくなったら、メモリマップをやめて(メモリ空間からはがして)、"WORK.BIN"を削除すればおしまいです。 |
| | + | |
| | + | [[OSASK]]ではstatic変数やスタックさえも、所詮はファイルなのです。メモリなんて概念上は全く存在せず、あったとしてもただのファイルキャッシュです。僕たちがCPUのキャッシュサイズ以上のワークエリアを簡単に利用できるのと同じように、ファイルシステムが許す限り、実メモリ以上の容量のワークエリアを自由に利用できます。 |
| | + | |
| | + | なお、このやり方をまともにやるとやたらとファイルアクセスが発生しそうで遅そうですが、[[遅延書き込み]]や[[プリロード]]などにより、実際のアクセスはかなり少ないと思われます。ファイルを生成しても遅延書き込み時間中はディスクに反映されませんし、その反映されない間にそのファイルが消去されたりすれば、結局ディスクアクセスはゼロになります。そういう感じです。 |
| | + | |
| | + | このメモリレスアーキテクチャのメリットは、メモリをコントロールするためのAPIファンクションを用意しなくていいということが、最大です。これによってOSの構造は単純化されます。 OSは[[スワップ]]ファイルの管理のためにコードを追加する必要は全くなくなります。ひたすらファイル[[キャッシュ]]制御の質を高めていけばそれでいいのです。またアプリごとに[[メモリイメージ]]がファイルとなってきれいに分離するために、デバッグの場合はそのファイルを覗いたりいじったりすればよく、[[タスクセーブ]]もこれらをまとめればメモリイメージのことは解決するということもあります。 |
| | + | |
| | + | メリットはこの程度です。今までできなかったことができるようになるというほどのものではありません。しかし効率重視の[[OSASK]]にとってはこういう改善の積み重ねが重要なのです。 |
| | + | |
| | + | ---------------------------------- |
| | + | |
| | http://www.hicat.ne.jp/home/turo/osask/ | | http://www.hicat.ne.jp/home/turo/osask/ |
