Mercurial > hg > Events > OSC2019

<html>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
<head>
<STYLE type="text/css">
.main { width:100%; }
.side { top:0px; width:0%; position:fixed; left:80%; display:none}
</STYLE>
<script type="text/javascript">
function showElement(layer){
    var myLayer = document.getElementById(layer);
    var main = document.getElementById('mmm');
    if(myLayer.style.display=="none"){
        myLayer.style.width="20%";
        main.style.width="80%";
        myLayer.style.display="block";
        myLayer.backgroundPosition="top";
    } else {
        myLayer.style.width="0%";
        main.style.width="100%";
        myLayer.style.display="none";
    }
}
</script>
<title>OS9 vrbf</title>
</head>
<body>
<div class="main" id="mmm">
<h1>OS9 vrbf</h1>
<a href="#" right="0px" onclick="javascript:showElement('menu')">
<span>Menu</span>
</a>
<a href="#" left="0px" onclick="javascript:showElement('menu')">
<span>Menu</span>
</a>

<p>
Microware 社によりMotorola のMC6809用に作られた 8bit OS。
<p>

<hr/>
<h2><a name="content000">level 2</a></h2>
sbc09 を mmu 対応にして level 2 まで動かした。
<p>
nitros9 という「まだメンテされている(〜2014)」ソースに対応した。
<p>
Coco (tandy color computer)
<p>

<pre>
    0xfe00-0xffff は MMU による影響を受けない
    ROM切り替えで、2MBのfull ramとして使える

</pre>

<hr/>
<h2><a name="content001">vrbf</a></h2>

<p>
仮想RBF (random block filer manager )
<p>

<pre>
    Unix 上のファイルを Emulator 側からos9のファイルシステムとして見せる

</pre>
os9はopen されたファイルを path descriptor というioman が管理するデータ構造で実装する。それに対応する構造体を vrbf 内で用意する。256個と決まっているので固定配列で良い。そこに FILE *を置けばよい。
<p>
os9はディレクトリを普通のファイルとして開いてしまうので、os9のディレクトリ構造を作って返す。
<p>

<pre>
   fmemopen というメモリ上のバッファを FILE* として開く機能を使う

</pre>
dir -e はファイルの属性を持つ特別なsector (file descriptor)を getstat のundocumented commandを使ってアクセスするので、それを返す必要がある。
<p>
os9は current directory をLSN( 24bit logical sector number)で持つが、面倒なので、current directory 名を256個のFIFOっで管理。同じ名前は再利用。
<p>
path descriptor でcurrent directoryを管理してくれれば良いのだが、そうでなくて、LSN。しかも、path descriptor と別。なので、別に管理する必要がある。
<p>

<hr/>
<h2><a name="content002">level2 での割り込み</a></h2>
時分割処理に必要な clock module は割り込みを行う。
<p>
割り込み時には、どのmmuにいるかわからない。なので、
<p>

<pre>
  os9にentry割り込みルーチンを登録する
  os9 が割り込み後mmuを設定してentry割り込みルーチンを呼び出す
  engry割り込みルーチンで、serviceタスクを SSvcIRQに登録して jmp   [D.XIRQ]
  すると iret してくれる
  os9 側が暇な時に、serviceタスクをsystem mode で呼び出す
  service は処理の後、task 切り替えをする用に　jmp   [&gt;D.Clock] する

</pre>

<hr/>
<h2><a name="content003">level2 のoverhead</a></h2>

<p>
vrbf はサービスするprocessとは別なシステムメモリ空間にいるので、データは copy sysetm callを使う必要がある。
<p>
vrbf のC側からはos9のsystem callを呼べないので、mmu を一時的に作って、それを使ってアクセス。mmuの情報はprocess descriptor 上にある。
<p>
call するプロセスのレジスタはsystem spaceにコピーされていて、そこに値を書き込むと返される。
<p>
hook がたくさんあり、indirect jump ばっかりが増える。
<p>
Coco ではIOは全部のプロセスに見えてしまってる。特に保護されてない。
<p>

<hr/>
<h2><a name="content004">module 間のlink</a></h2>
os9 のlinkは、system に登録されるだけ。同じメモリ空間に登録されるとは限らない。
<p>
同じ空間に登録されれば、module にアクセスできる。
<p>
module に付属している固定メモリはある
<p>
malloc されたものは自由に取り扱えるが、どこにあるかはprocess毎に異なる
<p>

<hr/>
<h2><a name="content005">Gears OS でのlink</a></h2>
現在は単一メモリ空間で動いてる。
<p>
他の部分にアクセスされないことを保証できれば別メモリ空間である必要はない。
<p>

<pre>
   Code Gear は割り当てられた Data Gear にしかアクセスできない

</pre>
できないことをメモリ保護機能的に保証するべきか?
<p>
ライブラリとライブラリの別versionの問題。
<p>

<pre>
   動く版の組み合わせリストのようなもの

</pre>
ページングは、fragmentation とかに使う方が良い。
<p>
論理的には64bitで、全部単一のアドレス空間に割り当てることが可能。(IPv6みたいに)
<p>
全世界でだと少し足りないか。分散メモリ空間を全部の計算機に割り当てる。
<p>

<hr/>
<h2><a name="content006">巨大なData Gear問題</a></h2>
許した方が過去との互換性がでる
<p>
GPGPUとの相性も良い
<p>
でも、Gers 的ではない
<p>
</div>
<ol class="side" id="menu">
OS9 vrbf
<li><a href="#content000">  level 2</a>
<li><a href="#content001">  vrbf</a>
<li><a href="#content002">  level2 での割り込み</a>
<li><a href="#content003">  level2 のoverhead</a>
<li><a href="#content004">  module 間のlink</a>
<li><a href="#content005">  Gears OS でのlink</a>
<li><a href="#content006">  巨大なData Gear問題</a>
</ol>

<hr/> Shinji KONO <kono@ie.u-ryukyu.ac.jp> /  Tue Jul 24 14:51:15 2018
</body></html>
author	anatofuz
date	Fri, 19 Apr 2019 18:23:10 +0900
parents
children