http://www.computer50.org/kgill/mark1/RobertTau/turing.pdf [computer50.org] > Wilkes includes an anecdote of Turing doing little-endian arithmetic on a chalkboard during a conference talk, to the general befuddlement of the other researchers in attendance.
インテルの (スコア:1)
Re:インテルの (スコア:1)
Re:インテルの (スコア:1)
VAX も Alpha もリトルエンディアンでしたよね。
# 大昔、確か SUN だったと思うけど、
# 他社製のプロセッサにエンディアン切り替え機能があるのを指して、
# 「他社にはエンディアンの異なるレガシー製品をサポートする必要があるからです」
# とかどこかに書いていたような。
Re: (スコア:0)
6800はビッグエンディアンだが、68系と言われることもある6502はリトルエンディアンだしね。
16032とV60もリトルエンディアン。
TRONチップは、本人はリトルエンディアンでやりたかったらしいが産業界からの反発によりビッグエンディアンに。
ARMもリトルエンディアンだったが、アップルからの要請によりビッグエンディアンに対応。
http://www.tronshow.org/2009/j/exhibitor/01/index.html [tronshow.org]
SPARC,PAはビッグエンディアン。
MIPSは最初からバイエンディアンかな?DECStation3100(R2000です)はリトルエンデ
Re:インテルの (スコア:1)
8086のセグメント方式は納得ですが、リトルエンディアンがそんなに致命的な方式とは思えないがなぁ。
Re:リトルエンディアンこそ正しいバイトオーダー (スコア:2)
ビッグエンディアンなら、ビット位置の指定もMSBからにしないと一貫性がないですよね。確か68020だったかのビットフィールド命令 (バイト境界をまたいでビット位置を指定する) が、通常と逆だった気がする。
Re: (スコア:0)
知能が足りない者としては、ビッグエンディアンの方がハンドアセンブルがやり易くて有難かった。
# リトルエンディアンにするなら、TMS34010 みたくビットオーダーまでリトルエンディアンにしといてくれないと:-p
Re:リトルエンディアンこそ正しいバイトオーダー (スコア:1)
チューリングは講義では数値をリトルエンディアンで書き(百二十三を321)、聴衆を閉口させたという話。
http://www.computer50.org/kgill/mark1/RobertTau/turing.pdf [computer50.org]
> Wilkes includes an anecdote of Turing doing little-endian arithmetic on a chalkboard during a conference talk, to the general befuddlement of the other researchers in attendance.
Re: (スコア:0)
#1589149 [srad.jp]にもありますけど,低い番号のビットに低位桁の値が入っている (通常の) ビット数え順こそが,リトルエンディアンとの一貫性が高いと思うのですが.
TMS34010 を知らないので,頓珍漢なことを言っていたらすみません.
Re: (スコア:0)
うん。君が正しい事を言っていることは認めよう。
だがしかし、それでも
人類は全員知能が足りないから、全ての状況でビッグエンディアンを使うべきなんだ。たとえば、バイトストリームがネットワークに流れる場合を考えてみよう。
小さい桁から流れてくるリトルエンディアンの方が読み取りやすくって処理効率がいいって?
それは違うんだ。たとえば 1byte の長さを 16bit のマシンが混在したとしても、
ビッグエンディアンの場合はそのまま読めば、ストリームイメージに変更をしなくて済む。
変更がない……これはなんて素晴らしい響きをもつ言葉だろうか?
そう、全てのPCは、そのまま bit 数を増やして行けば、そのまま拡張されて行く事になるのだ。
# 結果として、1byte が 64bit のPCができました。
Re: (スコア:0)
セグメント方式がダメなのではなくて、セグメントサイズの上限が64KBしかなかったことが問題でしょう。
現代のCPUでもセグメントに類する機構が存在することは珍しくありません。セグメントではなくGlobal Pointerとか呼ばれてるだけで。むしろ一切存在しないのはx64くらい。
Re:インテルの (スコア:1)
あれって今想像するに, コンカレントCP/M [wikipedia.org]みたいに1プロセスあたり64KBの空間(それで十分だと思っていた)を並列して効果的に動かすための機構として想定していたんじゃないかと思います. まさか単一のプログラムが64kBを超えるコードやデータを取り扱うことは無い. 一般プログラマが直接セグメントを管理することはなく, OSにまかせるものだと.
誤算だったのは, 8086用OSにセグメント管理を効率的にこなせるような高級なものが広まらなかったってことと, 画像処理みたいなメモリ空間を要求する用途が急激に広がったってことでしょうね.
Re: (スコア:0)
> まさか単一のプログラムが64kBを超えるコードやデータを取り扱うことは無い.
単一の64KBを越えるメモリブロックを取り扱うことはない、ですね。8086でもESを用いた任意の外部メモリブロックへのアクセスが想定されています。
80x86のセグメント方式は、大型計算機などでポピュラーだったものがiAPX432経由で取り込まれたものです。(iAPX432も64KBセグメントでした)
80286については以下のページが詳しいのでご覧ください。80286が保護仮想アドレスモードから実アドレスモードへ移行できない理由もお分
セグメントも使われたとしても失敗していると思われます (スコア:0)
今見れば、セグメントもオフセットも絶対的に足りていないような気がします。
Re: (スコア:0)
80386で32ビット(4GB)セグメントが導入されましたが。セグメントサイズが64KB単位になり悲しく思いました。
初期のlinuxでも80386のセグメントが使われていました。現在の32ビット版Windowsでもセグメントは使われています。
> 今見れば、セグメントもオフセットも絶対的に足りていないような気がします。
今から見れば、どんな設計にもケチをつけられますよ。だから当時の致命的なデザインミスかどうかの話をしているわけで。
Re: (スコア:0)
セレクタの仮想化は容易ですし、4GBセグメントがあれば1プロセスが64KBセグメントをたくさん使うということもなくなりますので、セレクタのスラッシングの心配は不要だと思いますよ。
※セレクタはオープンしているファイルハンドルにおおむね対応します。
Re: (スコア:0)
なしてMSBがbit0なん?ぜってーIBMだ!こんなわけわかなこと考えやがったのは!!
#Cellのエンディアンがビッグなのかリトルなのか未だにわからん…
Re:インテルの (スコア:1)
Re: (スコア:0)
大きいことはいいことだ
アメリカの伝統
そういえば、MZ2000のVRAMは画面の左がbit0でした。つまり他機種と逆。
Re: (スコア:0)
それは勘違いかと (スコア:0)
やりこめばやりこむほど、問題が噴出します。
ビッグエンディアンが便利になるのはビットフィールド的操作の時だけです。
セグメントが問題であるところは否定しません。