日記みたいな何か

コメントに書くと長そうなのでこっちにー．団子厨さんから以下のようなコメントを頂きました．

> 128ビットアラインメントされてないアドレスをロードすると
> 下位４ビットが無視される。

> 128ビット境界を跨ぐデータをロードする場合、2回ロードを発行して、
> それぞれ右シフト＋左シフトして重ね合わせることになる。
> この際、シフト命令が補数をとる形式だと下位4ビットがそのまま使うことが
> できる。

おお！なるほど！ それは考えたことがなかった！ というわけで早速試してみたんですが，ちょっとうまくいかないっぽいです (´・ω・｀)

アドレスをシフト値に使うということなので，ビットで指定する spu_rlmaskqwbytebc ではなくバイトで指定する spu_rlmaskqwbyte の話になるかと思うんですが，たとえば以下のコードでbuf の中の「CDEFGHIJKLMNOPQR」を1個のレジスタに読み出したいようなシチュエーションでの利用ということでいいんですよね？

char buf[] __attribute__((aligned(16))) = "ABCDEFGHIJKLMNOP"
                                          "QRSTUVWXYZabcdef"
                                          "ghijklmnopqrstuv"
                                          "wxyz";
vec_char16 v, vp, v1, v2;
vp = (vec_char16 *)(buf + 2);
v1 = vp[0];
v2 = vp[1];

// ビッグエンディアンなので1個目を左シフト，2個目を右シフトする
v = spu_or(spu_slqwbyte(v1, (int)vp),
           spu_rlmaskqwbyte(v2, (int)vp));

残念ながら，これはうまくいかないっぽいです．動かすと，vの中身は「\0\0\0\0\0\0\0\0\0\0\0\0\0\0QR」か「CDEFGHIJKLMNOP\0\0」になってしまいます．

シフトの大きさは (bufのアドレス + 2) としていますが，これは (16の倍数 + 2) になっているので，左シフトでも右シフトでも下位4bitしか見ないのであれば「2」を指定したのと同じになるはずです．

が，実際は，spu_rlmaskqwbyte は指定されたシフト値の符号を反転した後，下位5bitを取り出して，その数分右シフトします．また，バイト単位で左シフトする命令の spu_slqwbyte も同じように下位5bitを使います．なので，上記コードでは，シフト値として「2」が渡されるとは限らず，bufのアドレス次第では「18」になってしまう可能性があります．

で，18 になってしまうと，18 バイト左シフトされた1個目の値は全部 0 で埋まってしまいます．右シフトの方は「-14」を指定したのと同じことになるので14bit右シフトしてくれて丁度いいのですが・・・．

また，vpの下位5bitが 18 でなく 2 だった場合，左シフトは 2バイトでいい具合なんですが，今度は右シフトが「-30」を指定したのと同じ扱いになってしまい，結果が全部 0 で埋まってしまいます (´・ω・｀)

というわけで，アドレスをそのまま使って2回に分けてロードしたベクタの合成には使えないかなーという感じなのですが，どうでしょう・・・．わざわざ5bit分使うのは16バイトの右シフトにも対応させたかったからなんですかね・・・．うーん．

あと，ここまで書いて気がついたんですが，SPEではそういう必要が生じたらシャッフル命令を使ってこんな風にやるのが普通なのかもしれません．

char buf[] __attribute__((aligned(16))) = "ABCDEFGHIJKLMNOP"
                                          "QRSTUVWXYZabcdef"
                                          "ghijklmnopqrstuv"
                                          "wxyz";
vec_char16 v, vp, v1, v2;
const vec_uchar16 vshuf2 = (vec_uchar16){ 2,  3,  4,  5,  6,  7,  8,  9,
                                         10, 11, 12, 13, 14, 15, 16, 17};
vp = (vec_char16 *)buf;
v1 = vp[0];
v2 = vp[1];

v = spu_shuffle(v1, v2, vshuf2);

12月9日版のG-HAL氏パッチを当てたAnthyを使っているわけですが，恐ろしいパターンを発見してしまいました．

「そのでばいすに」を変換すると，普通は「その + デバイスに」になってくれると思います．が，うっかり間違えて文節を伸ばしてしまって「園で + 倍すに」とした上で1回確定してしまうと，その後何度文節を直して確定しても「そのでばいすに」→「園で + 倍すに」で固定されてしまいます・・・．

今んとこ復帰するには last-record2_default.utf8 をエディタで開いて「園で」とかを探して手で消すしかないような．うーむ，うまいこと設定で回避できないものか・・・．他の人どうっすかねー．まあ，覚えてくれないよりは遥かにいいのかも知れませんがｗ

ちょこちょこいじってたらちょっとスコアが伸びました．でも何でこれで伸びるのかさっぱりわかりません．むしろ遅くなっておかしくない筈なのに(;´Д`)

ところで spu-gcc の組み込み関数の一覧見てて気になったんですが，spu_rlmaskqwbytebc って何のためにあるんですかね．spu_slqwbytebc とかだと spu_slqw とあわせて1〜128ビットの左シフトとかに使えそうだけど， spu_rlmaskqwbytebc は負の数で指定しないといけないという謎仕様のせいで spu_rlmaskqw と組み合わせてもきれいに右シフトに使えないっぽいんですよね・・・．simdmath 見ても使われてないようだし．謎だ・・・．

昨日の続き．Fedora 9 を Vmware 上にクリーンインストールしてみました．HDDイメージを作るのが面倒だったので Windows の方の VMware で使ってる奴をコピーしてフォーマットし直してつかうことに．

順調にインストールが進むも，インストール後 yum update を始めたところでなにやら異変が．T60 が全体的にやたらと重い・・・なんだこりゃ．・・・アッー！ SWAP が 500M も使われているぞ (;´Д`)

VMwareのゲストOSにうっかり1Gもメモリを割り当ててしまったせい？ とりあえずあれこれホストの Linux 側のプロセスを落としまくってどうにか 300M くらいまでに減らしましたが，ここから先はもう落とせるものがない状態 ｗ．くそー．で，結局その後数時間耐えてどうにか完走はしたんですが，こりゃ途中で止めてWindows側のVMware に移してやり直した方が速かったぽいなぁ．不覚・・・．

いやしかし，インストール直後で大して中身も入っていないはずの状態なのにディスクが 18G もあるのはどうなのかと．いやそもそも勝手にシュリンクされたりはしないのかな．手を抜いてコピーしてきたディスクイメージを使いまわしたのも失敗だったか・・・orz

そんなわけでどうにか縮める方法はないものかと探してみたら vmsrinkというのを発見．これはすごそう．

早速ゲストOS上にダウンロードしてコンパイルして実行．最初にデフラグっぽいことをしているのか，数字がぐるぐると回ります．・・・ずいぶん待たされますな・・・ってなんか別のワークスペースでVMware Playerがエラーを吐いているぅ (VMware 上の Fedora にsshでログインして作業してたので気づかなかった)． なになに，作業をするのに十分なディスク領域がないだと (;´Д`)？ 失敗してたのね・・・orz

仕方ないのでイメージをWindows側にコピーして，Windows の VMware Player 上で再挑戦することに．こっちはHDDの空きが十分あるんでばっちり縮小に成功．3Gくらいになりました．これを再度 T60 側に持ってきてようやく環境構築完了．ふー．HDD買い換えようかな・・・

なぜか最近 (実は前から？) VMware 上の Fedora で上げてるXサーバに mlterm の窓を飛ばすとマウスのダブルクリックやトリプルクリックでの文字列の選択が100% 失敗するようになってしまいました．まあマウスでじっくり選んでやれば大丈夫だったのでとりあえず放置してたんですが，今日になってこれだとちょっと不便な事態が発生したので適当に追ってみることに．

ダブルクリックとか検出してそうなところをgrepして追って行ったらそれっぽいところに到達．むう，マウスのリリース処理が怪しいな・・・．というわけで適当にコピペしてみたらあっさり直ってしまいました．これはラッキー．どんな副作用があるかわかりませんが，↓で今んとこ普通に使えてます．

--- xwindow/x_screen.c.org
+++ xwindow/x_screen.c
@@ -3517,6 +3517,18 @@
                        yank_event_received( screen , event->time) ;
                }
        }
+        else if( win->click_num == 2 && event->button == 1)
+        {
+                /* double clicked */
+
+                selecting_word( screen , event->x , event->y , event->time) ;
+        }
+        else if( win->click_num == 3 && event->button == 1)
+        {
+                /* triple click */
+
+                selecting_line( screen , event->y , event->time) ;
+        }

        x_stop_selecting( &screen->sel) ;
        highlight_cursor( screen) ;

今までT60には VMware Workstation 5.5系が入っていたんですが，新しいのが使いたくなって VMware Player に入れ替えてみることにしました．が，インストーラをダウンロードして実行しするもまったくインストールできず・・・．一応データの展開は行われるっぽいんですが，展開が終了したところで落ちます．落ちるときに律儀に展開したテンポラリのデータを消してくれるので，何が原因で落ちているのかさっぱりわからん (;´Д`)

あれこれ試しているうちに環境変数で LD_LIBRARY_PATH=/usr/local/lib を設定してやると上がることが発覚 (/etc/ld.so.confが空なので標準で/usr/local/libは見にいかない)．あー，インストールにX使ってるのね (;´Д`)

が，しかし，まだインストールがうまくいっていないっぽい．文字コードがどうこうみたいなメッセージが表示されていたのでググってみるも，ヒットするのはロシア語のページばかり．なんじゃこりゃ・・・ロシア人だけがハマる？ ・・・LANGかな？ 試しに LANG を C にしてインストーラを起動してみたらばっちり．ようやくインストールできましたよ．何て難しいんだ (;´Д`)

その後 /dev/vmmonを作ったり，起動スクリプトにLD_PRELOADを書き足してX関連のライブラリを事前に読み込んでおくようにしたりしてどうにか VMware Player 自体も起動するようになりました．はぁ．

昨日のがさらにパワーアップしていました．早速組み込んで昨日と同じ環境で測定．

数パーセントとはいえさらに伸びてますね．恐るべし・・・．

いまさら聞けないライセンスの疑問．

• あるWebサイトで，とあるツールのソースと，そのソースへのパッチが公開されている
• ツール自体は，別所でコミュニティベースで開発されているオープンソースなもので，ライセンスはGPLとなっている
• パッチに関しては特にライセンスに関する記述が見当たらない
• 同じWebサイトでそのツールのバイナリパッケージ (RPMファイル) とソースパッケージ (SRPMファイル) も配布されている
• その SRPM ファイルを展開すると，そのツールのソースとパッチとSPECファイルが出てくる
• その SRPM ファイルを rpm -qpi すると「License: GPL」と出る
• 同様にその RPM ファイルについても，rpm -qpi すると「License: GPL」と出る

こういう状況で，RPMファイルやSRPMファイル，パッチなどの著作権者でない人間が RPM ファイルや SRPM ファイルの再頒布を行うことはライセンス的に可能なんでしょうか？ もちろんオリジナルのファイルに一切の改変を加えることなく無償でやるとして・・・．