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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

memcachedを使用する(memcacheライブラリ)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る