about union
Kinjiyou Takashi
共用体 union に関する質問です．
現在研究室では，FreeBSD 2.2.x を主に使用しているのですが，
gccで (version 2.7.2.1)で，以下のようなプログラムを書くと
参考書と違う結果がでたのですが，これは gcc のバグなんでしょうか？
それとも，今ではこれが一般的になっているのでしょうか？
ここで，一般的になっていると書いたのは，Linux (egcs-1.0.3 release)で同じ
プログラムをコンパイルして実行してもFreeBSDと同じ結果になったからです．
===== ここからサンプルプログラム =====
#include <stdio.h>
#include <stdlib.h>
typedef struct {
unsigned char r;
unsigned char g;
unsigned char b;
}RGB;
typedef union {
RGB col;
unsigned long val;
}Pixel;
void main(void){
Pixel pix;
pix.val = 0;
pix.col.r = 0xf1;
pix.col.g = 0xf2;
pix.col.b = 0xf3;
printf("R:%02x, G:%02x, B:%02x\n", pix.col.r,pix.col.g,pix.col.b);
printf("Pixel value = %08x\n",pix.val);
printf("Size of RGB = %d byte\n",sizeof(RGB));
printf("Size of Pixel = %d byte\n",sizeof(Pixel));
}
===== ここまでサンプルプログラム =====
結果：
SunOSのgcc(versin 2.7.2.2) では，以下のような結果になりました．これは参考書
に書いてあったとおりの結果でした．
R:f1, G:f2, B:f3
Pixel value = f1f2f300
Size of RGB = 3 byte
Size of Pixel = 4 byte
しかし，FreeBSD の gcc(version 2.7.2.1)ならびにLinuxのgcc(egcs-1.0.3 release)
では
R:f1, G:f2, B:f3
Pixel value = 00f3f2f1
Size of RGB = 3 byte
Size of Pixel = 4 byte
というような結果になり R，G，Bの順序が逆になってしまいます．
詳しい方がいましたら御教授願います．
-----
Name : Takasi Kinjo
Mail : k98...@eve.u-ryukyu.ac.jp, tak...@mibia.tec.u-ryukyu.ac.jp
PGP-Public-Key : http://mibai.tec.u-ryukyu.ac.jp/~takasik/takasik.asc
PGP-Fingerprint: 8F 05 0A 34 B9 3E DB F5 B1 60 F0 15 15 7D D1 1C
SHIROYAMA Takayuki
>
> 現在研究室では，FreeBSD 2.2.x を主に使用しているのですが，
> gccで (version 2.7.2.1)で，以下のようなプログラムを書くと
> 参考書と違う結果がでたのですが，これは gcc のバグなんでしょうか？
> それとも，今ではこれが一般的になっているのでしょうか？
> ここで，一般的になっていると書いたのは，Linux (egcs-1.0.3 release)で同じ
> プログラムをコンパイルして実行してもFreeBSDと同じ結果になったからです．
>
> というような結果になり R，G，Bの順序が逆になってしまいます．
> 詳しい方がいましたら御教授願います．
>
エンディアンの問題では？
Sparcは Big-endian, Intelのx86系のCPUは Little-endian
のため、値がひっくり返るのだと思います。
エンディアンについての諸々は、最近、fj.comp.lang.cでも
話題になったので、他の記事に目を通せば分かると思います。
--
SHIROYAMA Takayuki : p...@fortune.nest.or.jp
YOSIDA Takayuki
共用体のあるメンバに書き込んで他のメンバを読み出した場合の
動作は(特別な場合を除いて)言語仕様上規定されていません。
そういう意味では
Message-ID: <7e2jfk$79o$1...@news1.u-ryukyu.ac.jp>
> gccで (version 2.7.2.1)で，以下のようなプログラムを書くと
> 参考書と違う結果がでたのですが，これは gcc のバグなんでしょうか？
は、プログラムのバグです :-P というか、その参考書に「どの処理系でも
f1f2f300になるはずだ」と書いてあったならその参考書のバグです。
今回の場合、多分「共用体」というより「処理系ごとのlongの実装」が
違うのが原因だと思います。
# Message-ID: <7dumeb$do2$1...@sunriseb1.eds.ecip.nagoya-u.ac.jp>
# のスレッドでも話題に出ているendian - byte order の話
例えば「void dump(const void *buffer, size_t nbytes)」といった
あんばいのメモリダンプ関数を作った場合、
unsigned long l = 0xf1f2f300;
dump(&l, sizeof l);
がそれぞれの処理系でどういう結果になりるか把握していますか？
「一般的」という意味では、例のプログラムの出力は
f1f2f3**
**f3f2f1
f1f2f3**********
**********f3f2f1
あたりが一般的な気がします。「*」の部分は「ごみ」データなので
何になるか判らない。
あまり一般的でない例としては
000000f1
なんて処理系もあることでしょう。
---
KATAYAMA Yoshio
In article <3704EEFB...@parkcity.ne.jp>,
YOSIDA Takayuki <yos...@parkcity.ne.jp> writes:
>共用体のあるメンバに書き込んで他のメンバを読み出した場合の
>動作は(特別な場合を除いて)言語仕様上規定されていません。
正確には処理系定義（implementation-defined）です。
>Message-ID: <7e2jfk$79o$1...@news1.u-ryukyu.ac.jp>
>> gccで (version 2.7.2.1)で，以下のようなプログラムを書くと
>> 参考書と違う結果がでたのですが，これは gcc のバグなんでしょうか？
>は、プログラムのバグです :-P というか、その参考書に「どの処理系でも
>f1f2f300になるはずだ」と書いてあったならその参考書のバグです。
そうですね。もし、その参考書にそのようなことが書かれているなら、
その参考書を早く捨てることをお奨めします。
>例えば「void dump(const void *buffer, size_t nbytes)」といった
>あんばいのメモリダンプ関数を作った場合、
> unsigned long l = 0xf1f2f300;
> dump(&l, sizeof l);
>がそれぞれの処理系でどういう結果になりるか把握していますか？
>あまり一般的でない例としては
> 000000f1
>なんて処理系もあることでしょう。
規格に準拠している処理系なら、そのような結果にはなりません。
--
片山＠ＰＦＵ
よろずや kin-chan
Kinjiyou Takashi <k98...@eve.u-ryukyu.ac.jp> wrote in article
<7e2jfk$79o$1...@news1.u-ryukyu.ac.jp>...
> 結果：
> SunOSのgcc(versin 2.7.2.2) では，以下のような結果になりました．これは参考書
> に書いてあったとおりの結果でした．
>
> R:f1, G:f2, B:f3
> Pixel value = f1f2f300
> Size of RGB = 3 byte
> Size of Pixel = 4 byte
これは、Bigendian
これが普通だと思ってます。
> しかし，FreeBSD の gcc(version 2.7.2.1)ならびにLinuxのgcc(egcs-1.0.3 release)
> では
>
> R:f1, G:f2, B:f3
> Pixel value = 00f3f2f1
> Size of RGB = 3 byte
> Size of Pixel = 4 byte
これは、Littleendian
これは普通じゃない。けど、ＩｎｔｅｌのＣＰＵはこっち。
で、今じゃ普通じゃない方が多くなってしまった。
つまり、ＯＳでもｇｃｃでもなく、ＣＰＵが違うということ。
Masao Seki
"よろずや kin-chan" wrote:
> これは、Bigendian
> これが普通だと思ってます。
・
・
> これは、Littleendian
> これは普通じゃない。けど、ＩｎｔｅｌのＣＰＵはこっち。
> で、今じゃ普通じゃない方が多くなってしまった。
別に、どちらが普通と言うこともないのでないでしょうか。IntelがLittleendianを
採用したのは、ＩＢＭの特許を逃れるためとか大昔に聞いた事があるような気がしま
す。それが事実なら、Bigendianが先行とは言えるかもしれませんが。
画像ファイルのフォーマットの一つのTIFFでは、Magic Numberでendianを指定する
ようになっていますし、それを扱う為のlibtiffの関数は、自分が置かれた環境と
Magic Numberが指定するendianの整合／不整合を判定して、必要に応じてendian
の変換を行います。それだけ、両者は対等だと言う事だと思います。
--
関＠神奈川
Masao Seki <ma-...@gb3.so-net.ne.jp>
ken-1
>別に、どちらが普通と言うこともないのでないでしょうか。IntelがLittleendianを
>採用したのは、ＩＢＭの特許を逃れるためとか大昔に聞いた事があるような気がしま
>す。それが事実なら、Bigendianが先行とは言えるかもしれませんが。
間島ともうします。
特許が理由だったのですか。
わたくしが何かで聞いた話では、Littleendian の方がバイト列としては不
自然だがビット列としては自然なのだそうです。
Littleendian:
バイト 0 1 2 3
ビット 01234567012345670123456701234567
Bigendian:
バイト 0 1 2 3
ビット 76543210765432107654321076543210
x ビット目のデータを取り出すような場合、
Littleendian:
x/8 バイト目の x\8 ビット目を見ればよいのですが、
Bigendian:
x/8 バイト目の 7-(x\8) ビット目を見なければなりません。
>画像ファイルのフォーマットの一つのTIFFでは、Magic Numberでendianを指定する
>ようになっていますし、それを扱う為のlibtiffの関数は、自分が置かれた環境と
>Magic Numberが指定するendianの整合／不整合を判定して、必要に応じてendian
>の変換を行います。それだけ、両者は対等だと言う事だと思います。
PowerPC も、どちらのバイトオーダでも受け付けると聞いたことがあります。
Masao Seki
ken-1 wrote:
> 特許が理由だったのですか。
いや、大昔（computer year で言うと、半世紀も前）に、そんな話を聞いた
覚えがあるというだけで、確信はないのですが。それにIntelでなく、DEC
だったかも。どなたか、もっと信憑性のある情報をお持ちの方のフォローを
頂ければと思います。
> わたくしが何かで聞いた話では、Littleendian の方がバイト列としては不
> 自然だがビット列としては自然なのだそうです。
これは、FAXの信号は通常、ビット（not Byte) オーダーを反転して送ると言う
話の事ではないかと思われます。JBIGの処理などでは、char型のbufferを使う
のが普通なので、endianの話は直接は関係して来ないのではないでしょうか。
> Littleendian:
> バイト 0 1 2 3
> ビット 01234567012345670123456701234567
>
> Bigendian:
> バイト 0 1 2 3
> ビット 76543210765432107654321076543210
Littleendianでは、バイトオーダーが逆になるだけですから、この図では
ちょっと具合が悪くて、正しくは （１ワード＝４バイトのケースでは）
Littleendian:
ワード 0 1
バイト 3 2 1 0 3 2 1 0
ビット 7654321076543210765432107654321076543210765432107654321076543210
Bigendian:
ワード 0 1
バイト 0 1 2 3 0 1 2 3
ビット 7654321076543210765432107654321076543210765432107654321076543210
のようになります。
ken-1
Masao Sekiさんの<37074156...@gb3.so-net.ne.jp>から
>これは、FAXの信号は通常、ビット（not Byte) オーダーを反転して送ると言う
>話の事ではないかと思われます。JBIGの処理などでは、char型のbufferを使う
>のが普通なので、endianの話は直接は関係して来ないのではないでしょうか。
わたくしはその話は存じませんので、たぶんわたくしの聞いた話とは別だと
思います。FAX の本なんて、G3 で MH の頃の古いものしか読んだことがあり
ませんし。（MR は名前が１回出てきただけ。MMR など影も形もなし。）
Ｃとは関係ない話かもしれませんが、よかったら詳しく教えていただけない
でしょうか。
> 略
>
>Littleendianでは、バイトオーダーが逆になるだけですから、この図では
>ちょっと具合が悪くて、正しくは （１ワード＝４バイトのケースでは）
>
> 略
>
>のようになります。
上位ビットが立つと１になるというのは、いくら何でもたしかに変でした。
# しかも、ご指摘のように、わたくしの図ではバイトオーダが逆になってない
#（赤面）。何の話をしているつもりだったんだろう。
図を眺めながらいろいろと考えてみたのですが、わたくしが聞いた話は、
（16ビットワードに変えました）
Littleendian:
ワード 0 1
ビット 151413121110 9 8 7 6 5 4 3 2 1 0151413121110 9 8 7 6 5 4 3 2 1 0
バイト 3 2 1 0
ビット 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bigendian:
ワード 0 1
ビット 151413121110 9 8 7 6 5 4 3 2 1 0151413121110 9 8 7 6 5 4 3 2 1 0
バイト 0 1 2 3
ビット 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
で、Littleendian の場合はワードアクセスでもバイトアクセスでも 0 ビット
目が一致するのに対して、Bigendian だと一致しないというような意味だった
ような気がしてきたようなしてこないような…
とにかく、Littleendian の方が便利なケースもある、という説明で、その
時はなるほどと納得したのですが、あまりよく解っていなかったようです。
まだ間違っているようでしたら、乗りかかった舟だと思って、正しく理解で
きるまで教えていただけないでしょうか。図々しいお願いですが。
# 最初の投稿のときにもっと考えればよかったんだよな。いつもながら＞オレ
Hideki Kato
Masao Sekiさんの<37074156...@gb3.so-net.ne.jp>から
>関＠神奈川です。
>ken-1 wrote:
>> 特許が理由だったのですか。
>いや、大昔（computer year で言うと、半世紀も前）に、そんな話を聞いた
>覚えがあるというだけで、確信はないのですが。それにIntelでなく、DEC
>だったかも。どなたか、もっと信憑性のある情報をお持ちの方のフォローを
>頂ければと思います。
私が記憶している限りでは，8 bit CPU で 16 bit の加算を行う（アドレス計算を含む）
場合，下のバイトが先に得られる方が 1 cycle 速く実行できるから，Intel はそちらを
採用したのだったと思います．Motorola に対抗する気持ちもあったのかも知れませんが．
少なくとも，ＩＢＭやＤＥＣに byte order に関する特許があるという記憶はありません．
>> わたくしが何かで聞いた話では、Littleendian の方がバイト列としては不
>> 自然だがビット列としては自然なのだそうです。
これは一理ありますが，アーキテクチャから見ると後追いの理屈でしょう．
--
加藤英樹＠東京 <mailto:ka...@pop12.odn.ne.jp>
ken-1
間島ともうします。
Hideki Katoさんの<7e89ne$n83$1...@newsgw7.odn.ne.jp>から
>私が記憶している限りでは，8 bit CPU で 16 bit の加算を行う（アドレス計算を含む）
>場合，下のバイトが先に得られる方が 1 cycle 速く実行できるから，Intel はそちらを
先に下位バイトを計算しつつ、上位バイトをメモリから取り出す、というこ
とでしょうか？
パイプラインがないアーキテクチャでも、こういうことで差が出るのですか？
>採用したのだったと思います．Motorola に対抗する気持ちもあったのかも知れませんが．
モトローラの方が先でしたっけ？ 8080 より 6800 の方が少し後だったよ
うな気がするのですが。8008 は 16 ビットのデータは扱えませんよね？
この時代のことは、よく知らないのです。Z80 や 6809 以降なら、少しはわ
かるのですが。
Masao Seki
遅れました。
本題に入る前に、間島さんの図を訂正した私の図も少しおかしかったので
訂正しておきます。
私の記事 <37074156...@gb3.so-net.ne.jp>で
> Littleendian:
> ワード 0 1
> バイト 3 2 1 0 3 2 1 0
> ビット 7654321076543210765432107654321076543210765432107654321076543210
>
> Bigendian:
> ワード 0 1
> バイト 0 1 2 3 0 1 2 3
> ビット 7654321076543210765432107654321076543210765432107654321076543210
という図を載せましたが、図のバイトナンバは、例えば
int a[10];
・・・
fwrite(a, sizeof(a), 1, fp);
のような感じでファイルに書き出した時の、バイト列の通しナンバのつもりで、
それをマルチバイトの整数型オブジェクトが（大小の意味を持った）数値として
評価される時の重みの大きいバイトを（ワードエリア内で）左側に置いた図に
するつもりでした。ビットの数値は単にMSBを左側に、LSBを右側に置いている
だけです。
この主旨に従った図は、正しくは
Littleendian:
ワード 0 1
バイト 3 2 1 0 7 6 5 4
ビット 7654321076543210765432107654321076543210765432107654321076543210
Bigendian:
ワード 0 1
バイト 0 1 2 3 4 5 6 7
ビット 7654321076543210765432107654321076543210765432107654321076543210
のようになりますので、この図に訂正させて頂きます。
ken-1 wrote:
> Masao Sekiさんの<37074156...@gb3.so-net.ne.jp>から
> >これは、FAXの信号は通常、ビット（not Byte) オーダーを反転して送ると言う
> >話の事ではないかと思われます。JBIGの処理などでは、char型のbufferを使う
> >のが普通なので、endianの話は直接は関係して来ないのではないでしょうか。
>
> わたくしはその話は存じませんので、たぶんわたくしの聞いた話とは別だと
> 思います。FAX の本なんて、G3 で MH の頃の古いものしか読んだことがあり
> ませんし。（MR は名前が１回出てきただけ。MMR など影も形もなし。）
> Ｃとは関係ない話かもしれませんが、よかったら詳しく教えていただけない
> でしょうか。
私もFAXは専門外なので、殆ど知ったかぶりに近いのですが、FAXの動作を
規定しているITU-Tの規格にそうすべしという記述があるのです。また、
各メーカーも、いやいや規格に従っているのではなく、むしろ実装上の
都合で皆が行っている事を規格に反映させたに近いような印象があります。
多分、間島さんも触れておられた、通しのビットナンバと個々のoctet data
のビットナンバとの親和性が良くなる事が関係しているのだと思います。
> 図を眺めながらいろいろと考えてみたのですが、わたくしが聞いた話は、
> （16ビットワードに変えました）
>
> Littleendian:
> ワード 0 1
> ビット 151413121110 9 8 7 6 5 4 3 2 1 0151413121110 9 8 7 6 5 4 3 2 1 0
> バイト 3 2 1 0
> ビット 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
>
> Bigendian:
> ワード 0 1
> ビット 151413121110 9 8 7 6 5 4 3 2 1 0151413121110 9 8 7 6 5 4 3 2 1 0
> バイト 0 1 2 3
> ビット 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
>
> で、Littleendian の場合はワードアクセスでもバイトアクセスでも 0 ビット
> 目が一致するのに対して、Littleendian だと一致しないというような意味だった
> ような気がしてきたようなしてこないような…
この図の見方が良く分からないのですが、16ビットワードなのにバイトのナンバ
に２や３があるという事は、この記事の最初で述べた、私の訂正後のバイトナンバ
と同じ性格の数字であると解釈してよろしいでしょうか。
それで、ワードとバイトの間の方のビットのナンバと、バイトの数値は、図が示す
通りの対応関係にある事を示しているのでしょうか。
それとも、一番下のビットと同じく、MSBを左側に配置し、LSBを右側に置いただけ
なのでしょうか。
私には、0～15のビットが0の時、0～7のビットも0になっている対応しか、目に
付かないのですが、それだとLittleendianもBigendianも同じになっているし・・。
Littleendian で一致していて、Bigendianで一致していないのは、図のどの部分か
教えて下さい。
> とにかく、Littleendian の方が便利なケースもある、という説明で、その
> 時はなるほどと納得したのですが、あまりよく解っていなかったようです。
> まだ間違っているようでしたら、乗りかかった舟だと思って、正しく理解で
> きるまで教えていただけないでしょうか。図々しいお願いですが。
Littleendianの方が便利な事があるのは、間違いないでしょう。現に別記事で
Hideki Katoさんが示されているような例もある事ですし。
ちょっと尻切れトンボですが、間島さんの図がちゃんと理解出来てから議論を
続けたいと思いますので、今日はこの辺で。
Hideki Kato
ken-1さんの<7eakh0$t7u$2...@news00.iij4u.or.jp>から
>
> 間島ともうします。
>
>Hideki Katoさんの<7e89ne$n83$1...@newsgw7.odn.ne.jp>から
>>私が記憶している限りでは，8 bit CPU で 16 bit の加算を行う（アドレス計算を含む）
>>場合，下のバイトが先に得られる方が 1 cycle 速く実行できるから，Intel はそちらを
>
> 先に下位バイトを計算しつつ、上位バイトをメモリから取り出す、というこ
>とでしょうか？
いえ，そうではなくて，というか，実行はその通りなんですが，ポイントは
ALU が 8 bit しかないので，下のバイトのフェッチ＆加算，上のバイトの
フェッチ＆桁上げ＆加算の順で実行 (2 cycle) することにあります．
逆順にすると，最後に桁上げの処理で 1 cycle 追加になってしまうのです．
> パイプラインがないアーキテクチャでも、こういうことで差が出るのですか？
結果的にパイプラインみたいになってますねぇ．単に逐次的なだけか．
>>採用したのだったと思います．Motorola に対抗する気持ちもあったのかも知れませんが．
>
> モトローラの方が先でしたっけ？ 8080 より 6800 の方が少し後だったよ
>うな気がするのですが。
あ，そうですね．私が勘違いしたようです．ん？まてよ，
8008 -> 6800 -> 8080 -> Z80 -> 6809 の順だったような気もしますが．．．
＃流石に昔過ぎて手元には資料がありませんでした．
>8008 は 16 ビットのデータは扱えませんよね？
Intel のアーキテクトがまともなら，8008 を設計している時には当然 16 bit
の加算の事まで考えてるはずです．ＩＣ技術の制約で 8008 には実装できなく
ても，次のチップは当然同時に計画してるはずですから．
Yasuki Arasaki
(できるだけfj.lang.c的な話にしようとがんばってます:-)
以下「===」で囲まれた部分は
http://www.rdrop.com/‾cary/html/endian_faq.html
の「ON HOLY WARS AND A PLEA FOR PEACE」の「MEMORY ORDER」の章から
適当に抜粋・和訳・まとめました。
===================================================================
ここではCがバイト(character)、Bがビット、ワードは32ビットとする。
「右」「左」は数値を書いたときの各ケタのsignificanceによる右左。
(123456はsignificanceの大きい1が左で、significanceの小さい6が右)
Big-Endian (significanceの大きい方が低位のアドレス)
low memory address high memory address (word単位で)
|---word0---|---word1---|---word2---|....
|C0,C1,C2,C3|C0,C1,C2,C3|C0,C1,C2,C3|.....
|B0......B31|B0......B31|B0......B31|......
※ワードW(n)を「右」にシフトするとW(n)のLSBがW(n+1)のMSBに入っていく。
※C0のB0がwordのMSB。文字列は左から右へ書かれる。
# 例: PDP10、360。
M68000ではワードとバイトを上図のように書くとビットの番号付けが逆。
Little-Endian (significanceの小さい方が低位のアドレス)
high memory address low memory address
...|---word2---|---word1---|---word0---|
....|C3,C2,C1,C0|C3,C2,C1,C0|C3,C2,C1,C0|
.....|B31......B0|B31......B0|B31......B0|
※ワードW(n)を「右」にシフトするとW(n)のLSBがW(n-1)のMSBに入っていく。
※C0のB0がwordのLSB。この図の書き方だと、文字列は右から左に書かれる。
# 例: PDP11、ただし1ワード=16ビット。32ビット整数値や実数はワードが
逆順で入る。VAXは32ビット整数は上図の順だが実数はPDP11と同じく逆順。
Big-EndianでもLittle-Endianでもそれぞれは首尾一貫している。
====================================================================
えーと、今のところ誰も混乱してないようなので指摘するだけ
やぼかもしれませんが、
In article <370A360A...@gb3.so-net.ne.jp>
Masao Seki <ma-...@gb3.so-net.ne.jp> さんwrote:
>> Littleendian:
>> ワード 0 1
>> バイト 3 2 1 0 7 6 5
>> ビット 76543210765432107654321076543210765432107654321076543210
>>
>> Bigendian:
>> ワード 0 1
>> バイト 0 1 2 3 4 5 6
>> ビット 76543210765432107654321076543210765432107654321076543210
(図の右の方は1バイト分切らせてもらいました)
ここでは暗黙の内にビット0=LSB、ビット7=(バイトの)MSBということ
ですけど、この番号のふりかたは処理系によるんじゃないですか。
たとえば手近なマシンで下のプログラムの実行結果を見ると
FreeBSD(x86) (little-endian)
12345678 = 78 56 34 12 = 0001 1110 0110 1010 0010 1100 0100 1000
fedcba98 = 98 ba dc fe = 0001 1001 0101 1101 0011 1011 0111 1111
58494e55 = 55 4e 49 58 = 1010 1010 0111 0010 1001 0010 0001 1010
HPワークステーション (big-endian)
12345678 = 12 34 56 78 = 0001 0010 0011 0100 0101 0110 0111 1000
fedcba98 = fe dc ba 98 = 1111 1110 1101 1100 1011 1010 1001 1000
554e4958 = 55 4e 49 58 = 0101 0101 0100 1110 0100 1001 0101 1000
ビットフィールド割り付け順序ならlittle-endianな処理系では
LSBからMSB、big-endianな処理系ではMSBからLSBという順が
普通じゃないかと思います。もともとCではビット番号は規格上に
でてこないのでビットフィールド割り付け順序とビット番号を
対応させることはしないのかもしれませんが…
--
新崎@東大院総合
ara...@mns2.c.u-tokyo.ac.jp
-----
/* sizeof(int) == 4 == 32bits assumed */
#include <stdio.h>
#define UI unsigned int
union bitcontent_t {
struct {
UI b00:1; UI b01:1; UI b02:1; UI b03:1;
UI b04:1; UI b05:1; UI b06:1; UI b07:1;
UI b08:1; UI b09:1; UI b10:1; UI b11:1;
UI b12:1; UI b13:1; UI b14:1; UI b15:1;
UI b16:1; UI b17:1; UI b18:1; UI b19:1;
UI b20:1; UI b21:1; UI b22:1; UI b23:1;
UI b24:1; UI b25:1; UI b26:1; UI b27:1;
UI b28:1; UI b29:1; UI b30:1; UI b31:1;
} b;
unsigned char c[4];
unsigned int i;
};
void show_bitcontent(union bitcontent_t u)
{
printf("%08x = %02x %02x %02x %02x = "
"%d%d%d%d %d%d%d%d %d%d%d%d %d%d%d%d "
"%d%d%d%d %d%d%d%d %d%d%d%d %d%d%d%d¥n",
u.i,
u.c[0], u.c[1], u.c[2], u.c[3],
u.b.b00, u.b.b01, u.b.b02, u.b.b03,
u.b.b04, u.b.b05, u.b.b06, u.b.b07,
u.b.b08, u.b.b09, u.b.b10, u.b.b11,
u.b.b12, u.b.b13, u.b.b14, u.b.b15,
u.b.b16, u.b.b17, u.b.b18, u.b.b19,
u.b.b20, u.b.b21, u.b.b22, u.b.b23,
u.b.b24, u.b.b25, u.b.b26, u.b.b27,
u.b.b28, u.b.b29, u.b.b30, u.b.b31);
}
int main(void)
{
union bitcontent_t u;
u.i = 0x12345678;
show_bitcontent(u);
u.i = 0xfedcba98;
show_bitcontent(u);
u.c[0] = 'U'; u.c[1] = 'N'; u.c[2] = 'I'; u.c[3] = 'X';
show_bitcontent(u);
return 0;
}
/* eof */
ken-1
Hideki Katoさんの<7edprr$7jp$1...@newsgw7.odn.ne.jp>から
>> 先に下位バイトを計算しつつ、上位バイトをメモリから取り出す、というこ
>>とでしょうか？
>
>いえ，そうではなくて，というか，実行はその通りなんですが，ポイントは
>ALU が 8 bit しかないので，下のバイトのフェッチ＆加算，上のバイトの
>フェッチ＆桁上げ＆加算の順で実行 (2 cycle) することにあります．
>
>逆順にすると，最後に桁上げの処理で 1 cycle 追加になってしまうのです．
下位バイトから桁上がりがある場合に、
下位どおしを足す -> 上位どおしを足して＋１
で済むか
上位どおしを足す -> 下位どおしを足す -> 上位に１を足す
としなければならないか、ということでしょうか。
>8008 -> 6800 -> 8080 -> Z80 -> 6809 の順だったような気もしますが．．．
わたくしの記憶でも、こうだったと思います。で、Z80 -> 8085 -> 6809。
ちなみに、このころにも多くの８ビット CPU があったはずですが、インテ
ル・モトローラ以外のベンダはどのような様子だったのでしょうか。
6502 はモトローラ似だったとして、TI や NS その他が覇を競っていた時代
なので、それぞれが独自の工夫をしていたはずですが。
ken-1
Masao Sekiさんの<370A360A...@gb3.so-net.ne.jp>から
>> 図を眺めながらいろいろと考えてみたのですが、わたくしが聞いた話は、
>> （16ビットワードに変えました）
>>
>> Littleendian:
>> ワード 0 1
>> ビット 151413121110 9 8 7 6 5 4 3 2 1 0151413121110 9 8 7 6 5 4 3 2 1 0
>> バイト 3 2 1 0
>> ビット 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
>>
>> Bigendian:
>> ワード 0 1
>> ビット 151413121110 9 8 7 6 5 4 3 2 1 0151413121110 9 8 7 6 5 4 3 2 1 0
>> バイト 0 1 2 3
>> ビット 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
>>
>> で、Littleendian の場合はワードアクセスでもバイトアクセスでも 0 ビット
>> 目が一致するのに対して、Littleendian だと一致しないというような意味だった
>> ような気がしてきたようなしてこないような…
>
>この図の見方が良く分からないのですが、16ビットワードなのにバイトのナンバ
>に２や３があるという事は、この記事の最初で述べた、私の訂正後のバイトナンバ
>と同じ性格の数字であると解釈してよろしいでしょうか。
そうですね、自分でもよくわかっていないのですが、関さんの訂正後の図と
同じ意味で書いたのではないかと思います。
Littleendian:
ワード 0 1
ビット 151413121110 9 8 7 6 5 4 3 2 1 0151413121110 9 8 7 6 5 4 3 2 1 0
バイト 1 0 1 0
ビット 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bigendian:
ワード 0 1
ビット 151413121110 9 8 7 6 5 4 3 2 1 0151413121110 9 8 7 6 5 4 3 2 1 0
バイト 0 1 0 1
ビット 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
と書きたかったのかもしれません。＜無責任発言。
>それで、ワードとバイトの間の方のビットのナンバと、バイトの数値は、図が示す
>通りの対応関係にある事を示しているのでしょうか。
>それとも、一番下のビットと同じく、MSBを左側に配置し、LSBを右側に置いただけ
>なのでしょうか。
>私には、0～15のビットが0の時、0～7のビットも0になっている対応しか、目に
>付かないのですが、それだとLittleendianもBigendianも同じになっているし・・。
>Littleendian で一致していて、Bigendianで一致していないのは、図のどの部分か
>教えて下さい。
この図だと、かえってわかりにくいのかもしれません。
たとえば、
Littleendian Bigendian
regA:ff regA:ff
regB:0000 regB:0000
0000:00 00 00 00 00 00 00 00 0000:00 00 00 00 00 00 00 00
というメモリマップで、$0000 番地に regA を書き込みます。
regA:ff regA:ff
regB:0000 regB:0000
0000:ff 00 00 00 00 00 00 00 0000:ff 00 00 00 00 00 00 00
次に、同じデータを regB で読み込みます。
regA:ff regA:ff
regB:00ff regB:ff00
0000:ff 00 00 00 00 00 00 00 0000:ff 00 00 00 00 00 00 00
と、Bigendian では、上位・下位バイトが入れ替わってしまいます。
>ちょっと尻切れトンボですが、間島さんの図がちゃんと理解出来てから議論を
>続けたいと思いますので、今日はこの辺で。
すみません。わたくし自身も自分の考えていることをよく理解していないよ
うなので、まして他人にわかるわけないですよね（謝）。
議論とおっしゃっても、こちらが教わる一方になると思いますが、それでよ
ろしかったらおつきあいいただけると幸いです。
YOSIDA Takayuki
片山＠ＰＦＵさんもフォローしている様に↓は間違いです。
Message-ID: <3704EEFB...@parkcity.ne.jp>
> void dump(const void *buffer, size_t nbytes)
> unsigned long l = 0xf1f2f300;
> dump(&l, sizeof l);
> あまり一般的でない例としては
> 000000f1
> なんて処理系もあることでしょう。
---
# これを書いた当時にどんな勘違いしていたのか自分でもわからない……
Masao Seki
Yasuki Arasaki wrote:
> Big-Endian (significanceの大きい方が低位のアドレス)
・
・
> # 例: PDP10、360。
PDP10てBigendianだったんですか。DECの製品はすべてLittleendianかと
思っていました。
> Little-Endian (significanceの小さい方が低位のアドレス)
・
・
> # 例: PDP11、ただし1ワード=16ビット。32ビット整数値や実数はワードが
> 逆順で入る。VAXは32ビット整数は上図の順だが実数はPDP11と同じく逆順。
VAXは整数と実数でendian特性が、一貫していない訳ですね。
#画像処理にVAX11/750(VMS)を5年ほど使った事がありますが、専らVAX-Fortran
#を使っていたので、全然気が付きませんでした。特別な工夫をしなくても、一般
#のFortranより高い performanceを示してくれたし、割と使い勝手も良く、気に
#入っていました。当時のＣは最適化のレベルが低く、画像処理にはチョットと
#いう感じでした。(80年代の終わり頃の話です。）
> ここでは暗黙の内にビット0=LSB、ビット7=(バイトの)MSBということ
> ですけど、この番号のふりかたは処理系によるんじゃないですか。
・
・
> ビットフィールド割り付け順序ならlittle-endianな処理系では
> LSBからMSB、big-endianな処理系ではMSBからLSBという順が
> 普通じゃないかと思います。
そうでしたか。確かに、お示し頂いた確認プログラムの結果を見ると、
最初のビットフィールドに割付られるビットが、big-endianか
little-endianかによって、MSBとLSBに別れていますね。これも、全然
知りませんでした。ビットオーダーに関しては、endianでは何も変わら
ないと云う、思い込みがあったようです。
ご指摘、どうもありがとう御座いました。
#それにしても、Littleendianでのワードやバイトとビットとの対応は、
#一見グチャグチャですね。目が回って来そう。
Takahiro Kambe
> Yasuki Arasaki wrote:
> > Big-Endian (significanceの大きい方が低位のアドレス)
> ・
> ・
> > # 例: PDP10、360。
>
> PDP10てBigendianだったんですか。DECの製品はすべてLittleendianかと
> 思っていました。
#define LITTLE_ENDIAN 1234 /* LSB first: i386, vax */
#define BIG_ENDIAN 4321 /* MSB first: 68000, ibm, net */
#define PDP_ENDIAN 3412 /* LSB first in word, MSW first in long */
と定義されています。
--
神戸 隆博, 株式会社ジェプロ(京都) / Takahiro Kambe, JEPRO Co., Ltd.
MAEDA Atusi
> Yasuki Arasaki wrote:
> > Big-Endian (significanceの大きい方が低位のアドレス)
> ・
> ・
> > # 例: PDP10、360。
>
> PDP10てBigendianだったんですか。DECの製品はすべてLittleendianかと
> 思っていました。
PDP-10ってちょっと特殊なんで，BigともLittleとも言えないと思っていまし
た．どう特殊かと言うと，
・メモリにはワード単位で番地が付いている(36bit word, 18bit address)．
・halfword操作はできるが，番地じゃない(L/Rと呼ぶ)．
でも新崎さんが紹介してくれた定義だとはっきりしますね．
・2つのレジスタ(アキュムレータと呼ぶ)をいっぺんにシフトする時は，ACnの
LSBがACn+1のMSBに入る．ACnは同時にメモリのn番地でもある．(つまりシフト
による定義ではBigendian)．
・Byteという言葉はPDP-10ではワード中の任意位置/任意サイズのビットフィー
ルドを意味する．このとき，位置0はLSBのこと．ILDB命令(Byteポインタを
インクリメントしながらロード; 文字列の読み出しに使う)では，位置を示
す値が *減らされて* いく．つまり語中のMSB側からLSB側へという順でByte
を取り出す．したがって文字列の置き方もBigendian．
前田敦司
Hideo Sir MaNMOS Morishita
ちゃちゃ。
"よろずや kin-chan" <kin-...@fsinet.or.jp> writes:
> これは、Littleendian
ここで
One little,two little,three little endian
と歌った人は近所のnative americanに謝罪するようにしましょう。
--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 ＭａＮＭＯＳ 英夫＠ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37
KATAYAMA Yoshio
Masao Seki <ma-...@gb3.so-net.ne.jp> writes:
>> # 例: PDP11、ただし1ワード=16ビット。32ビット整数値や実数はワードが
>> 逆順で入る。VAXは32ビット整数は上図の順だが実数はPDP11と同じく逆順。
>VAXは整数と実数でendian特性が、一貫していない訳ですね。
VAX は PDP-11 互換フォーマット、native(?) フォーマット、IEEE フォー
マットの３種類があり、PDP-11 互換フォーマット以外はマットウなリ
トルエンディアンになっています。
＃これは Alpha でも同じ
一貫していないのは PDP-11 であり、整数だけを見ても（一見）奇妙な
順序になっています。
>> ビットフィールド割り付け順序ならlittle-endianな処理系では
>> LSBからMSB、big-endianな処理系ではMSBからLSBという順が
>> 普通じゃないかと思います。
>そうでしたか。確かに、お示し頂いた確認プログラムの結果を見ると、
>最初のビットフィールドに割付られるビットが、big-endianか
>little-endianかによって、MSBとLSBに別れていますね。これも、全然
>知りませんでした。ビットオーダーに関しては、endianでは何も変わら
>ないと云う、思い込みがあったようです。
MC680X0 (X >= 2) のビットフィールド命令でも、上位ビットが下位ア
ドレスに割付けられているかのようになっていますね。
>#それにしても、Littleendianでのワードやバイトとビットとの対応は、
>#一見グチャグチャですね。目が回って来そう。
元記事の対応図は見ていない（目が勝手にスキップした :-p）のですが、
マットウなリトルエンディアンなら、下位バイト／ビットが下位アドレ
スになるだけで、マットウなビッグエンディアンと同様にすっきりして
います。
--
片山＠ＰＦＵ
Kazuo Fox Dohzono
# Followup-to: fj.sci.lang が良かったのかな.
In article <KATE.99A...@yamato.trad.pfu.co.jp>
ka...@pfu.co.jp (KATAYAMA Yoshio) writes:
> マットウなリトルエンディアンなら、下位バイト／ビットが下位アドレ
> スになるだけ
これって低位の桁の値を低位のアドレスに書くわけで, ごく自然な位取りなん
ですよね.
この話は遡ると位取りが伝達する途中での right to left な言語地方の表記
が発祥なのではないでしょうか. つまり little endian を“逆だ”と感じる
のは, 実はそれ以外の表記が逆なのでは (もしくは数字を輸入した時に引っく
り返すべきだったとか).
# 人間の指が左右 4 本ずつだったら良かったのに, と思ったことのある人は
# 居ませんか? :-)
--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp
[12],(6,9),0,0,2
(477/14730/27065)
Hideki Kato
fj.comp.arch と cross post, followup-to は fj.comp.arch にしました．
fj.comp.arch の方々へ：元々は byte order (endian) の話だったんですが，
Intel はなぜ little endian を採用したのか？ という話になり，16 bit
加算の時に 1 cycle 儲かるからではないか，と私が書いたことから，こう
いう話になって降ります．詳しくは fj.comp.lang.c をご覧下さい．
ken-1さんの<7efoej$5h7$2...@news00.iij4u.or.jp>から
> 間島ともうします。
> 下位バイトから桁上がりがある場合に、
> 下位どおしを足す -> 上位どおしを足して＋１
>
>で済むか
>
> 上位どおしを足す -> 下位どおしを足す -> 上位に１を足す
>
>としなければならないか、ということでしょうか。
その通りです．上位に１を足すのにも１サイクル掛かってしまいますから．
ご存知かも知れませんが，加算で一番時間が掛かるのは桁上げの処理です．
最悪の場合，一番下から一番上まで桁上げが伝播してしまいますから．同
期型の回路では，この最悪の場合に合わせてサイクルを決めなければなり
ません．
＃要するに，桁上げだけの加算でも，普通の加算と同じ時間を要すると言いたいのです．
>>8008 -> 6800 -> 8080 -> Z80 -> 6809 の順だったような気もしますが．．．
>
> わたくしの記憶でも、こうだったと思います。で、Z80 -> 8085 -> 6809。
>
> ちなみに、このころにも多くの８ビット CPU があったはずですが、インテ
>ル・モトローラ以外のベンダはどのような様子だったのでしょうか。
> 6502 はモトローラ似だったとして、TI や NS その他が覇を競っていた時代
>なので、それぞれが独自の工夫をしていたはずですが。
この情報を探していて手間取ってしまいました．結果として，手近には見つからず，
ＴＩ，ＮＳの 8 bit processor は名前さえ思い出せませんでした．ＴＩは後に 8080
の second source を出してたはずですが．
＃言い訳：この頃は丁度大学受験だったと思います．それに，当時はコンピュータの
＃アーキテクチャに興味を持って，ミニコンや汎用機については調べていましたが，
＃マイクロプロセッサなんてのはコンピュータではない，という認識だったんですね．
＃ハードウェアスタックを採用したのは，当然とは言え，斬新でしたが．
唯一覚えていたのは，今は亡き Fairchild の F8 というプロセッサです．これは
ちょっと面白かったので覚えているのですが，割り込み処理というか context switch
を高速化するために，register file を内部に持たず（内部に持つと，context switch
の時に memory に save しなければならず，当時の memory の cycle time では，軽
視できない時間を必要としたのです），memory 中への pointer を持ち，そこからの 8
だか 16 byte を registers として使用するというものです．この方式自体は新しいも
のではなく，16 bit ミニコンの FACOM-R，後のＴＩの 16 bit processor，TMS9900 で
も用いられていますが， 8 bit processorでは，多分これだけだったと思います．
これも記憶だけを頼りに書いているので，間違っていたら訂正よろしくお願いします．
もちろん，他の 8 bit processor に関してご存知の方も，よろしくお願いします．＞ＡＬＬ
Masao Seki
MAEDA Atusi wrote:
> PDP-10ってちょっと特殊なんで，BigともLittleとも言えないと思っていまし
> た．どう特殊かと言うと，
>
> ・メモリにはワード単位で番地が付いている(36bit word, 18bit address)．
> ・halfword操作はできるが，番地じゃない(L/Rと呼ぶ)．
>
> でも新崎さんが紹介してくれた定義だとはっきりしますね．
>
> ・2つのレジスタ(アキュムレータと呼ぶ)をいっぺんにシフトする時は，ACnの
> LSBがACn+1のMSBに入る．ACnは同時にメモリのn番地でもある．(つまりシフト
> による定義ではBigendian)．
> ・Byteという言葉はPDP-10ではワード中の任意位置/任意サイズのビットフィー
> ルドを意味する．このとき，位置0はLSBのこと．ILDB命令(Byteポインタを
> インクリメントしながらロード; 文字列の読み出しに使う)では，位置を示
> す値が *減らされて* いく．つまり語中のMSB側からLSB側へという順でByte
> を取り出す．したがって文字列の置き方もBigendian．
アレッ、ちょっと混乱して来ました。「BigともLittleとも言えない」とは、
或る見方をするとBigendianだけど、別の見方ではLittleendianになると云う
事ではないのですか。Littleendianになるケースが見当たらないのですが。
> ・Byteという言葉はPDP-10ではワード中の任意位置/任意サイズのビットフィー
> ルドを意味する．
これには、ビックリです。ちょっとどころでなく特殊ですね。でも、使いこなせ
れば、すごく重宝しそう。
Masao Seki
> ・Byteという言葉はPDP-10ではワード中の任意位置/任意サイズのビットフィー
> ルドを意味する．
--
Masao Seki
KATAYAMA Yoshio wrote:
>
> In article <370D5193...@gb3.so-net.ne.jp>,
> Masao Seki <ma-...@gb3.so-net.ne.jp> writes:
>
> >VAXは整数と実数でendian特性が、一貫していない訳ですね。
>
> VAX は PDP-11 互換フォーマット、native(?) フォーマット、IEEE フォー
> マットの３種類があり、PDP-11 互換フォーマット以外はマットウなリ
> トルエンディアンになっています。
>
> ＃これは Alpha でも同じ
>
> 一貫していないのは PDP-11 であり、整数だけを見ても（一見）奇妙な
> 順序になっています。
なるほど。3種類もフォーマットを持っていた訳ですか。過去の資産
の活用と、新機種としての最高性能の発揮と、国際規格への対応を
全て満足させようとしたのでしょうね。 （それで、満足させた事に
なるのかな？）
#なんだか、昔読んだVAXの開発を題材にした小説（？）を、また
#読みたくなってきた。捨ててはいない筈だけど・・・。
> >#それにしても、Littleendianでのワードやバイトとビットとの対応は、
> >#一見グチャグチャですね。目が回って来そう。
>
> 元記事の対応図は見ていない（目が勝手にスキップした :-p）のですが、
> マットウなリトルエンディアンなら、下位バイト／ビットが下位アドレ
> スになるだけで、マットウなビッグエンディアンと同様にすっきりして
> います。
それはそうなのですが、バイトオーダーを逆順にしたデータと、ワード
全体をビット反転させたデータを見比べる時、バイトの16進データの
上位と下位をさらに反転させて対応させなければならないので、一瞬
とまどうんです。まあ、これくらいでオタオタしているようでは、この
手の話題に参加する資格を疑われると云う所ですか。
MAEDA Atusi
> 関＠神奈川です。
>
> MAEDA Atusi wrote:
> > PDP-10ってちょっと特殊なんで，BigともLittleとも言えないと思っていまし
> > た．どう特殊かと言うと，
> アレッ、ちょっと混乱して来ました。「BigともLittleとも言えない」とは、
> 或る見方をするとBigendianだけど、別の見方ではLittleendianになると云う
> 事ではないのですか。Littleendianになるケースが見当たらないのですが。
バイト毎の番地が付いていないわけですから「1ワード内でバイトがどう並ん
でいるか」を考えても意味がないだろうと思っていたのです。だからBigとも
Littleとも言えないと思っていたわけです。
前田敦司
Nakayama Ryu~ji
Masao Seki <ma-...@gb3.so-net.ne.jp> さん、
> #なんだか、昔読んだVAXの開発を題材にした小説（？）を、また
> #読みたくなってきた。捨ててはいない筈だけど・・・。
コンピュータ開発の小説で有名なのっていうと、トレイシー・ギダーの「超マ
シン誕生(原題: The soul of new machine)」があるんですけれど、VAXの開発
ストーリってのも有ったんですか? ぜひ読んでみたいので、教えていただきた
いです。
ちなみに「超マシン誕生」はDataGeneralのEclipse MV/8000の開発ストーリで
した。その中でVAX-11の構造を探るシーンは有りましたが。
--
中山隆二
naka...@canary.sl.cae.ntt.co.jp
KATAYAMA Yoshio
In article <370EA069...@gb3.so-net.ne.jp>,
Masao Seki <ma-...@gb3.so-net.ne.jp> writes:
>それはそうなのですが、バイトオーダーを逆順にしたデータと、ワード
>全体をビット反転させたデータを見比べる時、バイトの16進データの
>上位と下位をさらに反転させて対応させなければならないので、一瞬
>とまどうんです。
なるほど。そういう見方をしてるのですか。それだと、私なら「一瞬」
では済みそうにありません。
普通のメモリーダンプなどでは、
0 1 2 3 …
XXXX: XX XX XX XX …
のように表示されますが、数値の場合は、
… 3 2 1 0
… XX XX XX XX :XXXX
のように表示方向を逆転して読めばよいのです。
--
片山＠ＰＦＵ
KATAYAMA Yoshio
In article <7eo8ns$ktp$1...@news2.na.rim.or.jp>,
doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:
>これって低位の桁の値を低位のアドレスに書くわけで, ごく自然な位取りなん
>ですよね.
何を中心に考えるかによると思います。
整数だけを考えれば、リトルエンディアンでは小数点がある位置が基準
になりますから、その意味では自然だと思います。
＃「メモリー領域を先頭番地で示す現在の計算機」を前提としています
しかし、固定小数点数や浮動小数点数の仮数部などを考えると、ビッグ
エンディアンの方が自然だと思います。
>この話は遡ると位取りが伝達する途中での right to left な言語地方の表記
>が発祥なのではないでしょうか. つまり little endian を“逆だ”と感じる
>のは, 実はそれ以外の表記が逆なのでは (もしくは数字を輸入した時に引っく
>り返すべきだったとか).
「位取りが伝達する途中での right to left」というのがよく分かりま
せん。
リトルエンディアンが逆だと感じるのは、数を上位の桁から読み、表記
もそのように行なう言語を使っているからだと思います。
算用数字を使った数の表現は（桁数や小数点を示す符号に多少の差はあ
りますが）ほぼ世界共通と言えると思いますので、これを基準に考えれ
ば、左から右へ書く言語（というか用字）を使っている人にとって、リ
トルエンディアンは逆と感じることになると思います。
--
片山＠ＰＦＵ
Masao Seki
アジャパー。
# この表現に違和感無く共鳴できる方は、かなりのベテランである事を認定致します。
# 何のベテランかと言いますと、人生のベテランです。
私が思い浮かべていたのは、まさにその「超マシン誕生」です。エーーーー、本当に
「超マシン誕生」は、MV/8000の開発ストーリなのですか。 いつの頃かは、定かで
ありませんが、私の頭の中で、VAXの開発ストーリに完全にすり替わっていました。
中山さんのフォローに対して、真っ当な答えが返って来る事を期待しておられた方には
大変申し訳ありませんが、私の完全な思い違いの様です。謹んで、お詫び申し上げます。
今夜中なので、本棚をゴソゴソあさる訳にも行かず、確認できませんが、納期が迫って
も予定した性能が出せず、禁じ手にしていたマイクロコードを使った実装を使い始める
辺り、非常に緊迫感があったような記憶があります。
# 良いのかな、件の本が発売になった直後に、一度読んだだけのいい加減な記憶を元に
# こんな事書いて。記憶が如何に当てにならないか、教えて頂いたばかりなのに。
VAXの開発ストーリ、有ったら私も読みたいです。ご存知の方、是非フォローをお願い
します。
Nakayama Ryu~ji
らへ。
Article <371210E2...@gb3.so-net.ne.jp> にて、
Masao Seki <ma-...@gb3.so-net.ne.jp> さん、
> Nakayama Ryu~ji wrote:
> > コンピュータ開発の小説で有名なのっていうと、トレイシー・ギダーの「超マ
> > シン誕生(原題: The soul of new machine)」があるんですけれど、VAXの開発
> > ストーリってのも有ったんですか? ぜひ読んでみたいので、教えていただきた
> > いです。
> >
> > ちなみに「超マシン誕生」はDataGeneralのEclipse MV/8000の開発ストーリで
> > した。その中でVAX-11の構造を探るシーンは有りましたが。
>
> 私が思い浮かべていたのは、まさにその「超マシン誕生」です。エーーーー、本当に
> 「超マシン誕生」は、MV/8000の開発ストーリなのですか。 いつの頃かは、定かで
> ありませんが、私の頭の中で、VAXの開発ストーリに完全にすり替わっていました。
がびーん。ぬか喜び。;-) ざんねんですぅ。
にしても、この手のノンフィクション小説はさすがに需要が少ないと見られる
のか、あまり見ませんね。
私はこの「超マシン誕生」と(ハードではなくてソフトですが)「闘うプログラ
マー(原題: SHOWSTOPPER!)」あたりしか読んだことがありません。
スピード感はそこそこあるし、読み物としてはそれほど悪くないと思うんです
が、この他でこういうコンピュータ関連の開発ストーリみたいなのをご存知な
方、ぜひお教えいただきたいなと思います。
# 「計算機屋かく戦えり」みたいなのは小説ではないので今回はちょっと範囲
# 外ということで。
--
中山隆二
naka...@canary.sl.cae.ntt.co.jp
Kazuo Fox Dohzono
In article <KATE.99Ap...@yamato.trad.pfu.co.jp>
ka...@pfu.co.jp (KATAYAMA Yoshio) writes:
> >これって低位の桁の値を低位のアドレスに書くわけで, ごく自然な位取りなん
> >ですよね.
>
> しかし、固定小数点数や浮動小数点数の仮数部などを考えると、ビッグ
> エンディアンの方が自然だと思います。
すいません, ここのところが良く判りません.
Q1) 固定小数点数は整数を一般化した場合ではないでしょうか.
Q2) 浮動小数点数の並びは利便が先にあるのではないでしょうか.
> 「位取りが伝達する途中での right to left」というのがよく分かりま
> せん。
こちらは酒のついでに昔どこかで聞いた冗談めいた話です.
位取り記法が発明された当初実はリトルエンディアンで表記されていて, アラ
ビア方面を経由してヨーロッパへ伝達する途中, たとえば「その数は百二十三」
つまり
.123 si rebmun eht
を輸入したときに数字を引っくり返し忘れたということはないのかな, という
意味です.
# あ, これも“指四本”と一緒で“そうだったらエンディアンの問題も無かっ
# たかも”という類いの話だった気が….
--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp
[12],(6,9),0,0,2
(410/13080/24119)
ロキシー
Masao Seki wrote:
> > コンピュータ開発の小説で有名なのっていうと、トレイシー・ギダーの「超マ
> > シン誕生(原題: The soul of new machine)」があるんですけれど、VAXの開発
> > ストーリってのも有ったんですか? ぜひ読んでみたいので、教えていただきた
> > いです。
> >VAXの開発ストーリ、有ったら私も読みたいです。ご存知の方、是非フォローをお願いしま
> す。
開発ストーリーにはほど遠いですが、VAXの話だったらやはりDECに
関する書物を...
ということでダイヤモンド社刊「究極の企業家」（ISBN4-478-32033-0）を
あげておきます。
しかし「超マシン誕生」ほどテクノロジに関する濃密な描写があるわけでは
ありませんので、あまり期待なさると見事に裏切られてしまいます。
どちらかと言えば、DECの歴史の中の1章として、VAXの開発に関わるエン
ジニアや上層部との人間的確執を描いたものです。
その他に興味深かったのは、天才エンジニア、エド・デ・カストロのあまりに
先進的な設計アイデアが経営陣に受け入れてもらえず、新しいPDPの開発
半ばでDECを辞め、自分の会社データ・ゼネラルを興すくだりです。
以上、ご参考までに。
--
ロキシー @ Love River 彩の国
KATAYAMA Yoshio
In article <7f1pmb$ins$1...@news2.na.rim.or.jp>,
doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:
>> しかし、固定小数点数や浮動小数点数の仮数部などを考えると、ビッグ
>> エンディアンの方が自然だと思います。
>すいません, ここのところが良く判りません.
> Q1) 固定小数点数は整数を一般化した場合ではないでしょうか.
> Q2) 浮動小数点数の並びは利便が先にあるのではないでしょうか.
“固定小数点数”というのはよくない表現した。固定小数点小数のつも
りでした。ここは、
しかし、固定小数点小数 や 浮動小数点数の仮数部 などを考えると、ビッグ
エンディアンの方が自然だと思います。
と読んで下さい。(_ _)
整数の場合、ビット番号を下位ビットから付けていくと、各ビットの重
みが“2**ビット番号”になりますので、リトルエンディアンが自然だ
と思います。
しかし、固定小数点小数 や 浮動小数点数の仮数部 では、上位ビット
からビット番号を付ければ、各ビットの重みが“2**-(ビット番号+1)”
になり、こちらの方が自然だろうということでした。
>> 「位取りが伝達する途中での right to left」というのがよく分かりま
>> せん。
>位取り記法が発明された当初実はリトルエンディアンで表記されていて, アラ
>ビア方面を経由してヨーロッパへ伝達する途中, たとえば「その数は百二十三」
やっと、「伝達」の意味がわかりました。実際のところは、どうなんで
しょうね。
--
片山＠ＰＦＵ
Kazuo Fox Dohzono
In article <KATE.99Ap...@yamato.trad.pfu.co.jp>
ka...@pfu.co.jp (KATAYAMA Yoshio) writes:
> 固定小数点小数 や 浮動小数点数の仮数部 では、上位ビットからビット番
> 号を付ければ、各ビットの重みが“2**-(ビット番号+1)”になり、こちらの
> 方が自然だろう
# 固定小数点小数 は 固定小数点数の小数部 かな.
片方が“下位ビットから…2**ビット番号”で, もう一方が“上位ビットから…
2**-(ビット番号+1)”というのはちょっと苦しい気がします. 隣り合ったビッ
トの関係はやはりどちらも“上位ビットが下位ビットの倍”ですし.
この場合“有効桁数が増える場合のビットの伸びる方向が整数と逆”というの
が自然に思わせる原因ではないでしょうか (あ, そういう意味で“何を中心に
考えるか”なのか).
--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp
[12],(6,9),0,0,2
(441/13783/25478)
Nakayama Ryu~ji
ロキシー <nas...@anet.ne.jp> さん、
> Masao Seki wrote:
> > >VAXの開発ストーリ、有ったら私も読みたいです。ご存知の方、是非フォローをお願いしま
> > す。
>
> 開発ストーリーにはほど遠いですが、VAXの話だったらやはりDECに
> 関する書物を...
> ということでダイヤモンド社刊「究極の企業家」（ISBN4-478-32033-0）を
> あげておきます。
ダイヤモンド社ですか。確か「超マシン誕生」もダイヤモンド社刊だった記憶
があります。こういうのが得意な会社なんですね。
まぁ、週刊ダイヤモンドとか見てれば分かるか。:-)
> その他に興味深かったのは、天才エンジニア、エド・デ・カストロのあまりに
> 先進的な設計アイデアが経営陣に受け入れてもらえず、新しいPDPの開発
> 半ばでDECを辞め、自分の会社データ・ゼネラルを興すくだりです。
おぉ、これは。ここからそっち(超マシン誕生)へつながっていくんですね。結
構忘れてること多いなぁ。
--
中山隆二
naka...@canary.sl.cae.ntt.co.jp
Mitsuhiro TAKEHISA
ちなみに、
これは VAX アセンブラの例で、こういう風に書きます。
マシン語の部分は、右から左に読みます。
数値（整数）計算させるとき、リトルエンディアンでは位上がりの処理が きれ
いにできます。
この点以外にも いろいろ、ゴードンベル氏 （VAX のアーキテクト） の先見性
は すごいと感心させられるところがありました。
VAX は 308 のマシン語命令があり、一番最初の VAX-11/780 から 20 年後（最
後？）の VAX 7000 まで変っていません。
20 年間経って、CPU の設計が変わってもマシン語命令の追加が全くなかった
CPU も めずらしいです。
マシン語 番地 行 ニーモニック
0000 0000 1 .entry main,^m<>
52 94 0002 2 clrb r2
53 B4 0004 3 clrw r3
54 7C 0006 4 clrq r4
55 7CFD 0008 5 clro r5
000B 6 $exit_s
67 66 65 64 63 62 61 0014 7 .ascii "abcdefg"
001B 8 .end main