[b-free: 202] Re: MemoryMap for B-FreeOS

内藤 隆一 (GGC00661@niftyserve.or.jp)
Sat, 01 Apr 1995 21:44:00 +0900

隆一です。

B-Free メイリングリストの皆さん、こんにちは。

>> On Sat, 01 Apr 1995 00:34:00 +0900, 真鍋さん said:

>  3Bのアドレス空間を参考にしながら、B-FreeOSに於けるプロセスのアドレス空間
に> つ
> いて考えてみました。

真鍋さん、提案ありがとうございます。

> ●ディレクトリ領域
>  CR3レジスタで先頭を示すディレクトリ領域(4Kbyte)から、32bit論理アドレスの先
頭> 10bit
> をオフセットとして、ページテーブルの所在が求められます。
>  先日のミーティングでも話がでましたが、コンパイラの出力するコードは絶対
> アドレスを使う様なので、プロセス毎に個別の空間が必要となります。一方で、8000
00> 00h以降の共有半空間は全プロセスで共有されます。
>  従って、ディレクトリ領域の後半(2K)の内容は全プロセスで同じアドレスを示す(

> ージテーフ
> ゛ルを共有する)はずですが、前半の2Kはプロセス毎に異なるアドレスを示します。

> う
> せならディレクトリ領域の後半を全プロセスで共有できれば簡単ですが、i80386には
そ> の
> ような仕組みは無いので、プロセス毎に4Kのディレクトリ領域を確保し、後半2Kは同
じ> アト
> ゛レスを書き込む方法を取ることになると思います。

はい。今の ITRON もそういうメモリ配置としています。
(タスク生成時のコンテキスト情報を作るところで、ページディレクトリの後
ろ 2K バイトに同じ情報を書き込んでいます)

> ●ページテーブルとコード領域の共有
>  ディレクトリ領域からページテーブルの先頭アドレスがもとめられます。これに32
bi> t論理ア
> ドレスの21〜12bitをオフセットとして、実ページを求めます。
>  一つのページテーブルは1024個の実ページをしめすので、最大で4Mbyteのアドレス
空> 間を表す事ができます。
>  処で、各プロセスの実行コード領域を、最大で(4*n)Mbyte以内に納めると言う制約
> 条件を作る事は可能でしょうか。
>  可能ならば、同じアプリを複数起動する時のコード共有を行う際に、コード部を示
> すページテーブルは一番最初の起動時のみ確保して、それ以降のプロセスでは先に述
べ> たディレクトリ領域にそのページテーブルを示すアドレスを書き込むだけで、コー
ドの> 共有とペ
> ージテーブル領域の節約が実現できると考えます。

コード領域/データ領域をページディレクトリのエントリごとに分割するとい
うのはいいアイデアだと思います。ページエントリの分だけコピーする手間が
省くことができますから。
4M バイト以上のコード部をもつプログラムというのは、ほとんどないと思い
ますがどうでしょうか? > all

# 各プロセス用の仮想空間は、2G バイトありますからもう少し余裕をもっても
# 大丈夫だと思います(128 M バイトとか)。

> ●データ領域
>  先に述べた方式でコード共有を行うなら、データ領域を示すページテーブルには、
コ> ード
> 部と別のページテーブルを用意する必要があります。従って、コンパイラはコード部
と> データ
> 部を4Mbyteのブロックで分割するコードを生成する必要があるでしょう。

これはあとで確かめてみます。

> ●アドレス空間
>  以上の考えに基づく、プロセス毎の個別半空間のアドレス割り当ての1案です
> 。

> 00000000h--------------------0M
>      コード領域
> 00400000h--------------------4M
>      データ領域
> 00800000h--------------------8M
>      ローカルメモリー領域
> 08000000h--------------------128M
>      予約
> 0FC00000h--------------------252M
>      スタック領域
> 10000000h--------------------256M
>      未使用
> 7FFFFFFFh--------------------

先にもちょっと書きましたが、もうちょっと、コード領域とデータ領域に余裕
をもたせてもいいと思いますが、どうでしょう?
ところで、これには共有メモリ領域がないですが、実際には必要ですよね。
だから、未使用の部分は次のようになると思います(ここでは、共有メモリと
して 128 M バイト用意してみました。共有メモリについてはすべてのユーザ
プロセスで同じメモリをアクセスしますから、もっと多い方がいいかもしれま
せん)。

:
:
0FC00000h--------------------252M
     スタック領域
10000000h-------------------256M
共有メモリ領域
18000000h--------------------384M

7FFFFFFFh--------------------

PS.
ところで、アプリケーションプログラムにとっては、3B 方式のメモリ取得方
法 (特に宣言しなくても勝手にアクセスできる) と BTRON1 のようなメモリ取
得方法(あらかじめ宣言してメモリを取得しないといけない) どちらの方がい
いのでしょうか?

メモリ取得エラーを考えないとあらかじめ宣言しないでも使用できる 3B 方式
の方がいいとは思いますが、メモリ取得時にエラーとなった場合の対応が難し
いような気がします。
とりあえず、次回のミーティングには、BTRON1 の方式のシステムコールをサ
ポートした場合のものをもっていきます。

-- 
内藤隆一 (ggc00661@niftyserve.or.jp)