===================================================================
RCS file: /home/cvs/OpenXM/doc/Attic/genkou19991125.tex,v
retrieving revision 1.34
retrieving revision 1.39
diff -u -p -r1.34 -r1.39
--- OpenXM/doc/Attic/genkou19991125.tex	1999/12/21 12:02:21	1.34
+++ OpenXM/doc/Attic/genkou19991125.tex	1999/12/21 20:02:51	1.39
@@ -4,10 +4,14 @@
 \author{
 前川 将秀\thanks{神戸大学理学部数学科},
 野呂 正行\thanks{富士通研究所},
-小原 功任\thanks{金沢大学}, \\
-奥谷 幸夫\thanks{神戸大学大学院自然科学研究科博士課程前期課程数学専攻},
+小原 功任\thanks{金沢大学理学部計算科学科}, \\
+奥谷 幸夫
+%\thanks{神戸大学大学院自然科学研究科博士課程前期課程数学専攻},
+\thanks{神戸大学大学院自然科学研究科数学専攻},
 高山 信毅\thanks{神戸大学理学部数学教室},
-田村 恭士\thanks{神戸大学大学院自然科学研究科博士課程後期課程情報メディア科学専攻計算システム講座}
+田村 恭士
+%\thanks{神戸大学大学院自然科学研究科博士課程後期課程情報メディア科学専攻計算システム講座}
+\thanks{神戸大学大学院自然科学研究科情報メディア科学専攻}
 }
 \date{1999年11月25日}
 %\pagestyle{empty}
@@ -44,101 +48,94 @@ OpenXM 規約独自のデータ形式である CMO 形式(Common Math
 
 \section{OpenXM の計算モデル}
 
-{\Huge この節では計算モデルの話をしなければいけませんよ、田村君}
+{\Huge この節では計算モデルの話をしなければいけません}
 
 OpenXM 規約での計算とはメッセージを交換することである。
 そして、そのメッセージの交換はサーバとクライアントの間で行なわれる。
 クライアントからサーバへメッセージを送り、
-メッセージに対する返答を受け取ることによって
+サーバからクライアントがメッセージを受け取ることによって
 計算の結果が得られる。
 
 サーバはスタックマシンであると仮定されており、
 サーバがクライアントから受け取ったメッセージはすべてスタックに積まれる。
-OpenXM のメッセージの中にはサーバに行なわせたい動作に対応するデータがあり、
+ただし、OpenXM のメッセージの中にはサーバに行なわせたい動作に
+対応するデータがあり、
 このメッセージを受け取ったサーバはそれに対応する動作を
 行なうことが期待されている。
-ただし、サーバは命令されない限り何も動作を行なおうとはしない。
-このため、クライアントはサーバへ送ったメッセージの結果を
-サーバから
+しかし、サーバは命令されない限り何も動作を行なおうとはしない。
+このため、クライアントはサーバの状態を気にせずにメッセージを送り、
+一旦メッセージを送付し終えた後、
+サーバへ送ったメッセージの結果を
+サーバから待つことなしに次の動作に移ることができる。
 
-これはクライアントがサーバへ一旦メッセージを送付し終えると、
-あとはサーバ側の状態を気にせずにクライアントは
-クライアント自身の仕事に戻れることを意味する。
+なお、サーバに対する動作に対応したデータは SM 形式として定義されている。
+SM 形式以外のデータでは、サーバは受け取ったデータをスタックに積む
+以外の動作をしないことになっている。
+つまり、 SM 形式のデータがサーバにデータを受け取る以外の動作を
+行なわせる唯一のデータ形式である。
 
 
 \section{OpenXM のメッセージの構造}
 
-{\Huge この節では構造の話をしなければいけませんよ、田村君}
+%{\Huge この節では構造の話をしなければいけません}
 
-OpenXM のメッセージはバイトストリームであり、次のような構造を持つ。
-\begin{verbatim}
-ヘッダ  ボディ
-\end{verbatim}
-ヘッダの長さは8バイトであると定められている。ボディの長さはメッセージご
-とに異なる($0$でもよい)。
-ヘッダは次の二つの情報を持つ。
+OpenXM で規定されているメッセージはバイトストリームであり、
+次のような構造になっている。
+
+\begin{tabular}{|c|c|} \hline
+ヘッダ	& \hspace{10mm} ボディ \hspace{10mm} \\ \hline
+\end{tabular}
+
+ヘッダの長さは 8 バイトであると定められている。
+ボディの長さはメッセージごとに異なっているが、
+長さは $0$ でもよいことになっている
+%なお、すべてのメッセージに ボディが必要というわけではなく、
+%ボディのないメッセージも OpenXM 規約には存在することに
+%注意しなければならない。
+
+ヘッダは次の二つの情報を持っている。
 \begin{enumerate}
-\item 前半の4バイト。タグと呼ばれ、メッセージの種類を表わす識別子である。
-\item 後半の4バイト。メッセージにつけられた通し番号である。
+\item	前半の 4 バイトにある、メッセージの種類を表わす識別子。
+	タグと呼ばれる。
+\item	後半の 4 バイトにある、メッセージにつけられた通し番号。
 \end{enumerate}
+それぞれの 4 バイトは 32 ビット整数とみなされて扱われる。
+この場合に用いられる整数の表現方法の説明については後述するが、
+基本的に表現方法はいくつかの選択肢から選ぶことが可能となっており、
+またその選択は通信路の確立時に一度だけなされることに注意しなければならない。
 
-それぞれの4バイトは32ビット整数とみなされて処理される。
-この場合に用いられる整数の表現方法については後述するが、基本的に
-表現方法はいくつかの選択肢から選ぶことが可能であり、
-また選択は通信路の確立時に一度だけなされることに注意しておこう。
+%{\Huge 以下、書き直し}
 
-{\Huge 以下、書き直してね。}
+ボディの中身は各データ形式によって
+それぞれ独立に決められるようになっている。
+もし、 OpenXM 規約でまだ定義されていないデータ形式を使いたい場合は、
+メッセージのヘッダのタグをまだ使われてない整数値に設定し、
+ボディにデータを埋め込めばよい。
+なお、このような用途にも使えるように、
+タグにはシステム固有の表現用に推奨されている整数の範囲がある。
 
-ボディの中のデータがどのように格納されているかは
-各データ形式がそれぞれ独立に決められるようになっている。
-もし、 OpenXM 規約でメッセージのやりとりを行ないたいが、
-まだ規約で定義されていないデータ形式を使いたい場合は、
-タグをまだ使われてなさそうな値
-(システム固有の表現のために推奨されている値がある)
-に設定し、 ボディの部分にデータを埋め込めばよい。
-なお、すべてのメッセージに ボディが必要というわけではなく、
-ボディのないメッセージも OpenXM 規約には存在することに
-注意しなければならない。
 
-サーバに対する動作に対応したデータは SM 形式として定義されている。
-SM 形式以外のデータでは、サーバは受け取ったデータをスタックに積む
-以外の動作をしないことになっている。
-つまり、 SM 形式のデータがデータを受け取る以外の動作を
-サーバに行なわせる唯一のデータ形式である。
-このデータを受け取る以外の動作の中には、
-データになんらかの加工を施す動作も入っている。
-このデータになんらかの加工を施す動作の中には
-数学的な演算を行なう動作も含まれている。
-以後、データになんらかの加工を施す動作のことを計算と呼ぶことにする。
-
 \section{OpenXM の計算の進行方法}
 
-OpenXM における計算とはメッセージの交換のことである。既に計算モデルの節
-で説明したが(説明されているはずである)、OpenXM はサーバ・クライアントモ
-デルを採用していて、サーバはスタックマシンの構造を持つ。サーバが行うのは
-基本的に次の事柄に限られる。クライアントからメッセージを送られるとサーバ
-は、まずメッセージの識別子を調べ、OX\_COMMAND でなければスタックに積む。
-OX\_COMMAND であればメッセージのボディからスタックマシンのオペコードを取
-りだし、あらかじめ規約で定められたアクションを起こす。
+OpenXM における計算とはメッセージの交換のことである。
+既に計算モデルの節で説明したが、
+OpenXM はサーバ・クライアントモデルを採用していて、
+サーバはスタックマシンの構造を持つ。
+サーバが行うのは基本的に次の事柄に限られる。
+クライアントからメッセージを受け取るとサーバは、
+まずメッセージの識別子を調べ、 SM 形式のデータでなければスタックに積む。
+SM 形式のデータであればメッセージのボディから
+スタックマシンのオペコードを取りだし、
+あらかじめ規約で定められた動作を行なう。
 
-上の説明でわかるように、サーバはクライアントからの指示なしに、自らメッセー
-ジを送ることはない(例外? ox\_asir の mathcap)。
+%上の説明でわかるように、
+サーバはクライアントからの指示なしに、
+自らメッセージを送らないことに注意しなければならない。
+%(例外? ox\_asir の mathcap)。
 
-{\Huge 以下、書き直してね、田村君}
-
-
-% クライアントがサーバへなんらかの計算を行なわせる場合、
-% クライアントからサーバへ計算させたいデータをメッセージとして送り、
-% そしてその結果をサーバからメッセージで受け取ることによって計算は行なわれる。
-% ただし、サーバは結果の送信すらも命令されなければ行なうことはなく、
-% クライアントは結果を受け取らずにサーバに次々と
-% 計算を行なわせることも可能である。
-
 サーバがクライアントから受け取ったメッセージはすべてスタックに積まれる。
-ただし、このままでは受け取ったメッセージに含まれるデータを
-スタックに積み上げていくだけで、サーバは計算を行なおうとはしない。
-次いでサーバに行なわせたい動作に対応したデータを送ると、
-初めてサーバは計算などの、なんらかの動作を行なう。
+次いでサーバに SM 形式のデータを送ると、
+初めてサーバはデータをスタックに積む以外のなんらかの動作を行なう。
 このとき、必要があればサーバはスタックから必要なだけデータを取り出す。
 ここで、クライアントからの命令による動作中にたとえエラーが発生したとしても
 サーバはエラーオブジェクトをスタックに積むだけで、
@@ -149,6 +146,8 @@ OX\_COMMAND であればメッセージのボディからスタックマシ
 サーバに行なわせた動作の結果をクライアントが知りたい場合、
 スタックからデータを取り出し送信を行なう命令に対応した SM 形式のデータを
 サーバ側へ送ればよい。
+
+{\Huge 以下、書き直し}
 
 クライアントがサーバへ計算を行なわせ、結果を得るという手順を追っていくと、
 次のようになる。