[b-free 665] Re: 仮身名

Hideaki Suzuki (h1suzuki@Bridgew.edu)
Mon, 29 Sep 97 00:51:02 -0500

まだまだ、いきます。
Aki です。

(ひゃー、、、宿題が、、、。:心の叫び ^^;;;;)

In "[b-free 642] Re: 仮身名" with Ryuichi Naitoh ,
(05:55:40 PM +0900 in September 26,1997)
- naitoh_r wrote.

|> |> # RISC はこちらでは、未だに、「高性能 Processer」として高い評価を
|> |> # 受けているようです。僕の親しい教授も平気で、Transister 数と性能
|> |> # の Graph を Intel のチップと比べて「コストが低くて高性能を出せる」
|> |> # と力説していた。<ちゃんと「偏見だね」と、授業中僕は言ったけど。
|> |> # RISC == 次世代 という雰囲気をまだ感じる。
|> |
|> |# うーん、まぁ最近のチップで RISC でないものを探す方が難しいくらいだし、
|> |# 高性能プロセッサは RISC といってもいいんじゃないでしょうか。
|> |# もちろん、RISC だから高性能というわけではないと思うけど。
|> |
|> |# P7 あたりだと VLIW になるそうだし、そうするとまた高性能プロセッサの
|> |# 評価が変わるかもしれません。
|>
|> 少なくとも、Non-RISC というだけで、「なんだ」って感じの風潮は代わると良い

|> あ。でも、T-open は CISC じゃなく SISC とか言っても、つうじなさそうだし。

|> 苦笑)
|
|そのためにも、TRON Chip の「次」を出して欲しい。
|今だと 64 ビットがお勧め。いや、いっそのこと、128 ビットくらいで、10
|年後に出すとアナウンスしてしまうとか(そのころインテルはまだあるのか?)。

同感。
依然、友達に Gmicro/500 を紹介したときに、

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
えっと、Infoseek (Japanese) で "Gmicro" で検索してみると、
TRON Symposium, Dec 1-2 1993, Tokyo

と言うのがあるねぇ。
で。おおっと。1993 年に、66MHz で 132 MIPS を達成してるじゃないですか。
^o^!

http://www.atip.or.jp/public/atip.reports.94/tron-93.94.html ね。

すると、順当に成長していたのなら(仮定法過去用法)、66MHz -> 200MHz(3倍
)を考えると、396 MIPS!!!
ははは。Pentium Pro @200 MHz なみじゃんか。信じられん。93年当時は、僕は
そんなこと、考えもしなかったからなあ。そんなすごい数字になるとは、思わ
なかった。(笑)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

というのを、書いた。
T-open の最上位 Chip は凄いですよ。これ、Clock での単なる比例計算ですよ。小
電力・高速化以外の改良は全く成されていないと言う前提にたっている。要するに、
ホントに続いていたらこれ以上になってたはず。μVP とか繋がったし。結構周辺 C
hip もそろっていた気がする。なんで、止めちゃったの? って感じさえする。

# というか、止めたのかどうかも知らない。だって、話を聞かない。

ということで、64-bit chip も涎がでるほどみてみたいですが、まず、32-bit chip
をもっと出して欲しいです。とりあえず、CG の専用マシンとか、だれか作らないか
なぁ。H32/500+mVP ね。やっぱ、高性能 CPU は、CG から使い始めるのが、しきたり
という気がするし。<偏見大
もち、B-free を移植するの。

で、その CG machine が UI と処理性能でよい評価を受けているうちに、H64, H128
を開発。ばんばん! って発表して、「T-open の設計の先見性をみたかーーー! 
ざまあみろ(?)」って。

# なんて、楽観主義な。というか、もうほとんど、極楽主義。^^;;;

|> |世界一長い人の名前って何文字でしたっけ?
|>
|>
|> う。
|> 知らない。100もじ越える? (-.-;
|
|じゅげむなんたらは 100 文字を越えてますよね。
|(漢字だともっと短い?)

でも、短い名前ももってたよね。<関係ないけど。

|> |> 後、仮身名はアプリケーションからは、隠すべきだと思います。
|> |> システムで処理してしまうと云う事ね。
|> |> システムの内部情報の中に全てのっかるでしょう?>仮身名
|> |>
|> |> 変更とかも、「仮身属性」からやれば良いし。
|> |> もしくは、「仮身名」というのをメニューに追加?
|> |>
|> |> # 仮身名の追加は、実際は LINK 構造体の変更と
|> |> # App の re-compile で何とかならないかな?
|> |> # 構造体の変更も、member の追加にとどめてさ。
|> |
|> |アプリケーションから仮身名を隠すということは、アプリケーションから実身
|> |名と仮身名を区別できないということですか?
|> |そうすると、実身名と仮身名の情報の両方にアクセスしたいアプリケーション
|> |が困ってしまうのでは?
|> |
|> |複数の実身を同時に開くようなアプリケーションがあった場合、同じ実身を
|> |2 重に開きたくないとします。その場合同じ実身かどうかを区別するのは、
|> |その実身名でしょう。仮身名を入れた場合、同じ実身に対して、仮身名と実身
|> |名の 2 つの名前がつくことになります。アプリケーションから区別できない
|> |とすると、ある名前(実身名か仮身名のどちらか) がすでに開いた実身かどう
|> |かを区別できないことになります。
|>
|> えっと、区別できないと言うより、実身名しか見えないと言う意味ね。メニュー
が増
|> えても、oexe_vmn() に渡すだけだから、App から引き続き見え無くできますよね

|> (不確か)
|> 仮身名を操作したい App もあるやも知れませんが、それって、システムで提供す

|> 物以外にどんな物が考えられます? あと、同じ実身を2つ開きたくないのは、単

|> 、ファイルIDで判断すれば良いのではないのかなあ? とにかく、仮身名を追加
する
|> とすれば、VLINK の直後しかないでしょうね。
|
|たとえば、仮身を表示するアプリケーションの場合、システム提供の機能だけ
|では足りず、自分で仮身名を参照したい場合があるとか。
|あと、仮身名をキーにして検索するようなツールの場合だと、当然ながら仮身
|名を見る必要がありそうです。
|
|あとは、バッチ処理(あぁ、逃げないで!)を行うようなツールで、ある実身に
|含まれる仮身名を一斉に特定の規則(たとえば、現在の日付を追加したいとか)
|にのっとって変更したいとか、いろいろ考えられます。
|
|# 考えてみると実身/仮身って「お回し」という立派なバッチ処理の概念がある
|# のですよね。。。誰も使っていないだけで。

仮身を表示すること自体は、システム提供の機能でしょ?

odsp_vop(vid, r, disp)
or
odra_vop(vlink, vseg, wid, disp)

どちらも、仮身名を VLINK や ID で渡すから、仮身名は関係ない。

検索のキーとするのは、vid かなんかと検索条件から、Hit/Miss を返す API を作っ
てしまうのが一番だと思う。

Batch に関しては、うーん。TACL を待つとか。^^;;;;

# お回しは、B-free に標準装備?
# (だと、かっこいいなぁ。^^)

--------------------------------------------------------------
Hideaki Suzuki (SO in Bridgewater State College)
e-mail H1Suzuki@Bridgew.edu
Home Page http://www.yashi.com/h1suzuki (Under Constr.)
Nifty-Serve KGH06253