Skip to content

MMU

Jump to bottom Edit New page
oraccha edited this page Jan 14, 2013 · 1 revision

Memory Management Unit

=== PDAとMMU === PDA用プロセッサにもMMUがあった方がいいか．

コストの問題もありますし，uClinuxなどのMMUを使わないLinuxなどの実装もありますが，MMUがあった方が圧倒的にプログラム作りやすいでしょう． アドレス空間をリニアな論理アドレスにマッピングできるようになるので，バンク切替えやPalmOSみたいな面倒な作業をユーザが気にする必要がなくなるし．

  • メモリ空間が「抽象化」されることは大事(=嬉しい)だと思いますが、 「リニアに」なることが同じくらい大事なのかどうかは疑問です。 二次元アドレッシングの話や「C言語ポインタ完全制覇」本を読んで 益々そう確信するに至りました(^^;。従来通り(笑)のCとUnixの延長 のみを考えるならばリニアが前提なんでしょうけど、リニア性は結局 1つの配列の中身でだけ成立すれば充分じゃんっていうか。 -戯
  • つーわけで JavaOS なのかなーと(^^;。保護がなぜ必要かというと、 リニア…直線つーか「線分」なメモリモデルを仮定してるから、 故意にせよ事故にせよOVER RUNを案じないとならないせい、ですよね？ . JavaOSでは極論すればKernelは「配列」マネージャなんじゃないかと(暴言 。
    • 仮想マシンのところでも少し書いたけど，Java が安全なのは 生のメモリへのアクセスを禁止して，仮想マシン上で動作するからでしょう． 言語レベルで境界チェックがあるので，配列外へのアクセスはできないなど．
      • 仮想マシンを拡張してハードウェアアドレスにアクセスできるバイトコード (peek/pokeとでもしておきますか(^^;)を付けた時点でC言語と同様な 脆弱性が生まれますよね．
      • そここそがJava御自慢のSecurity Managerの出番かと。 通常のByteCode列であることしか期待されてないClass FileをLoadしたら、 正しいかどうかをManagerが調べてくれる。
        • だから逆にいえば、拡張Codeを含んだFileや、更にいえばJNI必須の ドライバ(やVM自体のパッチ?)を、配布する手段を考えると 困り果ててしまうのだと思います。尤も万事無批判にやっちゃう従来の OSよりはマシかもですが。
    • もちろん，JavaVM だけを動かすことを前提としたカーネルはプロセスみたいな ヘビーな環境を用意する必要はないですし，メモリに関して言えば malloc/free 程度の固定長ブロックの確保，解放があれば十分だと思うので， 「暴言」じゃないと思いますよ．ひょっとしたら， アクティビティもスレッドよりプリミティブなもので十分かもしれない．
    • で，どうしても fork がしたい(^^;) (マルチスレッドじゃなく複数の保護ドメインみたいなものが欲しい)場合は， カーネルじゃなくて仮想マシンを拡張しちゃってもいいんじゃないかと思います．
    • 「マイクロカーネル : [OSパーソナリティ] = (ちび)カーネル : 仮想マシン」って感じかな．

ページングみたいな高級な機能を使わなくてもMMUはやっぱり便利です．メモリ保護も重要な点です．

  • MIPS には従来の TLB を使う方式の他に，BAT (Block Address Translation)というアドレス変換機構がある．BAT は，アドレスのマッピングをページ単位ではなく，ブロック単位でまとめてマッピングする仕組み．MIPS はプロセッサの特権モードによってアクセスできるアドレス空間が異なるが，ブロックの単位はそのセグメント単位になる．PowerPCなんかは，256MB まとめてとか，そんな感じになるらしい．
  • MIPS でメモリ保護が不要な場合は，FMT (Fixed Mapping Translation)もある．
Add a custom footer
Add a custom sidebar
Clone this wiki locally