Mitsukiの魔法実験室

　某#techでたいぷちゃんが 楽しそうにしてる ので、どんなものかと 本家 とかざっくり眺めてみる。 Doom みたいなゲームや音楽・動画プレーヤーの他、 シェル のみならず エディタ(vi) もあるらしい。最後の方は実用性は微妙そうだけど……（笑）。

• ベースになっているのは uCLinux だそうなので、MMU周りの機能がサポートされていない関係で一部の機能に制限があるほかは、普通にLinuxとして使えるっぽい（mmap()は当然使えないし、メモリ保護もない。fork()も使えないけど、vfork()やexec()は使えるのでマルチタスク動作はできる）。
• 開発環境は普通にgcc-arm。 C++でSTL も（条件付きで）可。
  
• フレームバッファは液晶に内蔵されてる＆MMUがなくメモリマップされないので、アクセス方法が（Linuxとしては）若干特殊。解像度は 機種によってバラバラ 。
  
• リモートコントロール端子がシリアルデバイスとしてアサインされているので、変換コネクタを自作すれば普通のシリアルポートとして使えるっぽい。
  
• USB/IEE1394で母艦と接続した場合、母艦からはマスストレージデバイスとして見えるので、ファイルシステムに直接アクセスできるっぽい（ただし新しい機種では微妙に制限がある模様）。

　……これって、UIやメモリ保護の面を除けば、PalmOSより素性よく使えるんじゃ？（苦笑）

ちなみに、ARM自体はMMU持ってるので、その気になればメモリ保護も実装はできる。

　仕事がアレな感じでなかなか進まないながらも、 先日買った 悪魔本を読んでるわけですが、「5.3 カーネルにおけるメモリ管理」を読んで長年(?)の疑問が氷塊。もとい氷解。

　FreeBSDといいWindowsといい、ユーザープロセスで使えるメモリ空間を減らしてまで、カーネルがユーザープロセス空間の高位（アドレス値の大きい端）を占めているのかずっと不思議だったのですが、どうもシステムコールの際のユーザー−カーネル間のデータコピーのコストを下げるためらしい。
　両者が同じアドレス空間にあれば単なるメモリブロックコピーで済むところが、両者が違うメモリ空間にあると特殊な転送を行う必要があって遅くなるため……とのこと。カーネル時間の1/3はこの手のデータコピーに食われているそうなので、そりゃたしかに影響大きそうだなあ……。

　まあ、x86ならカーネル空間とプロセス空間でセグメントを分ければ（ラージモデル）、セグメント間転送で済むのでそんなにコストもかからなそうな気もするけど、やっぱり案外コストがかかるのかもしれないし、移植性は確実に低くなるので避けたのかな。初期の386べったりな頃のLinuxとかMonaはどうしてる（た）んだろう。