[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[WitchTech 00446] SRAM ファイル共有



dieです。

On Tue, 5 Sep 2000 21:22:54 +0900 (JST)
in [WitchTech 00442] Re: 手抜き malloc
cdr@cosmonet.org (Tatsuya Kudoh) wrote:

> CDR/TKです。
> Subject変えたほうがいいかな..

と言うわけで、Subject変えて、さらによこやえりなさんのスレッドも
いったんまとめますね。

まさか(よこやえりなさんのような)ライブラリ提供者側からの
コメントが最初に来るとは思っていなかったのでびっくり(^^;


> >> 案1: /ram0 上に「みんなで使うファイル」を作る。
> >>      たとえば16KBのファイル。みんなで使えば有効活用。
> >>      そのファイルにはbank BIOSとかでアクセスする。
> >> 
> >> 案2: おそらく使っていない(笑) 2nd プロセス用のSRAM を使う(^^;
> >>      そのメモリにはbank BIOSでアクセス。

> 確保した領域に、独自のファイルシステムを作っちゃうのが
> 便利だと思います。サブディレクトリとかも実装して。
> アクセス用の関数をILにすれば、ユーザープロセスも圧迫しないし。

はい、このあたりは私も考えていました。
独自のファイルシステムと言うよりも、名前付きのメモリをmmap()
するようなイメージです。サブディレクトリって本当に必要ですか?
そもそもきっかけが「malloc()のコードをファイルと組み合わせれば」
という思い付きだったので・・

IL化も考えていました。おそらくよこやえりなさんは速い通常ライブラリを
作られると思うので、その辺で住み分けられるかな(^^;

# まぁ本当は同じモノを二つ作っちゃうぐらいなら私はコード書くのは
# やめちゃうのも手かなとか思っているんだけど・・


> 問題は、
> 1) データ管理用の領域を食う
> 2) PCとのデータ転送が面倒
> ですかね。2に関しては、そのファイルシステムにアクセスできる独自の
> ユーザーシェルを作るという荒技もありますが...

このあたりも考えていましたが、1は仕方ないでしょう。
2の方は、管理ユーティリティを別に作る必要があると思っています。
共有領域と通常SRAMファイルとの相互転送とかは最低限。
シェルまでいかなくてもそのユーティリティが直接XMODEMを話せば
相当便利でしょうね。


(よこやえりなさんのメールより)

On Tue, 05 Sep 2000 15:32:37 +0900
in [WitchTech 00441] Re: 手抜き malloc
よこやえりな <yoko@aomori-ths.gr.jp> wrote:

> いいですね。ライブラリ部はウチも独自に作るんで(をひ)、仕様をまとめませんか?

ライブラリを使われる立場の方々から意見をいただくまでは
確定出来ないのですけど、なんとなく思っていたのは、

alloc(name, size) / free(name)  .. 領域確保
mmap(name) / unmap(name)        .. 領域マップ
copy()                          .. DS (への/からの)コピー

というセットです。各種ヘッダの定義とかバンクBIOSのドキュメントを
見る限り、実際にはmmap()とかは不可能かもしれませんが、
もしBIOSバージョンアップ(?)とかで可能性が広がったときでも
互換性を保てる事を狙っておきたいと考えています。

___
澤田 大輔(die)
email: die@zonze.nu(home), swd@techbrains.co.jp(office)


ML Archives