NAKAMURA Minoru の日記 (2006年8月)

[CPU][Prog] IA-64/Linux の sigcontext は gr32 番以降のレジスタが不足している

UNIX 系 OS はシグナルハンドラ中や getcontext で実行コンテキストの保存ができる。 これを使って割り込みが起こった時に、 割り込み元のコンテキストのレジスタを書き換えると言ったプログラムテクニックが可能だ。

しかし IA-64/Linux はちょっと妙だ。 128本ある汎用レジスタのうち回転しない最初の 32 本は sc_gr[] に記録されるのだが、 レジスタスタック分の gr32 〜 gr127 番までのレジスタが sigcontext 中に保存されていない。 このような場合、 レジスタスタックのバッキングストアに格納されていると考えられるのだが、 sc_ar_bsp は gr32 の位置を指していない。

struct sigcontext
{
  unsigned long int sc_flags;   /* see manifest constants below */
  unsigned long int sc_nat;     /* bit i == 1 iff scratch reg gr[i] is a NaT */
  stack_t sc_stack;             /* previously active stack */

  unsigned long int sc_ip;      /* instruction pointer */
  unsigned long int sc_cfm;     /* current frame marker */
  unsigned long int sc_um;      /* user mask bits */
  unsigned long int sc_ar_rsc;  /* register stack configuration register */
  unsigned long int sc_ar_bsp;  /* backing store pointer */
  unsigned long int sc_ar_rnat; /* RSE NaT collection register */
  unsigned long int sc_ar_ccv;  /* compare & exchange compare value register */
  unsigned long int sc_ar_unat; /* ar.unat of interrupted context */
  unsigned long int sc_ar_fpsr; /* floating-point status register */
  unsigned long int sc_ar_pfs;  /* previous function state */
  unsigned long int sc_ar_lc;   /* loop count register */
  unsigned long int sc_pr;      /* predicate registers */
  unsigned long int sc_br[8];   /* branch registers */
  unsigned long int sc_gr[32];  /* general registers (static partition) */
  struct ia64_fpreg sc_fr[128]; /* floating-point registers */
  unsigned long int sc_rbs_base;/* NULL or new base of sighandler's rbs */
  unsigned long int sc_loadrs;  /* see description above */
  unsigned long int sc_ar25;    /* cmp8xchg16 uses this */
  unsigned long int sc_ar26;    /* rsvd for scratch use */
  unsigned long int sc_rsvd[12];/* reserved for future use */

  /* sc_mask is actually an sigset_t but we don't want to
   * include the kernel headers here. */
  unsigned long int sc_mask;    /* signal mask to restore after handler returns */
};

いろいろ調べた結果、 sc_ar_bsp - (入力レジスタ数) × 8 バイトの位置から gr32 が格納されている。 入力レジスタ数は関数の引き数の数で決まるのだが、 呼び出し元関数の構造に関する情報は sigcontext には保存されていない。 どこから情報を持ってくれば足りるのだろうか？

追記：9/1

基本的には sc_ar_bsp から sc_cfm.sof を引いた ポイントが gr32 レジスタの位置になるのでいいようだ。 ただしレジスタスタックを 63 本退避するごとに NaT コレクションレジスタを挟み込むので、 計算がややこしくなる。

libunwind ライブラリを参照すると、 以下のような補正関数を準備する必要があるとある。

unsigned long ia64_rse_slot_num (unsigned long *addr) {
    return (((unsigned long) addr) >> 3) &0x3f;
}

unsigned long* ia64_rse_skip_regs (unsigned long *addr, long num_regs) {
    long delta = ia64_rse_slot_num(addr) + num_regs;
    if (num_regs > 0)
        delta -= 0x3e;
    return addr + num_regs + delta/0x3f;
}

シグナルハンドラの中で、 シグナル発生元関数の gr32 〜 gr34 以降のレジスタを参照したい場合は 以下のように書ける。

unsigned long* bsp;
long sof, gr32, gr33, gr34;

sof = uc->uc_mcontext.sc_cfm & 0x7fUL; 
bsp = ia64_rse_skip_regs (uc->uc_mcontext.sc_ar_bsp, -sof);

flushrs(); 

gr32 = *bsp;
gr33 = *ia64_rse_skip_regs(bsp, 1);
gr34 = *ia64_rse_skip_regs(bsp, 2);

当然ながらシグナルの発生元で gr32 〜 gr34 のレジスタが使えるように alloc 命令を設定する必要がある。 発生元で使用していないレジスタを RSE BS から参照しようとするのは危険だ。

[Food] 一六タルト (六時屋)

愛媛と友人から六時屋の「一六タルト」をいただく。

タルトと言っても tarte ではなく taart。 餡をカステラで巻いたオランダ菓子です。 餡子が素晴らしく甘いです。

[Bench] SPEC CPU2006 が登場 (CPU2006)

SPEC CPU2004 が延期されて以来幾星霜、 ついに CPU2006 が登場した。 ベンチマーク数は CINT2000が 12 個 (C 言語で書かれたものが×11個と C++ ×1個)、 CFP2000が 14 個 (Fortran77 ×6個と Fortran90 ×4個と C言語×4個) だったのが、 CINT2006が 12個 (C 言語×9個と C++ ×3個)になっている。C++ が増加した。 CFP2006は全部で 17 個のベンチマークで、 Fortran Only が 7 個、C言語 Only が 3 個、 コア部分だけ Fortran で書いて周辺部分は C 言語で書いたものが 3個、 C++ 言語で書かれたものが 4 個になっている。 Fortran95 のコードも登場。

今回の基準マシンは Sun Ultra Enterprise 2 (296MHz UltraSPARC II) になっている。 前回(CPU2000)の基準が Sun Ultra5_10 (300MHz) だったので、 ほとんどベースに差がない。 すでにスコアを登録したマシンを見ると Ultra Enterprise 2 に1桁以上の差をつけているものばかり。

まだ詳しく見ていないが、 CPU2000 と比べてデータセットがぐ〜んと拡大されていると聞いている。 最近のプロセッサはキャッシュが大きくなりすぎて、 ベンチマークのワーキングセットがそのキャッシュ内に収まってしまうこともある。 そのため「実機」の性能測定を公平化するにはデータを大きくしないとダメなんだろう。

一方、 プロセッサ開発を行うアーキテクチャ屋は、 シミュレーションを行う対象として SPEC CPU を長らく使ってきた。 彼等にしてみれば CPU2000 ですら規模が大きすぎて扱い辛くて、 これが膨れ上がるとますます使い辛いものになっていくようだ。 もっともアーキテクチャが収斂した 21 世紀という時代には、 死に絶えつつあるマイクロアーキテクチャ屋の都合なんて どうでもいいのかもしんない。

今のところスコア登録されたのは IA-32/AMD64 系の石と Ultra SPARC だけ。 今後は Itanium2 と POWER 系ぐらいしか参入してこないだろうから、 マイクロアーキテクチャ間で優劣を競うといった醍醐味はもうないだろう。

[Bench] さようなら SPEC CPU2000 (CPU2000)

ついでに最後になるだろう CPU2000 ウォッチ。 前回は 4/13

前回に Opteron 系が SPECint2000 で 2,000 越えをしたと思ったら、 Intel Core2 系はあっさり 3,000 越え。 ついでに SPECfp2000 も POWER5+ には及ばないもの 3,000 台をキープ。

IBM POWER5+ はクロックを 2300MHz まで伸ばして fp2000 が 3,600 台を達成。

新顔の Montecito 系の Itanium2 は微妙にスコアを伸ばすも、 ほとんど成長なし。

今回の分で Intel x86、AMD x86、Itanium、POWER5 がマルチコアになった。 黄色のセルは並列コンパイラを使ったマルチコア最適化の結果で、 4 コア構成で POWER5+(2100MHz) / AIX で 20%、 Opteron (3000MHz) / Solaris で 40% ほど上がっている。

しかし、 いろいろ思い返してみると SPEC CPU2000 の歴史は マイクロアーキテクチャの没落の歴史だよな。 失われた CPU に追憶を。

研修から帰還

火曜日から三泊四日の会社の研修へ行っていたが、 ようやく帰還。

とりあえず御飯のマトリックスを表示。

	朝	昼	晩
8/22 (火)		牛肉のソテー	豚の生姜焼きとポテトサラダと魚
8/23 (水)		かき揚げ丼	鰤の照り焼きと温泉卵のナニカ
8/24 (木)		秋刀魚と冷やしうどん	鶏の唐揚げの餡かけ
8/25 (金)	右はジャガイモの冷製スープ	鳥カツ

[Food] 鳥勢＠名古屋 (公式)

本日は仕事で名古屋に出張。 ついでに井手さんを名大に表敬訪問してきました。

研究室にはウォンバットの人形が常備されていました。

この後二人で栄の焼き鳥屋さん「鳥勢」へ。 この店は朝絞めた鶏だけを出すお店だそうです。

お店の暖簾です

サンシャイン栄の真ん前

前菜のキャベツ	コーチン鳥刺	冷奴	皮
つくね	せせり	コーチン(手前) & 軟骨(奥)	ささみ(手前) & ぼんちり(奥)
梅ささみ	お茶漬け

名古屋コーチンの焼き鳥はジューシーで柔らかくてうま〜。 玉子をといてタレを掛けて食べるつくねも美味です。

追記：8/20

井手さんからの情報でメニューが判明。

停電

終電間際の「のぞみ」に飛び乗って新横浜経由で帰還。
途中、雷がピカピカと空を照らしていたが、 ようやく帰宅してパソコンの電源を入れたと思ったら、 ピカ〜ゴロゴロと鳴って部屋の電源が一斉に切れる。

[MyWeb] nminoru.jp の JP ドメイン管理

nminoru.jp は Domain 21 というレジストラで登録していたのだが、 Domain 21 の運用元の愉快堂出版社が JPRS から JPドメイン名管理指定事業者を解除されたため、 レジストラを移動せねばならなくなった。

ほっといても別のレジストラ (ヒューメイアレジストリに委託)に移るのでいいのだが、 管理が切り替わるまで予備日がない。 ギリギリに発表しよって。

しかし「指定事業者契約を終了する」ではなくて、 「指定事業者を解除する」というのは いった何かやったのだろうか？

[Prog] IA-64/Linux でユーザマスクを弄ると…

IA-64 は Program Status Register (PSR) という 64-bit レジスタが CPU の動作モードを管理している。 このレジスタの特権モードでないとアクセスできないが、 PSR のうち 6 ビット(うち1ビットは予約)は ユーザマスク(UM) と呼ばれ、 非特権モードでも読み書きが可能になっている。

be - ビッグ・エンディアン

このビットが 1 の場合は、 load/store 命令がビッグ・エンディアンで行われる。 0 の場合はリトル・エンディアンになる。
Linux では UM.be = 0 で運用される。

ac - 不正アライメントアクセス制御

UM.ac = 0 の場合には不正アライメントのメモリアクセスを CPU 内でできるだけ解決する。 Itanium2 の場合、8バイトアライメント内に収まる 8 バイト以下のメモリアクセスは、 不正境界であってもを発生させずにメモリアクセスを行う。 UM.ac = 1 の場合にはあらゆる不正アライメントアクセスが Unaligment Data Access 例外になる。 Linux は UM.ac = 1 で運用される。

up - ユーザ・パフォーマンス・モニタ

パフォーマンスモニタ機構が、 非特権側に制御を許している場合には UMA.up ビットでオン・オフできる。

mfl/mfh 浮動小数点レジスタの更新チェック

浮動小数点レジスタに書き込みを行うと sticky に立つビット。

非特権命令でユーザマスクが変更できる以上、 IA-64/Linux でもユーザプロセスでモード変更になっている。 特に変更結果が目に見えて分かるのは UM.{ac,be} で sum/rum 命令でユーザマスクを変更すると、 不正境界アクセスが可能になったり ビッグ・エンディアンでメモリアクセスが可能になったりする。 ただしユーザマスクに関しては ABI で特に規定がないので、 OS 側でコンテキストが保存されるかどうか保証がない。

カーネル 2.6.11 でテストすると、 UM.ac = 0 の方はいったんリセットすると sched_yield(2) でも シグナルハンドラ内でもシグナルハンドラから帰ってきても UM.ac はリセットされるままになっている。 不正アライメントアクセスが頻発するようなプログラムを抱えている場合には朗報だ。

一方、 UM.be = 1 をセットするとエンディアンがリトルからビッグに切り替わるので、 関数呼び出しすらできなくなる。 アセンブラで null pointer exception をわざと出して、 SEGV シグナルハンドラに処理を移すとシグナルハンドラ内では UM.be = 0 に戻っている。

ハンドラからリスタートした時に UM.be = 1 になってくれるのであれば、 専用の ld.so を作りこんでビッグエンディアンのプロセスを導入できそうに思える。 エミュレータを書くときに便利そう。

Software Virtualization v.s. Hardware Virtualization (VMware の論文 PDF形式)

VMware 社から面白い論文が発表されている。 論文のタイトルは A Comparision of Software and Hardware Techniques for x86 Virtualization。 1st Author の人は知らないが、 2nd Author の Dr. Ole Agesen は元 Sun Microsystem で Exact VM をやっていた人と同一人物だと思われる。 GC や JIT コンパイラの偉い人なり。 はてなの方にも書いたけど、 論文をショボショボ読んだので日記にも書いてみる。 それにしても HotSpot VM の Cliff Click 氏といい Sun は人材流出が激しいなぁ。

VMware 社は 自分たちの持っているソフトウェアベースの Para-Virtualization (つまり VMware ね)を Intel の x86 用の仮想化技術 VT-i や AMD の Secure Virtual Machine (SVM) アーキテクチャに 実験的に対応させたようだ。 ベンチマークを取ってみると ハードウェアでやってもソフトウェアよりも速くなるとは限らない、 むしろハードウェアの方が遅いことがあると分かったようだ。

VMware のバイナリ変換の概要

3章に(Software-assisted Virtualization の) VMware が行っているバイナリ変換技術の要約が載ってる。 オリジナル x86 命令を基本ブロックの先頭から次の分岐命令までを一塊にして変換を行う。

move %ecx, %edi
move %esi, $2
cmp  %esi, %ecx
jge  label0

分岐命令と特権命令以外はそのままで、 分岐命令は変換する。

move %ecx, %edi      ; そのまま
move %esi, $2        ; そのまま
cmp  %esi, %ecx      ; そのまま
jge  [takenAddr]     ; label0 の飛び先に
jmp  [faullthrAddr]  ; 後続の命令に

こういう基本ブロックをプロシージャ程度の単位で数ブロック分まとめて行い、 基本ブロック同士が繋がっている部分の最適化を行う。

メモリアクセスは x86 のセグメント修飾を活用することで行う。 VMware はアドレススペースの高位に VMM 用のメモリを配置しておく。 ゲスト OS がセグメントレジスタをセットする箇所をトラップして、 高位の VMM 用のメモリ空間を隠した形のセグメントに変換して物理 CPU に設定する。 VMM 用のメモリ空間に触ろうとすると例外が上がるという寸法。

Hardware-assisted Virtualization との比較

Hardware-assisted Virtualization は特権命令等の特殊な命令が実行されるタイミングで トラップが揚がって Hypervisor 側に処理が移る。 このトラップハンドラが Hypervisor の本体になる。 一方、Software-assisted Virtualization ではうまく特権命令をバイナリ変換できれば、 このトラップ処理が不要になる。 このあたりをうまく作るとソフトの方が優位という結果がさえ生まれるそうだ。

論文にはいくつか測定結果が出ているが、 x86-64 / RHEL3 上で SPECint2000、SPECjbb2005 を動かした場合、 ソフトでもハードでも実機の 90〜100% の性能が出ている。

Apache サーバのベンチマークや I/O まで含めたようなベンチマークでは、 いろいろ極端な結果が出ている。 Figure 3. を見ると 同じ Apache ベンチマークでも Linux ではソフトの方が速く、 Windows ではハードの方が速い。 論文中でもはっきりとした分析はされていない。

まぁ、

いろいろ分析はされているけど、 x86 の仮想化が性能面で本領を発揮するのは、 AMD の Nesting Paging や Intel の EPT 待ちだろうね。

[Prog] (再々) メモリ・オーダリングについての覚え書き

2002年10月30日、2004年10月12日に続いてmemory ordering についての覚え書き。 Total Store Ordering (TSO) と Store Forwarding の関係について。 これが意外にやねこしい状態を産む危険性を持っている。

ストア・バッファにストア命令を貯めて置き、後続のロード命令がストア・バッファ内に自分の書き込む場所と同じアドレスを見つけると、キャッシュまでデータを貰いにいかずにストア・バッファで折り返すことを Store Forwarding と呼ぶ。

今、メモリ [X] と [Y] の初期値が 0 の場合、以下の2つのプログラムの断片を実行したとする。 これを store forwarding のある CPU で並列実行すると、r1 = r3 = 1 で r2 = r4 = 0 という結果が返って来るかもしれない。 これはちょっと困った状態だ。

1: STORE [X] = 1
2: LOAD  r1 = [X]
3: LOAD  r2 = [Y]

4: STORE [Y] = 1
5: LOAD  r3  = [Y]
6: LOAD  r4  = [X]

プログラム A を実行した CPU では、1 行目のストア命令がストア・バッファに入り、2 行目のロード命令は 1 行目のストア命令からストアフォワーディングされた値を貰ってくる。 3 行目のロード命令はストア・バッファ中に値がないのでキャッシュから値を貰ってくる。 この段階で 1 行目のストア命令はまだキャッシュに反映されていない。 同じことがプログラム B を実行した CPU でも起きると、r1 = r3 = 1 で r2 = r4 = 0 という状態になる。

問題がどこにあるかというと、プログラマーがこの挙動を外側から見ると、r1 = r3 = 1 で r2 = r4 = 0 という状態は2つの CPU のどちらかで後発のロード命令(3,6)が先発のロード命令(2,4) を追い越さないと現れないという点だ。 最近のプロセッサは Total Store Ordering (TSO) やその亜種が多いが、TSO はロードがロードを追い越すことを認めていない。 その TSO でも store forwarding を認めているとこのタイプのロード→ロードの追い抜きは発生する。

難儀な話だ。 こういう状況の解決策は、メモリフェンス命令を余計に入れたりアトミックなメモリアクセスが必要だったりする。 アーキテクチャ毎にやり方が異なるので要注意。

追記：8/20

似たような問題が IA-32 の Speculative Program Ordering (SPO) にも存在する。 SPO は、

• ロード命令間 (RAR) では追い越して実行可能 (ただし例外が発生する場合は、順序を守ること)。
• ストア命令間 (WAW) では順序を守る。
• ストア命令 → ロード命令(RAW) の順で実行された場合、 ロード命令は先行するストア命令を追い越して実行が可能。 ただし同一メモリアドレスに対する RAW では追い越し禁止。
• ロード命令 → ストア命令 (WAR) の順で実行された場合は順序を守る。 ただし同一メモリアドレスに対する WAR では、 先発のロード命令がプロセッサ内で待機させられている場合、 後発のストア命令の書き込もうとしている値が先発ロード命令にフォワードされる。 これはストア命令によるロード命令の追い越しがあったかのように見える。
  (追記：2006.9.11)
  逆だ。同一アドレスに対する WAR は守り、異なるアドレスに対する WAR は守らない。

P.S.

IA-32 の日本語マニュアル(IA-32 インテル アーキテクチャ・ソフトウェア・デベロッパーズ・マニュアル、下巻: システム・プログラミング・ガイド) の 該当箇所の訳には問題があるように思える。 7-10 節に原文では 6. Data from buffered writes can be forwarded to waiting reads within the processor. とあるが、 これが 6. バッファリングされた書き込みのデータはプロセッサ内部で待機中の読み取りよりも先に実行できる。と訳されている。 誤訳ではないけど、理解し辛い文章だ。

横置き資料・両面刷り原稿の閉じ方

横置きの原稿や縦置き原稿の2段組を両面印刷する場合、左右閉じと上下閉じのどちらが一般的なんだろう？

大学時代に研究室でミーティングがある時は、2段組・両面刷りの資料は左右閉じがデフォルトだった。 就職して研究所にいた頃は左右閉じと上下閉じが半々だったような気がする。 事業部に移ってからはまわりの人は皆 上下で閉じており自分も最近はそれに習っている。

ミーティングの席で資料を見ている分には左右閉じの方が読みやすいのだが、後でパンチで穴止めしてファイリングすると左右閉じだとページが反転してしまうんだよなぁ。

思い出してみると、大学時代は資料はその場で読み切るもので、ペーパーメディアを保存して参照するということがなかったような気がする。 ○○仕様書とか××資料とかを山と積み上げるのが今の現状。 思えば遠くに来たものだ…

[時事] 鈴置洋孝死す

Z の映画の完成を待っていたようにお亡くなりに。
ご冥福をお祈りします。

検索エンジンのロボット

Apache Web サーバのログをみていると 最近 NaverBot からのアクセスが多いなぁと思っていたが、 Naver が日本に帰ってくるそうだ。 うちのサーバー的には Yahoo! Slurp、百度(Baidu) と並び アクセスの多い検索エンジンのトップ3を占めるようになった。 アクセス数だけで言うと、トップ3 はいずれも Goolgebot より 10 倍以上アクセス数が多い。

トップ3と言っても無駄なくクロールが多いで、 実質的な転送内容は Googlebot の 2 〜 3 倍程度と思われる。 とくにアンカー(A)要素の rel="nofollow" (教育は参考資料 2005/01/19)を辿るがどうかが、 無駄ページのクロール数に大きく関係している。 うちのサイトはトラックバックやコメントの書き込みページなどの動的に生成されるページへのリンクは nofollow を指定して、 その先にあるページはクロールしないように宣言している。 しかしこの nofollow 指定に対応しているのは (自分の確認した範囲では) 提唱者の Google ぐらいで、 Yahoo!、Naver、百度はまったく気にせずにアクセスしてくる (教育は参考資料 2005/12/15)。

それでも Naver の検索ロボットは Yahoo! Slurp や百度と比べても変な挙動をしている。 Naverbot は同じページへの二度目以降のクロールでも 手持ちのキャッシュと比較しない(If-Modified-Since フィールドを指定した GET リクエストを行わない)し、 robots.txt をコメツキバッタのように毎回取っていくんだよねぇ。

[CPU][Prog] 割り算がない

悲しいことに IA-64 には浮動小数点演算に割り算がない。
Intel 様は逆数近似命令と乗算を使ってニュートン・ラプソン法を使えとおっしゃる。

     frcpa.s0 f8,p6 = f6,f7
     ;;
(p6) fma.s1 f9 = f6,f8,f0
(p6) fnma.s1 f10 = f7,f8,f1
     ;;
(p6) fma.s1 f9 = f10,f9,f9
(p6) fma.s1 f11 = f10,f10,f0
(p6) fma.s1 f8 = f10,f8,f8
     ;;
(p6) fma.s1 f9 = f11,f9,f9
(p6) fma.s1 f10 = f11,f11,f0
(p6) fma.s1 f8 = f11,f8,f8
     ;;
(p6) fma.d.s1 f9 = f10,f9,f9
(p6) fma.s1 f8 = f10,f8,f8
     ;;
(p6) fnma.d.s1 f6 = f7,f9,f6
     ;;
(p6) fma.d.s0 f8 = f6,f8,f9

Intel 様はシフトに展開できない割り算は、 アセンブラの中でこのように書けとおっしゃる orz

とりあえず誤差を考えなければ 除数の逆数近似 frcpa.s0 f8,p6 = f6,f7 と 非除数と逆数の乗算 (p6) fma.s1 f9 = f6,f8,f0 の二つで OK だと思われる。 この誤差をどう評価するかが問題だ。

P.S.

正確に言うと整数掛け算もなくて、 fp ユニットを使う固定小数点演算で代用せにゃならん。 アセンブラを書いているとえらく面倒なんですけど。 どうにかならんかい。

[Food] ラージ・マハール＠渋谷 (公式、Excite、楽天グルメ)

渋谷に出たついでにカレーを食べにラージ・マハールにゆく(前回は2004/12/12)。 アルゴビうま〜。

前菜

ベジタブルのセット

ナン

本日見つけた懐かしい蛇口

元住吉駅になんか懐かしい蛇口の水道を見つける。

[MyWeb] 今度は日記のコメント欄にスパム

掲示板・トラックバックに続き 今度は日記等のコメント欄にスパムがやってきた (前回は7/3)。

日記を含めた Web の各ページには「くっつきBBS」を改造したものが仕込んであるが、 ここにスパムコメントを大量に貼り付けてくる輩がいる。

貼り付けられているリンクを見る限り、 掲示板・トラックバックのスパマーとは違う人物らしい。 とにかく徹底的に戦うぞ!!

週刊チャンピオンに聖闘士星矢

週刊チャンピオンの 22+23 号に予告されていた通り、 車田正美の聖闘士星矢がチャンピオンに移籍してキター。 袋とじになっているようで立ち見は不能。

八神健、漫☆画太郎、高橋陽一、山根和俊と ジャンプからチャンピオンに移った漫画家は多いけど、 パッとしたヒットを残せずに去っていた。 車田正美もどうなることやら。

[Prog][CPU] 不正境界アクセス処理のための命令シミュレータ

x86 などと違って RISC 系だとアライメント境界に沿っていないメモリアクセスは エラーになる。

IA-64 の場合、CPU の Process Status Register (PSR) の中に AC ビットがあり、 これがオンの場合は不正境界アクセスに対して Unaligned Data Reference 例外を生じる。 Linux では PSR.ac=1 で運用しており、 通常は Unaligned Data Reference 例外をトラップして 自前で不正アライメント処理を行っている。

しかし現在実装中のプログラムは、 不正境界アクセスにまで厳密なアトミック性を要求して、 Linux の不正境界アクセス処理が使えない。 自前でトラップ処理を書かねばならぬ。 プロセスに prctl(2) を適用すると、 不正境界アクセスが SIGBUS シグナルになって返って来るので、 これをハンドルして IP アドレスから IA-64 の命令の抽出 → デコード → 擬似実行という 処理を書く。

というわけで、ほげほげと IA-64 の命令デコーダを試作中。 3 命令が 1 バンドル(16バイト)になっているから、 命令がバイト単位では取り出せないのよね。 いろいろ面倒。

追記：9/1

プログラムの中から不正境界アクセスを使用時に SIGBUS シグナルを発生させるようにするには、 以下のように prctl 関数を使用する。

#include <sys/prctl.h>

prctl(PR_SET_UNALIGN, PR_UNALIGN_SIGBUS, 0, 0, 0);

一方、 プロセスの中で 8 バイト境界内に収まる不正境界アクセスを ハードウェアで自動補正するように変更するには、 プログラムの先頭で以下のように実行する。

void reset_usermask_ac() {
  asm volatile ("rum 0x8");
}