10進数に直せばこれは197である。これでは論点が分かりにくいかもしれないので、プログラムで表してみる。bs[i];という計算でビットストリームをデコードできるというわけである。bs[i];ということになる。エンコードされた数値をデコードするという作業はきわめて基本的なものであって、そのプログラムをリトルエンディアンならすっきり書けるというわけである。2のベキの指数部分の数値とバイトストリームのインデックスが同じだというのはシンプルでとても気持ちがいい。なんていう式は、全体が8bitだと分かっていなければ書けない式である。リトルエンディアンならそんな情報は要らなくて、ただビットストリームの終わりまで計算すればそれでOKなのだ。自分はビットストリームなんて扱わない、バイト列で十分だ、というかもしれない。エンディアンの美しさはバイト列しか扱わなくても同じように現れる。僕は以下のようなビッグエンディアン向きのデコード方法も知っている。bs[i];しかしなんというか、これはプログラミングテクニック的な問題である気がする。これは必ず前からデコードしなければいけない。ビットストリームが乱れてbs[0]から順番には届かず、先にbs[4]がきて、次にbs[1]が来て、みたいなことがもしあっても、とりあえずbs[0]が到着するまではこの方法ではデコード計算を開始できない(ビットストリームが乱れても、それがビットストリームのどの部分であるかの情報は、いっしょになって到着するとする・・・乱れるかもしれない状況ではそうやってパケットを作るのが基本である)。方式であれば、とりあえず届いたパケットから処理してsに加算していくことが可能である。いう意味でより基本的なデコード方法であると僕は信じる。リトルエンディアンによるビットストリームは、僕たちの数値表現とは逆方向なので読みにくい。それは僕たちのほうが間違っているのではないかと思う。読まずに「三・二十・百」と読めばいいではないか。みたいに桁を数える必要がない。気にせず左から読めばいいのだ。足し算をやる場合も「左から右へ」処理していくことができる。これは左から右へ文章を書くという方式と非常に合っている。アラビア語は右から左へ書いていくそうだけど、それなら数値も"123"でいいだろう(アラビア語で数値を"123"と書いているのかそれとも"321"と書いているかは知らないけど)。いうか123みたいな記法はアラビア数字とかいうから、もしかしたらアラビアでは「正しい」方向に書いていたのかもしれない。これがヨーロッパに伝わるときに、自分たちの記述方向に合わせて向きを反転しなかったのかもしれない・・・この推測が合っているのかどうかはわからないけど。とまあ以上のような考えを僕は以前から持っていて、だからリトルエンディアン派だったのでした。ビッグエンディアンの合理性そんな僕だったのですが、先日ビッグエンディアンもいいなと思うことがあって、それならいっそビッグエンディアンのほうが本質的だとこじつけることはできないだろうか、なんて空想をしてみました。初めは飽くまでもリトルエンディアン派が「かわいそうだからビッグエンディアンを慰める」みたいな感じだったのですが、だんだんビッグエンディアンこそ本質的かもしれないと思えるようになり、今ではすっかりビッグエンディアン派です。そのことを以下に書きます。ヘッダのあるビットストリームをバイト列に格納して、このヘッダを判定したいとする。かのどれであるかを判定したいとしよう。こんなとき、もちろんANDして比較するというのが普通の書き方だ。*/これはこれで妥当なのだ。ビッグエンディアン用に書き直しても同じようにANDして比較するように書ける。ビッグエンディアンなら次のようなテクニックも使える。*/つまりANDがいらない。その分だけ判定が速くできるというわけだ。値をレジスタに保持しておけば一度しか計算しなくて済む。一度もANDしないで済むビッグエンディアンの方法はもっと有利に見える。こんなビット列判定なんて回路的には簡単だから、専用の命令をCPUに持たせればいいという考え方もできる。今までは(これからも?)ニーズがなかったからそのような命令をCPUがもっていないだけなのだと。ビッグエンディアンであれば、そのような専用命令を新設する必要はなく、普通の符号なし比較命令で代用できるのである。リトルエンディアンではビットストリームにおけるフッタを比較命令だけで判定可能である。それは果たしてどれだけ実用的だろうか。ビットストリームは後ろから読む場合よりも前から読む必要のほうが断然に多いのではないだろうか。前から感じていたことに、日本と欧米の住所の書き方の違いがある。