Mercurial > hg > Events > OSC2019

comparison poster/os9/os9-level2.ind @ 8:7fd82a802a66

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
add os9
author anatofuz
date Fri, 19 Apr 2019 18:23:10 +0900
parents
children
comparison
equal deleted inserted replaced
7:d8feb607c44e 8:7fd82a802a66
1 -title: OS9 vrbf
2
3 Microware 社によりMotorola のMC6809用に作られた 8bit OS。
4
5 --level 2
6
7 sbc09 を mmu 対応にして level 2 まで動かした。
8
9 nitros9 という「まだメンテされている(〜2014)」ソースに対応した。
10
11 Coco (tandy color computer)
12
13 0xfe00-0xffff は MMU による影響を受けない
14 ROM切り替えで、2MBのfull ramとして使える
15
16 --vrbf
17
18 仮想RBF (random block filer manager )
19
20 Unix 上のファイルを Emulator 側からos9のファイルシステムとして見せる
21
22 os9はopen されたファイルを path descriptor というioman が管理するデータ構造で実装する。それに対応する
23 構造体を vrbf 内で用意する。256個と決まっているので固定配列で良い。そこに FILE *を置けばよい。
24
25 os9はディレクトリを普通のファイルとして開いてしまうので、os9のディレクトリ構造を作って返す。
26
27 fmemopen というメモリ上のバッファを FILE* として開く機能を使う
28
29 dir -e はファイルの属性を持つ特別なsector (file descriptor)を getstat のundocumented commandを
30 使ってアクセスするので、それを返す必要がある。
31
32 os9は current directory をLSN( 24bit logical sector number)で持つが、面倒なので、current directory 名を256個のFIFOっで管理。
33 同じ名前は再利用。
34
35 path descriptor でcurrent directoryを管理してくれれば良いのだが、そうでなくて、LSN。しかも、path descriptor と別。なので、
36 別に管理する必要がある。
37
38 --level2 での割り込み
39
40 時分割処理に必要な clock module は割り込みを行う。
41
42 割り込み時には、どのmmuにいるかわからない。なので、
43
44 os9にentry割り込みルーチンを登録する
45 os9 が割り込み後mmuを設定してentry割り込みルーチンを呼び出す
46 engry割り込みルーチンで、serviceタスクを SSvcIRQに登録して jmp [D.XIRQ]
47 すると iret してくれる
48 os9 側が暇な時に、serviceタスクをsystem mode で呼び出す
49 service は処理の後、task 切り替えをする用に　jmp [>D.Clock] する
50
51
52
53 --level2 のoverhead
54
55 vrbf はサービスするprocessとは別なシステムメモリ空間にいるので、データは copy sysetm callを使う必要がある。
56
57 vrbf のC側からはos9のsystem callを呼べないので、mmu を一時的に作って、それを使ってアクセス。mmuの情報はprocess descriptor 上にある。
58
59 call するプロセスのレジスタはsystem spaceにコピーされていて、そこに値を書き込むと返される。
60
61 hook がたくさんあり、indirect jump ばっかりが増える。
62
63 Coco ではIOは全部のプロセスに見えてしまってる。特に保護されてない。
64
65 --module 間のlink
66
67 os9 のlinkは、system に登録されるだけ。同じメモリ空間に登録されるとは限らない。
68
69 同じ空間に登録されれば、module にアクセスできる。
70
71 module に付属している固定メモリはある
72
73 malloc されたものは自由に取り扱えるが、どこにあるかはprocess毎に異なる
74
75 --Gears OS でのlink
76
77 現在は単一メモリ空間で動いてる。
78
79 他の部分にアクセスされないことを保証できれば別メモリ空間である必要はない。
80
81 Code Gear は割り当てられた Data Gear にしかアクセスできない
82
83 できないことをメモリ保護機能的に保証するべきか?
84
85 ライブラリとライブラリの別versionの問題。
86
87 動く版の組み合わせリストのようなもの
88
89 ページングは、fragmentation とかに使う方が良い。
90
91 論理的には64bitで、全部単一のアドレス空間に割り当てることが可能。(IPv6みたいに)
92
93 全世界でだと少し足りないか。分散メモリ空間を全部の計算機に割り当てる。
94
95 --巨大なData Gear問題
96
97 許した方が過去との互換性がでる
98
99 GPGPUとの相性も良い
100
101 でも、Gers 的ではない
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121