[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[WitchTech 00446] SRAM ファイル共有
- Subject: [WitchTech 00446] SRAM ファイル共有
- From: Daisuke Sawada <swd@techbrains.co.jp>
- Date: Wed, 06 Sep 2000 20:12:21 +0900
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