RFC387 日本語訳
0387 Some experiences in implementing Network Graphics Protocol Level0. K.C. Kelley, J. Meir. August 1972. (Format: TXT=9059 bytes) (Updated by RFC0401) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group Karl C. Kelley Request for Comments: 387 Jaacov Meir NIC: 11359 8/10/72 Categories: D.6, F Obsoletes: References: RFC #292
コメントを求めるワーキンググループカールのC.ケリー要求をネットワークでつないでください: 387 JaacovメイアNIC: 11359 8/10/72のカテゴリ: D.6、Fは以下を時代遅れにします。 参照: RFC#292
SOME EXPERIENCES IN IMPLEMENTING NETWORK GRAPHICS PROTOCOL LEVEL 0
ネットワークグラフィックスプロトコルレベル0を実行するいくつかの経験
We are in the process of implementing NGP-0 at several hosts. For the time being, we are forced to consider the remote host as the "last intelligent machine". We are attempting to translate NGP-0 to a machine dependent code for the Computek display. The remote hosts are CCN, UCSD, and soon RANDCSG. More comments about that work will be made in subsequent RFC's. The concern of this RFC is twofold:
数人のホストでNGP-0を実行することの途中に私たちはいます。 当分の間、私たちは、やむを得ずリモートホストを「最後の知的なマシン」と考えます。 私たちは、Computek表示のためにマシンの依存するコードにNGP-0を翻訳するのを試みています。 すぐ、リモートホストはCCN、UCSDです。RANDCSG。 More comments about that work will be made in subsequent RFC's. このRFCの関心は二つです:
1. Clarify the coordinate number system.
1. 座標数システムをはっきりさせてください。
2. Puzzle over how to do TEXTR string without either:
2. どちらかなしでTEXTRストリングをどうするかで悩んでください:
a. Reading current position and saving it while the text string is being output, or
a。 またはテキスト文字列が出力である間、現在の位置を読んで、それを救う。
b. Monitoring the beam position for each NGP command and saving this information somewhere.
b。 それぞれのNGPコマンドのためにビーム位置をモニターして、どこかにこの情報を保存します。
An appendix to this RFC will outline the conversion from the NGP coordinate system to the floating point arithmetic on the PDP-1O.
このRFCへの付録はPDP-1OにおけるNGP座標系から浮動小数点演算までの変換について概説するでしょう。
The Coordinate Data
座標データ
The document for NGP-0 (RFC 292) does not say specifically that the format of coordinate data is the same whether the command is in absolute or relative mode. The only thing stated is that they are in two's complement notation with the leftmost bit being the sign bit. It is possible to use two different 2's complement schemes:
NGP-0(RFC292)のためのドキュメントには、コマンドが絶対の、または、相対的なモードであるか否かに関係なく、座標データの形式が同じであると明確に書かれていません。 述べられた唯一のことは彼らが符号ビットである一番左ビットの2の補数記法でいるということです。 使用に、2異なった2が計画の補足となるのは、可能です:
Kelley & Meir [Page 1] RFC 387 Experience Implementing Net Graphics Protocol August 1972
グラフィックスプロトコル1972年8月にネットを実行するというケリーとメイア[1ページ]RFC387経験
System A System B (Absolute Coordinates) (Relative Coordinates)
システムはシステムBです(絶対座標)。(相対的な座標)
-1 -2 -3 -16 0 -1 -2 -15 -2 2 2 ... ...2 -2 2 2 ... 2 +--+--+--+--+---------+--+--+ +--+--+--+--+---------+--+--+ | | | | | | | | | | | | | | | | +--+--+--+--+---------+--+--+ +--+--+--+--+---------+--+--+ ^ ^
-1 -2 -3 -16 0 -1 -2 -15 -2 2 2 ... ...2 -2 2 2 ... 2 +--+--+--+--+---------+--+--+ +--+--+--+--+---------+--+--+ | | | | | | | | | | | | | | | | +--+--+--+--+---------+--+--+ +--+--+--+--+---------+--+--+ ^ ^
.0111 ...............11 = +1/2-e 0.11 ..............11 = 1-e
.0111 ...............11は+1/2-e0.11と等しいです…11 = 1e
.00 .................01 = +e 0.100 .............00 = 1/2
.00 .................01は+ e0.100と等しいです…00 = 1/2
.00 .................0 = 0 0.00...............01 = e
.00 .................0 = 0 0.00...............01 =e
.111 ................11 = -e 0.00 ..............00 = 0
.111 ................11は-e0.00と等しいです…00 = 0
.100 ................ = 1/2 1.11 ..............11 = -e
.100 ................ = 1/2 1.11 ..............11 =-e
1.10 ..............00 = -1/2
1.10 ..............00 = -1/2
1.00 ..............01 = -1+e = -(1-e)
1.00 ..............01 = -1+eが等しい、-(1-e)
1.00 ..............00 = -1
1.00 ..............00 = -1
-16 -15 Where: e = 2 Where: e = 2
-16 -15、どこ: e=2、どこ: e=2
-16 -15 Range: -1/2 to +1/2 - 2 Range: -1 to +1 - 2
-16 -15範囲: -1/2対+1/2--2は及びます: -1対+1--2
I submit that one could interpret the requirement for absolute coordinate data to be in the range -1/2 to +1/2 - e as requiring that two different number systems should be used. Thinking along those lines, System A has the advantage that you never get handed a number out of range, which saves some checking worries. It also has one whole bit more of precision.
私は、人が+1/2には絶対座標データが範囲-1/2にあるという要件を解釈できたのを提出します--2つの異なった数体系が使用されるべきであるのが必要であるとしてのe。 それらの線に沿って思って、System Aにはあなたが範囲から数を決して手渡させない心配をチェックする利点があります。範囲はいくつかを救います。 また、それには、一層の精度が全体の1ビットあります。
I further submit that having two systems to contend with merely clouds the issue and requires extra coding. It makes more sense just to stick with System B above. Among the advantages in its use are:
私は、競争する2台のシステムを持っているのが単に問題をうやむやにして、余分なコード化を必要とするのをさらに提出します。 それはまさしくSystem Bと共に上に刺さるより多くの意味になります。 使用中である有利な立場の中に、以下があります。
1. The single system can handle both absolute and relative coordinates.
1. ただ一つのシステムは絶対ものと同様に相対的な座標を扱うことができます。
Kelley & Meir [Page 2] RFC 387 Experience Implementing Net Graphics Protocol August 1972
グラフィックスプロトコル1972年8月にネットを実行するというケリーとメイア[2ページ]RFC387経験
2. If an absolute coordinate exceeds range, simply forcing the sign bit on causes a nice wrap-around.
2. 絶対座標が範囲を超えているなら、単にオンに符号ビットを強制すると、良い巻きつけて着るドレスは引き起こされます。
3. The representation is the same as the mantissa for floating point numbers on most machines. Notice, however, that mantissas of normalized floating point numbers are not in the range for absolute coordinates. The program will have to shift the mantissa until exponent is 0.
3. 表現はほとんどのマシンで浮動小数点のための仮数と同じです。 しかしながら、正常にされた浮動小数点の仮数が絶対座標のための範囲にないのに注意してください。 解説者が0歳になるまで、プログラムは仮数を移動させなければならないでしょう。
It may be that few of us interpreted the NGP document to mean two number systems were needed. If that is the case, so much the better. In any case, until shaken from the position by the overwhelming force of contrary logic, we will, in all of our implementations, use System B above for both absolute and relative coordinates.
多分、私たちのわずかしか、2つの数体系が必要であったことを意味するためにNGPドキュメントを解釈しませんでした。 それがケースであって、尚更良いなら。 どのような場合でも、反対の論理の圧倒的な力によって位置から振り落とされるまで、私たちは私たちの実現のすべてで絶対ものと同様に相対的な座標における、上のSystem Bを使用するつもりです。
The TEXTR Command -----------------
TEXTRコマンド-----------------
The last paragraph on page 4 of RFC 292 says, "...a command be included only if its output is a function solely of the current command and the "beam position" current at the start of the command. In other words, the interpreter for level 0 need have no internal storage for 'modes' or pushdown stacks."
「4RFCページの292上の最後のパラグラフは言います」…aは、出力が唯一コマンドの始めの現在のコマンドと「ビーム位置」電流の機能である場合にだけ含められるように命令します。 「言い換えれば、レベル0のためのインタプリタには、'モード'かプッシュダウンスタックのための内部記憶装置が全くある必要はありません。」
In the case of the Computek display, most of the NGP commands correspond to capabilities of the device. The lone exception is the TEXTR command. There are two ways to know what beam position to return to after the string is displayed. One way is to read the cursor position from the display just before doing the string output. This is no good because it requires reading from the device (which we can't do until input protocols are implemented). Also, on this device, the cursor position is accurate only to within 4 scope points.
Computek表示の場合では、NGPコマンドの大部分は装置の能力に対応しています。 ひとりの例外はTEXTRコマンドです。 ストリングを表示した後にどんなビーム位置に戻るかを知る2つの方法があります。 1つの方法はストリング出力をするすぐ前に表示からカーソル位置を読むことです。 装置(入力プロトコルが実行されるまで私たちができない)から読むのが必要であるので、これは良くはありません。 また、この装置では、カーソル位置も4範囲ポイントだけに正確です。
The second way to know what beam position to return to is to monitor all motions of the beam in software. Thus our implementations of NGP-0 to Computek translations will employ a software X register and Y register. On absolute commands, the registers will be set to the coordinates for that command. On relative commands, the coordinate data will be added to the registers. At the beginning and end of picture, these registers will be set to 0.
ソフトウェアにおけるビームのすべての動きをモニターすることになっているためにどんなビーム位置を返したらよいかを知る2番目の方法。 したがって、私たちのComputek翻訳へのNGP-0の実現はソフトウェアXレジスタとYレジスタを使うでしょう。 絶対座標指令のときに、レジスタはそのコマンドのために座標に設定されるでしょう。 相対座標指令のときに、座標データはレジスタに追加されるでしょう。 絵の首尾では、これらのレジスタは0に設定されるでしょう。
The TEXTR command will also cause these software beam registers to be changed. That is, the X register will be incremented for each character of the string to correspond to what is happening in the display itself.
また、TEXTRコマンドで、これらのソフトウェアビームレジスタを変えるでしょう。 ストリングの各キャラクタが表示自体で起こっていることに相当するように、すなわち、Xレジスタは増加されるでしょう。
Kelley & Meir [Page 3] RFC 387 Experience Implementing Net Graphics Protocol August 1972
グラフィックスプロトコル1972年8月にネットを実行するというケリーとメイア[3ページ]RFC387経験
APPENDIX
付録
NGP-0 to PDP-10 Floating Point ------------------------------
PDP-10へのNGP-0、浮動小数点------------------------------
The NGP-0 looks at all data numbers (X and Y parameters) as a fraction number in the following format (16 bits per number).
以下の断片番号が(1数あたり16ビット)をフォーマットするとき、NGP-0はすべてのデータ番号(XとYパラメタ)を見ます。
+--+--+--+--+--+--+-----------------+--+--+--+--+ | | | | | | | ... ... | | | | | +--.--+--+--+--+--+-----------------+--+--+--+--+ Bit position 0 1 2 3 ...... 14 15
+--+--+--+--+--+--+-----------------+--+--+--+--+ | | | | | | | ... ... | | | | | +--.--+--+--+--+--+-----------------+--+--+--+--+ ビット位置0 1 2 3… 14 15
with the binary point assumed between bits 0 and 1. Bit 0 is the sign bit and all negative numbers are represented as their two's complement. The PDP-10 machine code representation of fractions in floating point (mantissa part) is very similar to the above (with one exception--the number -1), so the transformation could be obtained simply by two operations, move and substitute.
2進小数点がビット0と1の間で想定されている状態で。 ビット0は符号ビットです、そして、すべての負数がそれらの2の補数として表されます。 浮動小数点(仮数一部)における、断片のPDP-10機械コード表現が上記で非常に同様である、(1つの例外--No.-1) 単に2つの操作で変化を得ることができるだろうというように動いてください、そして、代理をしてください。
Data (X,Y) Conversion ---------------------
データ(X、Y)変換---------------------
NGP (extreme points) Floating Point (PDP-10)
NGP(極端なポイント)の浮いているPoint(PDP-10)
(16 bits) (36 bits) exp mantissa
(16ビット) (36ビット)のexp仮数
1/2 0.1000 . . . . . .0 0 10000000 10 . . . . . .0
1/2 0.1000 . . . . . .0 0 10000000 10 . . . . . .0
-1/2 1.1000 . . . . . .0 1 01111111 10 . . . . . .0
-1/2 1.1000 . . . . . .0 1 01111111 10 . . . . . .0
-1 1.00 . . . . . .0 1 01111101 10 . . . . . .0 Special case
-1 1.00 .0スペシャルがケースに入れる.0 101111101 10
1-e 0.11 . . . . . .1 0 10000000 1111 . . . . .1
1-e0.11.1 010000000 1111… .1
Kelley & Meir [Page 4] RFC 387 Experience Implementing Net Graphics Protocol August 1972
グラフィックスプロトコル1972年8月にネットを実行するというケリーとメイア[4ページ]RFC387経験
Translation from NGP into floating point for PDP-1O:
PDP-1Oのための浮動小数点へのNGPからの翻訳:
1. Move sign bit (leftmost one) to sign bit.
1. 符号ビット(一番左もの)を符号ビットに動かしてください。
2. Move fraction part (15 bits) to mantissa part (left justified; fill with zero's to right).
2. 小数部(15ビット)を仮数一部に動かしてください(正当化された左; 右にゼロのもので満ちてください)。
3. Fill in exponent part (8 bits) according to:
3. 以下に従って、指数部(8ビット)に記入してください。
a. If positive number exp = 10000000 = (80) hex
a。 正の数expが10000000=(80)十六進法と等しいなら
b. If negative number exp = 01111111 = (7F) hex
b。 負数expが01111111=(7F)十六進法と等しいなら
c. Exception _in_only_ one number
c。 __1つの数だけにおける例外_
-1 in NGP (negative sign and fraction all zero's)
NGPの-1(ネガはサインします、そして、断片はゼロのすべてのものにサインします)
(1) mantissa becomes same as -1/2
(1) 仮数は-1/2と同じになります。
(2) exponent becomes the one's complement of (82) hex = (7D) hex
(2) 解説者は(82) (7D)が魔法をかける十六進法=の1の補数になります。
The methods of conversion will remain the same regardless of the number of bits (up to 24) that are used for the NGP fraction.
変換の方法はNGP断片に使用されるビット(最大24)の数にかかわらず同じままで残るでしょう。
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Alex McKenzie with ] [ support from GTE, formerly BBN Corp. 9/99 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[アレックス・マッケンジーによるオンラインRFCアーカイブ、][GTEからのサポート、以前BBN社9/99]
Kelley & Meir [Page 5]
ケリーとメイア[5ページ]
一覧
スポンサーリンク