+===========+ |P/ECE研究室| +===========+ P/ECE研究記録 ============= * Wed Apr 06 00:00:00 JST 2005 Naoyuki Sawa
- ストリーム再生のまとめ#2 今回もHTMLで書きました。以下のURLをご覧下さい。 http://www.piece-me.org/piece-lab/stream/stream2.html * Sat Mar 26 19:35:00 JST 2005 Naoyuki Sawa - ストリーム再生のまとめ#1 今回はHTMLで書きました。以下のURLをご覧下さい。 http://www.piece-me.org/piece-lab/stream/stream1.html * Fri Feb 25 06:00:00 JST 2005 Naoyuki Sawa - 続・ディレイド分岐命令の誤動作～"jp.d %rb"命令は使用不可 2003年12月17日～23日のP/ECE研究記録「ディレイド分岐命令の誤動作」で、"jp.d %rb"命令の直前にメモリアクセス命令を置くとディレイド命令が実行されない、という不具合について記しました。 ●ディレイド命令が正しく実行される例 ld.b %r4, %r7 ; メモリアクセス以外の命令 jp.d %r6 ; %r6レジスタの指すアドレスへジャンプ… add %r5, 1 ; …する前に、このディレイド命令を実行します。 ●ディレイド命令が正しく実行される例 ld.b [%r4], %r7 ; メモリアクセス命令 jp.d %r6 ; %r6レジスタの指すアドレスへジャンプ… add %r5, 1 ; …する前に、このディレイド命令を実行しなければいけないのですが、実行されません!! 詳しくは、2003年12月17日～23日のP/ECE研究記録「ディレイド分岐命令の誤動作」を参照してください。 ----------------------------------------------------------------------------- "jp.d %rb"命令の直前にメモリアクセス命令を置くことさえしなければ正しく動作するのならば、プログラミング時に気をつけてさえいれば、"jp.d %rb"命令の誤動作を確実に回避することができます。しかし実際には、誤動作が発生する条件はそれだけではなく、事実上"jp.d %rb"命令は使用不可能であることがわかりました。その条件とは、 "jp.d %rb"命令の実行と、DMA転送によるメモリアクセスのタイミングが重なると、 "jp.d %rb"命令のディレイスロットに置かれたディレイド命令が実行されない。というものです。 DMA転送によるメモリアクセスのタイミングを、プログラミング時にサイクル単位で完全に把握することは、まず不可能です。 "jp.d %rb"命令の誤動作を確実に回避することはできず、従って、"jp.d %rb"命令は使用不可、ということになります。さて、それでは、 "jp.d %rb"命令の実行と、DMA転送によるメモリアクセスのタイミングが重なると、 "jp.d %rb"命令のディレイスロットに置かれたディレイド命令が実行されない。ことを確認してみましょう。実験プログラムはこちら: http://www.piece-me.org/archive/jpdbug-20050225.zip 実験プログラムtest1～test4が、以下の説明の①～④に対応しています。 ----------------------------------------------------------------------------- ①まずは、"jp.d %rb"命令が正しく動作する例を確認します。アセンブラで書かれた次のようなテストルーチンをC言語から呼び出して、変数RESULTに格納された値を画面に表示します。 test1: xld.w %r4, 1000000 ; 1000000回ループします。 xld.w %r5, 0 ; 1回毎に1づつカウントアップします。 xld.w %r6, skip ; jp.d命令のジャンプ先アドレスです。 loop: jp.d %r6 ; jp.d命令を使って以下の区間を飛び越えます。 add %r5, 1 ; jp.d命令のディレイスロットでカウントアップを行います。 ; ;{{-------------------------------------------------------- ; この区間は飛び越えるので、実行されません。 ; 本当に飛び越えていることを確認するために、 ; 万一、この区間を飛び越えずに実行されたら、 ; アドレスエラーが発生するようにしておきます。 xld.w %r15, 1 ld.w %r15, [%r15] ;}}-------------------------------------------------------- ; skip: xsub %r4, %r4, 1 ; ループ処理を行います。 xjrne loop xld.w [RESULT], %r5 ; カウントアップの結果を格納します。 ret テストルーチンの内容は、次のとおりです。 1000000回のループを行い、ループが1回まわるたびにカウンタを1づつ増やします。このとき、「カウンタを1づつ増やす」処理("add %5,1")を、"jp.d %rb"命令のディレイスロットで行っています。 1000000回のループが終了したら、カウンタの値を、グローバル変数RESULTに格納します。正しく実行されたならば、グローバル変数RESULTには1000000が格納されているはずです。それでは実行してみます。結果: 1000000 期待どおり、グローバル変数RESULTには1000000が格納されました。このテストルーチンでは、"jp.d %rb"命令の直前にメモリアクセス命令が無いので、"jp.d %rb"命令が正しく動作し、ディレイスロットに置かれたディレイド命令がきちんと実行されていることがわかります。 ----------------------------------------------------------------------------- ②次に、"jp.d %rb"命令が誤動作する例を確認します。 2003年12月17日～23日のP/ECE研究記録「ディレイド分岐命令の誤動作」で確認したのと同じ条件ですけれど、念のために、今回も、もういちど確認しておくことにしました。テストルーチンを次のように変更します。 test2: xld.w %r4, 1000000 ; 1000000回ループします。 xld.w %r5, 0 ; 1回毎に1づつカウントアップします。 xld.w %r6, skip ; jp.d命令のジャンプ先アドレスです。 xld.w %r7, DUMMY ; jp.dの誤動作を再現するためのメモリ書き込みアドレスです。 loop: ld.b [%r7], %r7 ; jp.d命令の直前でメモリアクセスすると、jp.dが誤動作します。 ; (高速RAM上で実行する場合は読み書き両方、SRAMの場合は書き込みのみ) jp.d %r6 ; jp.d命令を使って以下の区間を飛び越えます。 add %r5, 1 ; jp.d命令の遅延スロットでカウントアップを行います。 ; ;{{-------------------------------------------------------- ; この区間は飛び越えるので、実行されません。 ; 本当に飛び越えていることを確認するために、 ; 万一、この区間を飛び越えずに実行されたら、 ; アドレスエラーが発生するようにしておきます。 xld.w %r15, 1 ld.w %r15, [%r15] ;}}-------------------------------------------------------- ; skip: xsub %r4, %r4, 1 ; ループ処理を行います。 xjrne loop xld.w [RESULT], %r5 ; カウントアップの結果を格納します。 ret ①との違いは、"jp.d %rb"命令の直前にダミーのメモリアクセス命令を置いたことだけです。実行してみると、結果: 84 となりました。(実行するたびに、数字は少し変化します) 本当は1000000となるはずのところ84ですから、ほとんどの"jp.d %rb"命令は誤動作していることになりますが、わずかに正常動作の回があります。これは何かと言うと、"jp.d %rb"命令の直前で割り込みが発生し、メモリアクセス命令と"jp.d %rb"命令の間で割り込みルーチンが実行された場合に、メモリアクセス命令と"jp.d %rb"命令が連続で実行されないので、"jp.d %rb"命令が正しく動作するのです。ためしに、割り込みを完全に禁止して、同じテストルーチンを実行してみると、結果: 0 となり、"jp.d %rb"命令がすべて異常動作することが確認できます。なお、この異常動作を確認するテストプログラムは、ときどきハングアップすることがあります。メモリアクセス命令と"jp.d %rb"命令が連続すると、ディレイド命令が実行されないだけでなく、予測できない動作となることもあるみたいです。 ----------------------------------------------------------------------------- ③さて、ここからが本題です。まず、テストルーチンの内容を①と同じものに戻します。 "jp.d %rb"命令が正しく動作して、“結果: 1000000”と表示されるはずのテストルーチンです。ただし、①との違いは、バックグラウンドでサウンドを再生しながらテストルーチンを実行する、という点です。サウンド再生には、通常のP/ECEサウンドAPI pceWaveDataOut() を使います。実行してみると、結果: 994836 1%未満ですけれど、"jp.d %rb"命令が誤動作しています。(実行するたびに、数字は少し変化します) ①との違いは、バックグラウンドでサウンドを再生していることだけですから、サウンド再生が"jp.d %rb"の誤動作の原因になっていることは確実です。サウンド再生処理の内容は、主に“DMAによるメモリ転送”と“DMA完了割り込み”のふたつです。このうち、“DMA完了割り込み”が誤動作の原因になっているとは考えづらいです。なぜなら、サウンド再生を行っていなくても、“DMA完了割り込み”以外の割り込みは頻繁に発生しているからです。 “DMA完了割り込み”以外の割り込みが"jp.d %rb"の誤動作を引き起こさず、“DMA完了割り込み”だけが誤動作を引き起こすとは思えないからです。そんなわけで、原因は“DMAによるメモリ転送”にあるとアタリを付けてみることにしました。 ----------------------------------------------------------------------------- ④“DMAによるメモリ転送”が"jp.d %rb"命令の誤動作の原因であることを確認しましょう。サウンド再生処理のような複雑な処理ではなく、純粋にDMA転送だけを行ってみます。 ①や③と同じテストルーチンのバックグラウンドで単純なDMA転送を行って、"jp.d %rb"命令の誤動作が発生するかどうかを確認します。テストルーチンを呼び出す前に、次のような手順でDMA転送を開始します。 DISABLE; /*---------- DMAトリガ用タイマの設定 ----------*/ /* クロック選択 = θ/1 (タイマカウントダウン周期 = 24MHz) */ bCLKSEL_T8_P8TPCK3 = 1; /* クロック制御 = On */ bCLKCTL_T8_23_P8TON3 = 1; /* リロードデータ = 240-1 (DMAトリガ周期 = 100KHz) */ pT8_RLD3 = 240-1; /* プリセット、Run。 */ pT8_CTL3 = (1<<1) | (1<<0); /*---------- DMAの設定 ----------*/ /* コントロール情報を設定する前に、高速DMA Ch.3を確実に停止します。 */ HS3_DISABLE; /* トリガ要因 = 8bitタイマCh.3アンダーフロー */ bHSDMA_HTGR2_HSD3S = HS3_8T3; /* アドレスモード = デュアル * 転送カウンタ = 0xffffff回 (このプログラムでは、明示的に停止されるまで) */ pHS3_CNT = (1<<31) | (1<<28)-1; /* 転送データサイズ = バイト * 転送元アドレス制御 = 固定 * 転送元アドレス = &DUMMY1 */ pHS3_SADR = (int)&DUMMY1; /* 転送モード = シングル転送 * 転送先アドレス制御 = 固定 * 転送先アドレス = &DUMMY2 */ pHS3_DADR = (int)&DUMMY2; /* 高速DMA Ch.3を有効にする前に、確実にトリガフラグをクリアします。 */ pHS3_TF = 1; /* 高速DMA Ch.3を有効にします。 */ HS3_ENABLE; ENABLE; DMA転送の内容は、ダミー変数領域から別のダミー変数領域へ、100KHzの頻度でメモリ転送を行う、というものです。サウンド再生と同様に、DMA転送とテストルーチンは並行して実行されます。サウンド再生の場合と違って、DMA転送にかかわる割り込みは発生しません。それでは、実行してみます。結果: 974426 予想どおり、"jp.d %rb"が誤動作しました。(実行するたびに、数字は少し変化します) サウンド再生の場合よりも、少し誤動作の頻度が多いですね。その理由は、サウンド再生のDMA転送レートは32KHzであるのに対して、④のテストプログラムの転送レートは100KHzだからです。 DMA転送の発生する頻度が多い分、"jp.d %rb"と重なる確率が高く、結果、"jp.d %rb"が誤動作する頻度も多くなるわけです。ためしに、DMA転送レートを10倍に増してみると、 /* リロードデータ = 24-1 (DMAトリガ周期 = 1MHz) */ pT8_RLD3 = 24-1; "jp.d %rb"誤動作の頻度がもっと高くなることが確認できます。結果: 699436 ----------------------------------------------------------------------------- 以上の実験で、 "jp.d %rb"命令の実行と、DMA転送によるメモリアクセスのタイミングが重なると、 "jp.d %rb"命令のディレイスロットに置かれたディレイド命令が実行されない。ことが確認できました。先にも述べたように、DMA転送のタイミングに依存する誤動作は、回避不可能です。 P/ECEの場合、サウンド再生と併用しなければ良いのですけれど、それは現実的ではありません。結論は、 ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃"jp.d %rb"命令は、いかなる場合においても★絶対に★使ってはいけない┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ となります。なお、P/ECE開発環境の標準Cコンパイラは最適化機能が弱く、"jp.d %rb"命令を生成しませんので、C言語だけを使ってプログラミングしている限りは安全です。アセンブラを使って、手作業で最適化する場合には、要注意です。 ----------------------------------------------------------------------------- さて、以下は余談です。 "jp.d %rb"命令とDMA転送の併用による誤動作に気付いた経緯について、記しておこうと思います。現在、「ゲームボーイ/EMU」の作成中なのですけれど、サウンドを追加したとたんに、CPUエミュレーションが正しく実行されなくなるという問題が発生しました。最初、サウンドエミュレーションルーチンにバグがあって、不正なメモリを破壊しているのかと考えて調べてみたのですが、いくら調べても間違っていません。原因を突き詰めていくと、サウンドエミュレーションルーチンを呼ばなくても、単にpceWaveDataOut()を呼ぶだけで、問題が発生することがわかりました。そこで、pceWaveDataOut()を呼んだ場合と呼ばない場合とで、CPUエミュレーションのトレースログを比較してみました。すると、pceWaveDataOut()を呼んだ場合に、ときどき、残りCPU実行サイクルのカウントダウンが行われていないことがわかりました。こんなかんじです。 pceWaveDataOut()を呼ばない場合 pceWaveDataOut()を呼んだ場合 ------------------------------ ------------------------------ PC=1000: 残り実行サイクル=440 PC=1000: 残り実行サイクル=440 PC=1001: 残り実行サイクル=436 PC=1001: 残り実行サイクル=436 PC=1002: 残り実行サイクル=432 PC=1002: 残り実行サイクル=436 <- 減ってない!! PC=1003: 残り実行サイクル=428 PC=1003: 残り実行サイクル=432 PC=1004: 残り実行サイクル=424 PC=1004: 残り実行サイクル=428 PC=1005: 残り実行サイクル=420 PC=1005: 残り実行サイクル=424 PC=1006: 残り実行サイクル=416 PC=1006: 残り実行サイクル=420 上の例では、1002番地の命令のエミュレーションで誤動作が発生していますが、実行するたびに誤動作が発生するアドレスが変化するのです。何度か試してみて、誤動作が発生する命令のエミュレーションルーチンの共通性に気が付きました。それらのエミュレーションルーチンはすべて、次のようなコード並びを使っていたからです。 ld.w %r0, %r4 ; (メモリアクセス以外の命令。"jp.d %r11"は誤動作しないはず、だったのですけれど…) jp.d %r11 ; メモリ書き込みルーチンへジャンプ sub %r7, 4 ; "jp.d %rb"命令のディレイストットで、残り実行サイクルを減らすつまり、ときどき"sub %r7,4"が実行されていないことになります。以前のP/ECE研究記録「ディレイド分岐命令の誤動作」で、"jp.d %rb"とメモリアクセス命令の相性が悪いことは既にわかっていました。サウンドを追加した途端に発生した誤動作、メモリアクセス、、、となると、サウンド再生のためのDMA転送しか考えられません。そこで今回のような調査を行ってみたところ、"jp.d %rb"命令とDMA転送の併用で異常動作が発生することがわかった、というわけです。今回は、単純で定型的な処理を繰り返すCPUエミュレーションルーチンの中での誤動作だったために、比較的簡単に原因が推測できました。もしも、通常のゲームプログラムの入り組んだルーチンの中で、ごく稀に発生するような誤動作だったならば、原因究明にはもっと時間がかかっていたと思います。ある意味、幸運だったかも知れません。 * Fri Feb 11 04:56:00 JST 2005 Naoyuki Sawa - 続・実はディレイド命令今回のテーマは、2003年4月12日の記録「実はディレイド命令」の続きです。 ====================================================================================================================== まずは、前回のおさらいから。 P/ECEのCPU S1C33209は、RISC CPUの特徴のひとつ、「ディレイド分岐機能」を持っています。ディレイド分岐機能とは、分岐命令の実行より先に分岐命令の直後の命令を実行し、実行効率を稼ぐ機能です。ディレイド分岐機能を使う分岐命令を、「ディレイド分岐命令」と呼びます。また、ディレイド分岐命令の直後に置かれる命令を、「ディレイド命令」と呼びます。ディレイド分岐命令直後の、ディレイド命令を置くことができる位置を、「ディレイドスロット」と呼びます。すべての命令が、ディレイド命令として使用できるわけではありません。ある命令がディレイド命令として使用できるか否かについて、基本的な判断基準は次の通りです。ディレイド命令は以下の条件をすべて満たしていることが必要です。・1サイクル命令・メモリをアクセスしない・ext命令による拡張なし『S1C33209コアCPUマニュアル』(C:\usr\PIECE\docs\datasheet\EPSON\33000Core-J.pdf) p.30「ディレイド分岐機能」より同ページには、ディレイド命令として使用できる命令の一覧が示されています。さらにその下に、次のような注意が記されています。注：上記の条件を満たさない命令は動作が不定となるため、ディレイド命令として使用することは禁止します。ところが、EPSON社自身による標準ライブラリの実装が、このルールを破っていました。ディレイド命令として使用できないはずの"ld.w %rd,%ss"命令を、ディレイド命令として使用していたのです。何通りかの命令並びを試してみたところ、"ld.w %rd,%ss"命令は、ディレイド命令として問題なく使用できることがわかりました。 EPSON社も使っているのですから、たぶん大丈夫なのでしょう。以上、前回のおさらいでした。 ====================================================================================================================== その後、自作プログラムで"ld.w %rd,%ss"命令をディレイド命令として使ってきましたが、これまでのところ問題は出ていません。やっぱり、大丈夫だったようです。さて、ディレイド命令として使用不可とされている命令のなかに、"ld.w %rd,%ss"命令よりもっと使用頻度の高いものがあります。 char⇔int変換やshort⇔int変換を行う、以下の命令群です。 ld.b %rd,%rs char⇔int変換 ld.ub %rd,%rs unsigned char⇔int変換、(value&0xff)の代用 ld.h %rd,%rs short⇔int変換 ld.uh %rd,%rs unsigned short⇔int変換、(value&0xffff)の代用以降の文では、これらの命令を“型変換命令”と呼ぶことにします。型変換命令はすべて「1サイクル命令」で「メモリをアクセスしない」命令で「ext命令による拡張なし」の条件を満たしています。にもかかわらず、『S1C33209コアCPUマニュアル』では、ディレイド命令として使用可能な命令に挙げられていません。実際にプログラムを組んでいると、型変換命令がディレイド命令として使えないために、悔しい思いをすることがよくあります。 add %r12, %r13　　　　　; a = a + b ld.ub %r10, %r12　　　　; return (unsigned char)a ret ↓"ld.ub %r10,%r12"がディレイド命令として使用可能だったならば、次のように並び替えて高速化できるのですが・・・ add %r12, %r13　　　　　; a = a + b ret.d 　　　　　　　　　; return (unsigned char)a ld.ub %r10, %r12　　　　; *delay* 実際には、"ld.ub %r10,%r12"がディレイド命令として使用可能でないために、並び替え“不可”です！！一見、ディレイド命令として使用可能な"and"命令で代用してしまえばいいようにも見えますけれど、それはできません。 add %r12, %r13　　　　　; a = a + b ret.d 　　　　　　　　　; return a & 0xff xand %r10, %r12, 0xff 　; *delay* ↓"xand %r10,%r12,0xff"は、コンパイラによって次のように展開されます。 add %r12, %r13　　　　　; a = a + b ret.d 　　　　　　　　　; return a & 0xff ext 0xff　　　　　　　　; ┐ and %r10, %r12　　　　　; ┴ 2命令に展開されてしまい、ディレイドスロットに収まりません！！型変換命令を使うときは、ディレイド分岐機能を使った高速化をあきらめるしかないのでしょうか？ ====================================================================================================================== 「1サイクル命令」「メモリをアクセスしない」「ext命令による拡張なし」の条件を満たしているにもかかわらず、ディレイド命令として使用可能でない命令としては、型変換命令の他に、"div1"や"halt"命令などがあります。 "div1"や"halt"命令はやや特殊な部類の命令ですから、ディレイド命令として使用可能でなくても、なんとなく納得できます。しかし、型変換命令のような単純で使用頻度の高い命令がディレイド命令として使用可能でないというのは、納得できません。そこでふと考えたのが、「もしかして実際には型変換命令もディレイド命令として使用可能なのではないか？」思えば"ld.w %rd,%ss"命令だって、マニュアルには記載されていないけれど、暗黙公然のディレイド命令だったわけですから。それではさっそく試してみましょう。 --------------------------------------------------------- foo: add %r12, %r13　　　　　; a = a + b ret.d 　　　　　　　　　; return (unsigned char)a ld.ub %r10, %r12　　　　; *delay* --------------------------------------------------------- このアセンブラルーチンを、C言語プログラムから呼び出してみます。 --------------------------------------------------------- extern int foo(int a, int b); n = foo(0x12345678, 0x9abcdef0); pceFontPrintf("%08x", n); --------------------------------------------------------- 結果は、「00000068」と表示されました。 0x12345678 + 0x9abcdef0 = 0xacf13568 (unsigned char)0xacf13568 = 0x68 ですから、正しい結果です。実行時間を計測してみると、ディレイド分岐機能を使ったことによる高速化の効果が確認できました。前後数命令の並びを何通りかに変えてみたり、プログラムやデータをSRAMや高速RAMに配置しても、すべて正しい結果となります。 "ld.b %rd,%rs"、"ld.h %rd,%rs"、"ld.uh %rd,%rs"命令についても同様に試してみたところ、すべて正しい結果が得られました。三年間悩んでいたのが可笑しくなってくるぐらい、あっけない幕切れです。 ┏━━━━━━━━━━━━━━━━━━━━┓ ┃┏━━━━━━━━━━━━━━━━━━┓┃ ┃┃　型変換命令もディレイド命令でした　┃┃ ┃┗━━━━━━━━━━━━━━━━━━┛┃ ┗━━━━━━━━━━━━━━━━━━━━┛ もっとも、テストプログラムで正しい結果が得られただけでは、あらゆる場面で正しい結果が得られるとは限りません。マニュアルにも「上記の条件を満たさない命令は動作が★不定★となるため～」と記されているように、テストプログラムではたまたま正しい結果が得られただけかも知れないからです。しかし、"ld.w %rd,%ss"の前例からすると、たぶんどんな場面でも大丈夫な気がします。僕のカンですけれど。。。(^^; 型変換命令がディレイド命令として使えることのメリットは、もしかしたら不安定かも…というリスクを上回ります。なにより、使ってみなければ不安定かどうかもわかりませんから、今後は積極的に使ってみることにしようと思います。 ====================================================================================================================== そんなわけで、型変換命令もディレイド命令として(たぶん)使用可能であることがわかりました。もっと早くに試しておけばよかった。。。さて、こうなってくると、「型変換命令以外にも、実はディレイド命令として使用可能な命令があるのでは？」と思えてきます。ちょっと試してみたところ、・1サイクル命令・メモリをアクセスしない・ext命令による拡張なしの条件をまったく無視して、ほとんどの命令がディレイド命令として(一応は)動作することがわかりました。 xjp.d bar mlt.w %r12, %r13　　　　; 5サイクル命令！！とか、 xjp.d bar ld.w %r10, [%r12] 　　　; メモリをアクセスする！！とか、 xjp.d bar ext 0xff　　　　　　　　; 分岐先の命令のext拡張を先取り！！ . . . bar: and %r10, %r12　　　　　; "xand %r10, %r12, 0xff"になりますとか、軽く試した限りでは、すべて正しい結果が得られました。実行時間を計測してみると、ディレイド分岐機能を使ったことによる高速化の効果が確認できます。特に二つ目の、メモリアクセス命令をディレイドスロットに入れた例で、大幅な高速化の効果があるみたいです。しかしながらさすがにこれらの複雑な命令になってくると、状況によっては結果が不安定になるのではないかという気もします。とりあえず今回は「型変換命令もディレイド命令」という結果に満足し、その他の命令の実験はまた今後、としたいと思います。 * Sun Dec 5 16:00:00 JST 2004 Naoyuki Sawa - ADPCMの仕組み#5 今回も絵が多いのでHTMLで書きました。以下のURLをご覧下さい。 http://www.piece-me.org/piece-lab/adpcm/adpcm5.html * Sat Dec 4 14:45:00 JST 2004 Naoyuki Sawa - ADPCMの仕組み#4 今回も絵が多いのでHTMLで書きました。以下のURLをご覧下さい。 http://www.piece-me.org/piece-lab/adpcm/adpcm4.html * Fri Dec 3 00:00:00 JST 2004 Naoyuki Sawa - ADPCMの仕組み#3 今回も絵が多いのでHTMLで書きました。以下のURLをご覧下さい。 http://www.piece-me.org/piece-lab/adpcm/adpcm3.html * Wed Dec 1 00:00:00 JST 2004 Naoyuki Sawa - ADPCMの仕組み#2 今回も絵が多いのでHTMLで書きました。以下のURLをご覧下さい。 http://www.piece-me.org/piece-lab/adpcm/adpcm2.html * Tue Nov 30 06:00:00 JST 2004 Naoyuki Sawa - ADPCMの仕組み#1 今回は絵が多いのでHTMLで書きました。以下のURLをご覧下さい。 http://www.piece-me.org/piece-lab/adpcm/adpcm1.html * Sat Nov 7 09:00:00 JST 2004 Naoyuki Sawa - 構造体パックに問題あり#2 前回、P/ECE開発環境では、構造体パックのための__attribute__((packed))が正しく動作しない、というところまでお話しました。具体的には、構造体サイズは正しくパックされるのだけれど、初期化済み構造体の内容がパックされていない、という症状です。今回は、その原因を探ってみます。結論だけ言うと一言で終わってしまうのですが、それでは面白くないので(^^;、僕が調査したときの手順を追って説明してみます。長いですけれど、おつきあいください。 ■■■■■■■■■■■■■■■■ ■コンパイラ出力を比較してみる■ ■■■■■■■■■■■■■■■■ さてそれでは、構造体アライメントあり(＝構造体パック無し)の場合と構造体アライメント無し(＝構造体パックあり)の場合とで、 C言語ソースがどのようにコンパイルされ、どのようなアセンブラコードが生成されているのか見てみます。 C言語ソースの内容は、前回の後半■Ｐ／ＥＣＥの場合～問題発生!!■を参照してください。まずは、後半部分にある、pceAppProc()関数がどのようにコンパイルされているのか見てみます。最初に、__attribute__((packed))を指定しない、構造体アライメントありの場合。 [構造体アライメントあり] ; void pceAppProc(int count) ; { ; 　　int i; ; 　　unsigned char* p; ; ; 　　memset(vbuff, 0, sizeof vbuff); ; 　　pceFontSetType(2); ; 　　pceFontSetPos(0, 0); ; ; 　　p = (unsigned char*)&cid; ; 　　pceFontPrintf("size = %d\n", sizeof(MMC_CID_INFO)); ; 　　for(i = 0; i < sizeof(MMC_CID_INFO); i++) { ; 　　　　pceFontPrintf("%02x ", p[i]); ; 　　} ; ; 　　pceLCDTrans(); ; } ; ; の部分が、次のようにコンパイルされます。 pceAppProc: 　　　　pushn　%r2 　　　　xsub　%sp,%sp,8 　　　　xld.w　%r12,vbuff 　　　　ld.w　%r13,0x0 　　　　xld.w　%r14,0x00002c00 　　　　xcall　memset 　　　　xld.w　%r12,0x00000002 　　　　xcall　pceFontSetType 　　　　ld.w　%r12,0x0 　　　　ld.w　%r13,%r12 　　　　xcall　pceFontSetPos 　　　　xld.w　%r10,__LC0 　　　　xld.w　[%sp],%r10 　　　　xld.w　%r10,0x00000014　　　　; 0x00000014(20) = sizeof(MMC_CID_INFO) 　　　　xld.w　[%sp+4],%r10 　　　　xcall　pceFontPrintf 　　　　xld.w　%r2,__LC1 　　　　xld.w　%r0,cid 　　　　xadd　%r1,%r0,15 __L6: 　　　　xld.w　[%sp],%r2 　　　　xld.ub　%r10,[%r0] 　　　　xld.w　[%sp+4],%r10 　　　　xcall　pceFontPrintf 　　　　xadd　%r0,%r0,1 　　　　cmp　%r0,%r1 　　　　xjrule　__L6 　　　　xcall　pceLCDTrans 　　　　xadd　%sp,%sp,8 　　　　popn　%r2 　　　　ret 次に、__attribute__((packed))を指定した、構造体アライメント無しの場合。 [構造体アライメント無し] ; void pceAppProc(int count) ; { ; 　　int i; ; 　　unsigned char* p; ; ; 　　memset(vbuff, 0, sizeof vbuff); ; 　　pceFontSetType(2); ; 　　pceFontSetPos(0, 0); ; ; 　　p = (unsigned char*)&cid; ; 　　pceFontPrintf("size = %d\n", sizeof(MMC_CID_INFO)); ; 　　for(i = 0; i < sizeof(MMC_CID_INFO); i++) { ; 　　　　pceFontPrintf("%02x ", p[i]); ; 　　} ; ; 　　pceLCDTrans(); ; } ; ; の部分が、次のようにコンパイルされます。 pceAppProc: 　　　　pushn　%r2 　　　　xsub　%sp,%sp,8 　　　　xld.w　%r12,vbuff 　　　　ld.w　%r13,0x0 　　　　xld.w　%r14,0x00002c00 　　　　xcall　memset 　　　　xld.w　%r12,0x00000002 　　　　xcall　pceFontSetType 　　　　ld.w　%r12,0x0 　　　　ld.w　%r13,%r12 　　　　xcall　pceFontSetPos 　　　　xld.w　%r10,__LC0 　　　　xld.w　[%sp],%r10 　　　　xld.w　%r10,0x00000010　　　　; 0x00000010(16) = sizeof(MMC_CID_INFO) 　　　　xld.w　[%sp+4],%r10 　　　　xcall　pceFontPrintf 　　　　xld.w　%r2,__LC1 　　　　xld.w　%r0,cid 　　　　xadd　%r1,%r0,15 __L6: 　　　　xld.w　[%sp],%r2 　　　　xld.ub　%r10,[%r0] 　　　　xld.w　[%sp+4],%r10 　　　　xcall　pceFontPrintf 　　　　xadd　%r0,%r0,1 　　　　cmp　%r0,%r1 　　　　xjrule　__L6 　　　　xcall　pceLCDTrans 　　　　xadd　%sp,%sp,8 　　　　popn　%r2 　　　　ret sizeof(MMC_CID_INFO)の値が、構造体アライメントありの場合はパディング込みで20バイト、構造体アライメント無しの場合は16バイトになっています。 P/ECE開発環境のCコンパイラは、構造体アライメントありの場合と無しの場合とで、構造体サイズの違いをきちんと処理できていることがわかります。構造体サイズが変化すること以外は、構造体アライメントありの場合も無しの場合も、まったく同じコンパイル結果です。問題ありません。それでは、前半部分の、初期化済み構造体の定義がどのようにコンパイルされているか見てみます。最初に、__attribute__((packed))を指定しない、構造体アライメントありの場合。 [構造体アライメントあり] ; //CID(Card IDentification number)　カードIDレジスタ情報構造体 ; typedef struct tag_MMC_CID_INFO ; { ; 　　unsigned char　 ucMID;　　　　　　　// + 0, 1: ManufactureID(8bit) ; 　　unsigned short　usOID;　　　　　　　// + 2, 2: OEM/Application ID(16bit) ; 　　unsigned char　 ucPNM[6];　　　　　 // + 4, 6: Product name(48bit) ; 　　unsigned char　 ucPRV;　　　　　　　// +10, 1: Product revision(8bit) ; 　　unsigned long　 ulPSN;　　　　　　　// +12, 4: Product serial number(32bit) ; 　　unsigned char　 ucMDT;　　　　　　　// +16, 1: Manufacturing date(8bit) ; 　　unsigned char　 ucCRC;　　　　　　　// +17, 1: 7-bit CRC checksum(7bit) ; } __attribute__((packed)) MMC_CID_INFO; // =20 ; ; MMC_CID_INFO cid = { ; 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucMID;　　// + 0, 1: ManufactureID(8bit) ; 　　0xffff,　　　　　　　　　　　　　　　　 // unsigned short　usOID;　　// + 2, 2: OEM/Application ID(16bit) ; 　　{ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }, // unsigned char　 ucPNM[6]; // + 4, 6: Product name(48bit) ; 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucPRV;　　// +10, 1: Product revision(8bit) ; 　　0xffffffff, 　　　　　　　　　　　　　　// unsigned long　 ulPSN;　　// +12, 4: Product serial number(32bit) ; 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucMDT;　　// +16, 1: Manufacturing date(8bit) ; 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucCRC;　　// +17, 1: 7-bit CRC checksum(7bit) ; }; ; ; の部分が、次のようにコンパイルされます。　　　　.align　2 cid: 　　　　.byte　 255 　　　　.space　1 　　　　.half　 65535 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.space　1 　　　　.word　 -1 　　　　.byte　 255 　　　　.byte　 255 　　　　.space　2 次に、__attribute__((packed))を指定した、構造体アライメント無しの場合。 [構造体アライメント無し] ; //CID(Card IDentification number)　カードIDレジスタ情報構造体 ; typedef struct tag_MMC_CID_INFO ; { ; 　　unsigned char　 ucMID;　　　　　　　// + 0, 1: ManufactureID(8bit) ; 　　unsigned short　usOID;　　　　　　　// + 1, 2: OEM/Application ID(16bit) ; 　　unsigned char　 ucPNM[6];　　　　　 // + 3, 6: Product name(48bit) ; 　　unsigned char　 ucPRV;　　　　　　　// + 9, 1: Product revision(8bit) ; 　　unsigned long　 ulPSN;　　　　　　　// +10, 4: Product serial number(32bit) ; 　　unsigned char　 ucMDT;　　　　　　　// +14, 1: Manufacturing date(8bit) ; 　　unsigned char　 ucCRC;　　　　　　　// +15, 1: 7-bit CRC checksum(7bit) ; } __attribute__((packed)) MMC_CID_INFO; // =16 ; ; MMC_CID_INFO cid = { ; 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucMID;　　// + 0, 1: ManufactureID(8bit) ; 　　0xffff,　　　　　　　　　　　　　　　　 // unsigned short　usOID;　　// + 1, 2: OEM/Application ID(16bit) ; 　　{ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }, // unsigned char　 ucPNM[6]; // + 3, 6: Product name(48bit) ; 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucPRV;　　// + 9, 1: Product revision(8bit) ; 　　0xffffffff, 　　　　　　　　　　　　　　// unsigned long　 ulPSN;　　// +10, 4: Product serial number(32bit) ; 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucMDT;　　// +14, 1: Manufacturing date(8bit) ; 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucCRC;　　// +15, 1: 7-bit CRC checksum(7bit) ; }; ; ; の部分が、次のようにコンパイルされます。　　　　.align　2 cid: 　　　　.byte　 255 　　　　.half　 65535 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.word　 -1 　　　　.byte　 255 　　　　.byte　 255 おや？一見問題ないように見えます。わかりやすいように、コメントに付けてみましょう。 [構造体アライメントあり] 　　　　.align　2　　　　; 次の位置が確実に(1<<2)=4の倍数アドレスから始まるようにする。 cid: 　　　　.byte　 255　　　; // unsigned char　 ucMID;　　// + 0, 1: ManufactureID(8bit) 　　　　.space　1　　　　; // (パディング)　　　　　　　// + 1, 1: 　　　　.half　 65535　　; // unsigned short　usOID;　　// + 2, 2: OEM/Application ID(16bit) 　　　　.byte　 255　　　; // unsigned char　 ucPNM[6]; // + 4, 6: Product name(48bit) 　　　　.byte　 255　　　; 　　　　.byte　 255　　　; 　　　　.byte　 255　　　; 　　　　.byte　 255　　　; 　　　　.byte　 255　　　; 　　　　.byte　 255　　　; // unsigned char　 ucPRV;　　// +10, 1: Product revision(8bit) 　　　　.space　1　　　　; // (パディング)　　　　　　　// +11, 1: 　　　　.word　 -1　　　 ; // unsigned long　 ulPSN;　　// +12, 4: Product serial number(32bit) 　　　　.byte　 255　　　; // unsigned char　 ucMDT;　　// +16, 1: Manufacturing date(8bit) 　　　　.byte　 255　　　; // unsigned char　 ucCRC;　　// +17, 1: 7-bit CRC checksum(7bit) 　　　　.space　2　　　　; // (パディング)　　　　　　　// +18, 2: 構造体アライメントありの場合については、完全に問題ありません。前回行ったP/ECE上でのテストでも、期待通りの実行結果となっていました。構造体アライメントありの場合については、もう検討する必要はなさそうです。問題は、構造体アライメント無しの場合です。 [構造体アライメント無し] 　　　　.align　2　　　　; 次の位置が確実に(1<<2)=4の倍数アドレスから始まるようにする。 cid: 　　　　.byte　 255　　　; // unsigned char　 ucMID;　　// + 0, 1: ManufactureID(8bit) 　　　　.half　 65535　　; // unsigned short　usOID;　　// + 1, 2: OEM/Application ID(16bit) 　　　　.byte　 255　　　; // unsigned char　 ucPNM[6]; // + 3, 6: Product name(48bit) 　　　　.byte　 255　　　; 　　　　.byte　 255　　　; 　　　　.byte　 255　　　; 　　　　.byte　 255　　　; 　　　　.byte　 255　　　; 　　　　.byte　 255　　　; // unsigned char　 ucPRV;　　// + 9, 1: Product revision(8bit) 　　　　.word　 -1　　　 ; // unsigned long　 ulPSN;　　// +10, 4: Product serial number(32bit) 　　　　.byte　 255　　　; // unsigned char　 ucMDT;　　// +14, 1: Manufacturing date(8bit) 　　　　.byte　 255　　　; // unsigned char　 ucCRC;　　// +15, 1: 7-bit CRC checksum(7bit) コンパイル結果のアセンブラコードを見る限りは、問題無さそうに見えます。が、実は、上のコメントのようなメモリ配置にはならないのです。『アセンブラにも暗黙のアライメント機能がある』というのがその理由です。 ■■■■■■■■■■■■■■■■ ■アセンブラのアライメント機能■ ■■■■■■■■■■■■■■■■ P/ECE開発環境に入っている、「S1C33 Family Cコンパイラパッケージ Ver.4」のマニュアルを開いてみてください。 (C:\usr\PIECE\docs\datasheet\EPSON\S5U1C33000C_J.pdf) マニュアル171ページ(PDFでは187ページ目)、「11.8.6 データ定義擬似命令」のところに、次のような記述があります。 .word擬似命令 ●注意事項・定義したデータは直前に.align命令がない限り、ワード境界アドレスから配置されます。　現在位置がワード境界アドレス以外の場合、データを配置するワード境界アドレスまでの間は0x00が設定されます。 .half擬似命令 ●注意事項・定義したデータは直前に.align命令がない限り、ハーフワード境界アドレスから配置されます。　現在位置が奇数アドレスの場合、現在位置には0x00が設定されます。これです!! つまり、コンパイル結果のアセンブラコードがas33.exeによってアセンブルされると、次のようなメモリ配置になっていたのです。 [構造体アライメント無し] 　　　　.align　2　　　　; 次の位置が確実に(1<<2)=4の倍数アドレスから始まるようにする。 cid: 　　　　.byte　 255　　　; // unsigned char　 ucMID;　　// + 0, 1: ManufactureID(8bit) 　　　　(0x00)　　　　　 ; // (パディング)　　　　　　　// + 1, 1: 　　　　.half　 65535　　; // unsigned short　usOID;　　// + 2, 2: OEM/Application ID(16bit) 　　　　.byte　 255　　　; // unsigned char　 ucPNM[6]; // + 4, 6: Product name(48bit) 　　　　.byte　 255　　　; 　　　　.byte　 255　　　; 　　　　.byte　 255　　　; 　　　　.byte　 255　　　; 　　　　.byte　 255　　　; 　　　　.byte　 255　　　; // unsigned char　 ucPRV;　　// +10, 1: Product revision(8bit) 　　　　(0x00)　　　　　 ; // (パディング)　　　　　　　// +11, 1: 　　　　.word　 -1　　　 ; // unsigned long　 ulPSN;　　// +12, 4: Product serial number(32bit) 　　　　.byte　 255　　　; // unsigned char　 ucMDT;　　// +16, 1: Manufacturing date(8bit) 　　　　.byte　 255　　　; // unsigned char　 ucCRC;　　// +17, 1: 7-bit CRC checksum(7bit) 構造体末尾のパディングが考慮されないことを除けば、このメモリ配置はCコンパイラによって構造体アライメントが行われた場合と同じです。 __attribute__((packed))が指定された時、Cコンパイラは明示的なパディング(.space擬似命令)のコード出力を省いて、構造体アライメントを無くしたつもりでいるのですが、実際にはアセンブラによってフィールド単位のアライメントが行われてしまい、結果、構造体アライメントありの場合と同じメモリ配置になってしまっていた、というわけです。では、どのようなアセンブラコード出力ならば、正しく構造体アライメント無しのメモリ配置になるのでしょうか？ .align擬似命令が、Visual C++における#pragma packみたいなものだと考えると、次のようなアセンブラコードを思いつきます。 [構造体アライメント無しにするには？] 　　　　.align　0　　　　; 次の位置が(1<<0)=1の倍数アドレスから始まるようにする。 cid: 　　　　.byte　 255 　　　　.half　 65535 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.word　 -1 　　　　.byte　 255 　　　　.byte　 255 が、これではダメです。実際にプログラムを書いてみて、これではダメなことを確認しました。 [構造体アライメント無しにするには？(失敗例)] #include unsigned char vbuff[128 * 88]; //CID(Card IDentification number)　カードIDレジスタ情報構造体 typedef struct tag_MMC_CID_INFO { 　　unsigned char　 ucMID;　　　　　　　// + 0, 1: ManufactureID(8bit) 　　unsigned short　usOID;　　　　　　　// + 1, 2: OEM/Application ID(16bit) 　　unsigned char　 ucPNM[6];　　　　　 // + 3, 6: Product name(48bit) 　　unsigned char　 ucPRV;　　　　　　　// + 9, 1: Product revision(8bit) 　　unsigned long　 ulPSN;　　　　　　　// +10, 4: Product serial number(32bit) 　　unsigned char　 ucMDT;　　　　　　　// +14, 1: Manufacturing date(8bit) 　　unsigned char　 ucCRC;　　　　　　　// +15, 1: 7-bit CRC checksum(7bit) } __attribute__((packed)) MMC_CID_INFO; // =16 //初期化済み構造体の定義を、インラインアセンブラで書き直してみます。 extern MMC_CID_INFO cid; asm(" 　　　　.align　0　　　　; 次の位置が(1<<0)=1の倍数アドレスから始まるようにする。 cid: 　　　　.byte　 255 　　　　.half　 65535 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.word　 -1 　　　　.byte　 255 　　　　.byte　 255 "); void pceAppInit() { 　　pceLCDSetBuffer(vbuff); 　　pceLCDDispStart(); } void pceAppProc(int count) { 　　int i; 　　unsigned char* p; 　　memset(vbuff, 0, sizeof vbuff); 　　pceFontSetType(2); 　　pceFontSetPos(0, 0); 　　p = (unsigned char*)&cid; 　　pceFontPrintf("size = %d\n", sizeof(MMC_CID_INFO)); 　　for(i = 0; i < sizeof(MMC_CID_INFO); i++) { 　　　　pceFontPrintf("%02x ", p[i]); 　　} 　　pceLCDTrans(); } void pceAppExit() { } ------------------------------------------------------------------------------------------- ■■ 結果 ■■ size = 16 ff 00 ff ff ff ff ff ff ff ff ff 00 ff ff ff ff ------------------------------------------------------------------------------------------- C言語で書いた場合の、誤った出力結果と変わっていません。なぜダメか、マニュアル174ページ(PDFでは190ページ目)の、.align擬似命令の説明を見てください。 .align擬似命令 ●機能　この擬似命令の直後に出現するデータを２＾Ｎバイト境界にアライメントします(Ｎ＝境界指定値)。 ●注意事項　.align擬似命令は直後にあるデータ定義擬似命令に対してのみ有効です。　したがって、アライメントが必要なデータを定義する場合には、データ定義擬似命令個々に.align擬似命令を使用する必要があります。そう、.align擬似命令は『直後の』データ定義擬似命令に対してしか、効果がないのです。直後よりうしろのデータ定義擬似命令は、通常どおり、暗黙のアライメントがなされてしまいます。　　　　.align　0　　　　; 次の位置が(1<<0)=1の倍数アドレスから始まるようにする。 cid: 　　　　.byte　 255 　　　　.half　 65535　　; ここから後ろは、通常どおり、暗黙のアライメントがなされてしまいます。　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.word　 -1 　　　　.byte　 255 　　　　.byte　 255 直後のデータ擬似命令に対して.alignが有効だとういうのならば、次のように書けばいいのでしょうか？ [構造体アライメント無しにするには？] 　　　　.align　2　　　　; 構造体の先頭を4の倍数アドレスから始めるために、先頭の.align 2は必要!! cid: 　　　　.byte　 255 　　　　.align　0　　　　; 次の.halfの暗黙のアライメントを抑制する。　　　　.half　 65535 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.align　0　　　　; 次の.wordの暗黙のアライメントを抑制する。　　　　.word　 -1 　　　　.byte　 255 　　　　.byte　 255 それでは、もういちどプログラムを書いて試してみます。 [構造体アライメント無しにするには？(失敗例)] #include unsigned char vbuff[128 * 88]; //CID(Card IDentification number)　カードIDレジスタ情報構造体 typedef struct tag_MMC_CID_INFO { 　　unsigned char　 ucMID;　　　　　　　// + 0, 1: ManufactureID(8bit) 　　unsigned short　usOID;　　　　　　　// + 1, 2: OEM/Application ID(16bit) 　　unsigned char　 ucPNM[6];　　　　　 // + 3, 6: Product name(48bit) 　　unsigned char　 ucPRV;　　　　　　　// + 9, 1: Product revision(8bit) 　　unsigned long　 ulPSN;　　　　　　　// +10, 4: Product serial number(32bit) 　　unsigned char　 ucMDT;　　　　　　　// +14, 1: Manufacturing date(8bit) 　　unsigned char　 ucCRC;　　　　　　　// +15, 1: 7-bit CRC checksum(7bit) } __attribute__((packed)) MMC_CID_INFO; // =16 //初期化済み構造体の定義を、インラインアセンブラで書き直してみます。 extern MMC_CID_INFO cid; asm(" 　　　　.align　2　　　　; 構造体の先頭を4の倍数アドレスから始めるために、先頭の.align 2は必要!! cid: 　　　　.byte　 255 　　　　.align　0　　　　; 次の.halfの暗黙のアライメントを抑制する。　　　　.half　 65535 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.byte　 255 　　　　.align　0　　　　; 次の.wordの暗黙のアライメントを抑制する。　　　　.word　 -1 　　　　.byte　 255 　　　　.byte　 255 "); void pceAppInit() { 　　pceLCDSetBuffer(vbuff); 　　pceLCDDispStart(); } void pceAppProc(int count) { 　　int i; 　　unsigned char* p; 　　memset(vbuff, 0, sizeof vbuff); 　　pceFontSetType(2); 　　pceFontSetPos(0, 0); 　　p = (unsigned char*)&cid; 　　pceFontPrintf("size = %d\n", sizeof(MMC_CID_INFO)); 　　for(i = 0; i < sizeof(MMC_CID_INFO); i++) { 　　　　pceFontPrintf("%02x ", p[i]); 　　} 　　pceLCDTrans(); } void pceAppExit() { } ------------------------------------------------------------------------------------------- ■■ 結果 ■■ size = 16 ff 00 ff ff ff ff ff ff ff ff ff 00 ff ff ff ff ------------------------------------------------------------------------------------------- やっぱりダメです。何通りか試した結果、どうやら.align擬似命令は「パディングを増やすことはできるが減らすことはできない」ことがわかりました。たとえば、通常、.byte擬似命令には暗黙のアライメントはありません。が、構造体の先頭フィールドがunsigned char型であるような場合など、unsigned char値を強制的に4の倍数アドレスに置きたい場合に、 .byte擬似命令の前に.align 2を指定したりするわけで、このような.align擬似命令の使い方はＯＫです。が、逆に、もともと暗黙のアライメントによって.half擬似命令や.word擬似命令の直前にパディングが追加されていたものとして、そのパディングを取り除くために.align 0を指定しても、それは無視されてしまうのです。以上の振る舞いはマニュアルには載っていないようですけれど、まあ、感覚的に理解できなくもありません。そんなわけで結局、アセンブラによる暗黙のアライメントを抑制するには、次のように1バイトづつ定義するしかないみたいです。 [構造体アライメント無しにするには？(いちおう成功例ですが…)] #include unsigned char vbuff[128 * 88]; //CID(Card IDentification number)　カードIDレジスタ情報構造体 typedef struct tag_MMC_CID_INFO { 　　unsigned char　 ucMID;　　　　　　　// + 0, 1: ManufactureID(8bit) 　　unsigned short　usOID;　　　　　　　// + 1, 2: OEM/Application ID(16bit) 　　unsigned char　 ucPNM[6];　　　　　 // + 3, 6: Product name(48bit) 　　unsigned char　 ucPRV;　　　　　　　// + 9, 1: Product revision(8bit) 　　unsigned long　 ulPSN;　　　　　　　// +10, 4: Product serial number(32bit) 　　unsigned char　 ucMDT;　　　　　　　// +14, 1: Manufacturing date(8bit) 　　unsigned char　 ucCRC;　　　　　　　// +15, 1: 7-bit CRC checksum(7bit) } __attribute__((packed)) MMC_CID_INFO; // =16 //初期化済み構造体の定義を、インラインアセンブラで書き直してみます。 extern MMC_CID_INFO cid; asm(" 　　　　.align　2　　　　　　　　; 構造体の先頭を4の倍数アドレスから始めるために、先頭の.align 2は必要!! cid: 　　　　.byte　 255　　　　　　　; // + 0, 1: ManufactureID(8bit) 　　　　.byte 255,255　　　　　; // + 1, 2: OEM/Application ID(16bit) 　　　　.byte　 255　　　　　　　; // + 3, 6: Product name(48bit) 　　　　.byte　 255　　　　　　　; 　　　　.byte　 255　　　　　　　; 　　　　.byte　 255　　　　　　　; 　　　　.byte　 255　　　　　　　; 　　　　.byte　 255　　　　　　　; 　　　　.byte　 255　　　　　　　; // + 9, 1: Product revision(8bit) 　　　　.byte　 255,255,255,255　; // +10, 4: Product serial number(32bit) 　　　　.byte　 255　　　　　　　; // +14, 1: Manufacturing date(8bit) 　　　　.byte　 255　　　　　　　; // +15, 1: 7-bit CRC checksum(7bit) "); void pceAppInit() { 　　pceLCDSetBuffer(vbuff); 　　pceLCDDispStart(); } void pceAppProc(int count) { 　　int i; 　　unsigned char* p; 　　memset(vbuff, 0, sizeof vbuff); 　　pceFontSetType(2); 　　pceFontSetPos(0, 0); 　　p = (unsigned char*)&cid; 　　pceFontPrintf("size = %d\n", sizeof(MMC_CID_INFO)); 　　for(i = 0; i < sizeof(MMC_CID_INFO); i++) { 　　　　pceFontPrintf("%02x ", p[i]); 　　} 　　pceLCDTrans(); } void pceAppExit() { } ------------------------------------------------------------------------------------------- ■■ 結果 ■■ size = 16 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ------------------------------------------------------------------------------------------- shortやintのフィールドを、人手で1バイトづつ分解して定義するというのは全く現実的ではありませんが、 Cコンパイラがアセンブラコードを自動生成する分には、やってくれても良さそうに思えますが.... たぶん、EPSONコンパイラはこのようなケースを想定していなかったのだと思います。余談ですが、Linux PC上でGCCを使った場合は、構造体アライメント無しの場合に次のようなアセンブラコードが生成されます。 cid: 　　　　.byte　 -1 　　　　.value　-1 　　　　.byte　 -1 　　　　.byte　 -1 　　　　.byte　 -1 　　　　.byte　 -1 　　　　.byte　 -1 　　　　.byte　 -1 　　　　.byte　 -1 　　　　.long　 -1 　　　　.byte　 -1 　　　　.byte　 -1 最初に見た、P/ECE上での誤った例と同じに見えますが、PCの場合はこれで大丈夫なのです。 Linux PCのアセンブラはP/ECEのアセンブラと違って、初期状態では暗黙のアライメントを行わないみたいです。 ■■■■■■■■■■■■■■■■■■■■ ■構造体パックを使っても大丈夫なケース■ ■■■■■■■■■■■■■■■■■■■■ 以上のように、P/ECE開発環境では__attribute__((packed))による構造体パックがかなり大きな問題を抱えていることがわかりました。通常、「使わないほうが良い」のは間違いありません。が、まったく使えないかというとそうでもなくて、よく注意して使えば役に立つケースもあります。かなり細かい話になりますので、必要なければ読み飛ばしてください。 ①初期済み構造体を使わないケースひとつめは、初期化済み構造体を使わないことが確実にわかっているケースです。 P/ECE上で正しく動作しなかったC言語プログラムを、初期化済み構造体を使わないよう、次のように書き換えてみました。 [構造体アライメント無し、初期化済み構造体を使わない] #include unsigned char vbuff[128 * 88]; //CID(Card IDentification number)　カードIDレジスタ情報構造体 typedef struct tag_MMC_CID_INFO { 　　unsigned char　 ucMID;　　　　　　　// + 0, 1: ManufactureID(8bit) 　　unsigned short　usOID;　　　　　　　// + 1, 2: OEM/Application ID(16bit) 　　unsigned char　 ucPNM[6];　　　　　 // + 3, 6: Product name(48bit) 　　unsigned char　 ucPRV;　　　　　　　// + 9, 1: Product revision(8bit) 　　unsigned long　 ulPSN;　　　　　　　// +10, 4: Product serial number(32bit) 　　unsigned char　 ucMDT;　　　　　　　// +14, 1: Manufacturing date(8bit) 　　unsigned char　 ucCRC;　　　　　　　// +15, 1: 7-bit CRC checksum(7bit) } __attribute__((packed)) MMC_CID_INFO; // =16 MMC_CID_INFO cid; void pceAppInit() { 　　pceLCDSetBuffer(vbuff); 　　pceLCDDispStart(); } void pceAppProc(int count) { 　　int i; 　　unsigned char* p; 　　//構造体フィールドに値をひとつづつ格納　　cid.ucMID = 0xff; 　　cid.usOID = 0xffff; 　　cid.ucPNM[0] = 0xff; 　　cid.ucPNM[1] = 0xff; 　　cid.ucPNM[2] = 0xff; 　　cid.ucPNM[3] = 0xff; 　　cid.ucPNM[4] = 0xff; 　　cid.ucPNM[5] = 0xff; 　　cid.ucPRV = 0xff; 　　cid.ulPSN = 0xffffffff; 　　cid.ucMDT = 0xff; 　　cid.ucCRC = 0xff; 　　memset(vbuff, 0, sizeof vbuff); 　　pceFontSetType(2); 　　pceFontSetPos(0, 0); 　　p = (unsigned char*)&cid; 　　pceFontPrintf("size = %d\n", sizeof(MMC_CID_INFO)); 　　for(i = 0; i < sizeof(MMC_CID_INFO); i++) { 　　　　pceFontPrintf("%02x ", p[i]); 　　} 　　pceLCDTrans(); } void pceAppExit() { } ------------------------------------------------------------------------------------------- ■■ 結果 ■■ size = 16 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ------------------------------------------------------------------------------------------- 正しい結果が得られました。初期化済み構造体の場合はフィールドひとつひとつがデータ定義擬似命令にコンパイルされたため、前述のような暗黙のアライメント問題が発生したわけですが、未初期化構造体の場合はフィールドひとつひとつに対応する擬似命令が生成されるわけではなく、次のようなアセンブラコードが生成されます。 .comm　　cid 16　　; 16バイトのグローバル変数領域を確保せよ、という意味構造体フィールドに値をひとつづつ格納する部分のC言語プログラムは、次のようにコンパイルされます。(読む必要ないです(^^;) xld.w　　%r0,cid xld.w　　%r10,0x000000ff xld.b　　[%r0],%r10　　　　　; + 0, 1: ManufactureID(8bit) xld.ub　 %r11,[%r0+1]　　　　; + 1, 2: OEM/Application ID(16bit) (手順に無駄がありますが、間違いではないです) or　　　 %r11,%r10 xld.b　　[%r0+1],%r11 xld.ub　 %r11,[%r0+2] or　　　 %r11,%r10 xld.b　　[%r0+2],%r11 xld.b　　[%r0+3],%r10　　　　; + 3, 6: Product name(48bit) xld.b　　[%r0+4],%r10 xld.b　　[%r0+5],%r10 xld.b　　[%r0+6],%r10 xld.b　　[%r0+7],%r10 xld.b　　[%r0+8],%r10 xld.b　　[%r0+9],%r10　　　　; + 9, 1: Product revision(8bit) xld.ub　 %r11,[%r0+10]　　　 ; +10, 4: Product serial number(32bit) (手順に無駄がありますが、間違いではないです) or　　　 %r11,%r10 xld.b　　[%r0+10],%r11 xld.ub　 %r11,[%r0+11] or　　　 %r11,%r10 xld.b　　[%r0+11],%r11 xld.ub　 %r11,[%r0+12] or　　　 %r11,%r10 xld.b　　[%r0+12],%r11 xld.ub　 %r11,[%r0+13] or　　　 %r11,%r10 xld.b　　[%r0+13],%r11 xld.b　　[%r0+14],%r10　　　 ; +14, 1: Manufacturing date(8bit) xadd　　 %r1,%r0,15　　　　　; +15, 1: 7-bit CRC checksum(7bit) xld.b　　[%r1],%r10 Cコンパイラは、パックされた構造体の各フィールドの正しいオフセットを認識しているので、正しいコードが生成されています。(ちょっと無駄ありますけれど) いま上で示したプログラム例のような、構造体の各フィールドをプログラムでひとつづつ初期化するケースに加えて、ファイルを読み込んだりデバイスからバイト列を受信して、そのまま構造体変数に格納するケースでも、初期化済み構造体を使う必要がないのでＯＫです。 ②構造体末尾のパディングだけを除去する場合もともと構造体アライメントありの場合にもフィールド間にはパディングがなくって、構造体末尾だけにパディングがあるような場合に、構造体末尾のパディングを取り除いてそのぶん構造体サイズを小さくしたいケースで、__attribute__((packed))が利用可能です。そんな都合の良い話があるか！と言われそうですが(^^;、あります。 USB仕様の構造体です。 USB仕様の構造体は、各フィールドのオフセットに関してはパディング無しで適切なアライメントになるよう定められていることが多いのですけれど、なぜか末尾に1バイトのフィールドがあったりして、構造体パック無しでは末尾にパディングが付いてしまうようなケースがよくあるみたいなのです。たとえば、USB通信端点の特性を記述するための構造体として、エンドポイントディスクリプタという構造体があります。 typedef struct _ENDPOINT_DESCRIPTOR { 　　unsigned char bLength;　　　　　　　　　　/* + 0, 1 */ 　　unsigned char bDescriptorType;　　　　　　/* + 1, 1 */ 　　unsigned char bEndpointAddress;　　　　　 /* + 2, 1 */ 　　unsigned char bAttributes;　　　　　　　　/* + 3, 1 */ 　　unsigned short wMaxPacketSize;　　　　　　 /* + 4, 2 */ 　　unsigned char bInterval;　　　　　　　　　/* + 6, 1 */ } __attribute__((packed)) ENDPOINT_DESCRIPTOR; /* = 7 */ USBデバイス(P/ECE側です)は、デバイスの通信特性をホスト(PC側です)へ知らせるために、エンドポイントディスクリプタをデバイスからホストへ送信します。エンドポイントディスクリプタの内容が変化することはまずないので、初期化済み構造体としてあらかじめ用意しておきます。初期化済みエンドポイントディスクリプタをデバイスからホストへ送信するプログラムは、だいたい次のようなかんじになります。 const ENDPOINT_DESCRIPTOR endpoint_desc_ep2in = { 　　sizeof(ENDPOINT_DESCRIPTOR),　　//unsigned char bLength;　　　　　　/* + 0, 1 */ 　　ENDPOINT_DESCRIPTOR_TYPE,　　　 //unsigned char bDescriptorType;　　/* + 1, 1 */ 　　0x82,　　　　　　　　　　　　　 //unsigned char bEndpointAddress;　 /* + 2, 1 */ 　　2,　　　　　　　　　　　　　　　//unsigned char bAttributes;　　　　/* + 3, 1 */ 　　EP2_NONISO_PACKET_SIZE,　　　　 //unsigned short wMaxPacketSize;　　 /* + 4, 2 */ 　　0,　　　　　　　　　　　　　　　//unsigned char bInterval;　　　　　/* + 6, 1 */ }; D12_WriteEndpoint(1/*出力端点の指定*/, &endpoint_desc_ep2in, sizeof(ENDPOINT_DESCRIPTOR)); ※本当はエンドポイントディスクリプタだけを単体で送信することはないのですけれど、説明を簡単にするために、ここでは考えないことにします。以上は、正しく動作するプログラムの例です。さて、もしもENDPOINT_DESCRIPTORの定義のところで__attribute__((packed))を指定しなかったらどうなるでしょうか？ typedef struct _ENDPOINT_DESCRIPTOR { 　　unsigned char bLength;　　　　　　　　　　/* + 0, 1 */ 　　unsigned char bDescriptorType;　　　　　　/* + 1, 1 */ 　　unsigned char bEndpointAddress;　　　　　 /* + 2, 1 */ 　　unsigned char bAttributes;　　　　　　　　/* + 3, 1 */ 　　unsigned short wMaxPacketSize;　　　　　　 /* + 4, 2 */ 　　unsigned char bInterval;　　　　　　　　　/* + 6, 1 */ 　　(パディング)　　　　　　　　　　　　　　　 /* + 7, 1 */ } ENDPOINT_DESCRIPTOR;　　　　　　　　　　　　 /* = 8 */ const ENDPOINT_DESCRIPTOR endpoint_desc_ep2in = { 　　sizeof(ENDPOINT_DESCRIPTOR),　　//unsigned char bLength;　　　　　　/* + 0, 1 */ ... 本当は7とすべきなのに、8が設定されてしまう!! 　　ENDPOINT_DESCRIPTOR_TYPE,　　　 //unsigned char bDescriptorType;　　/* + 1, 1 */ 　　0x82,　　　　　　　　　　　　　 //unsigned char bEndpointAddress;　 /* + 2, 1 */ 　　2,　　　　　　　　　　　　　　　//unsigned char bAttributes;　　　　/* + 3, 1 */ 　　EP2_NONISO_PACKET_SIZE,　　　　 //unsigned short wMaxPacketSize;　　 /* + 4, 2 */ 　　0,　　　　　　　　　　　　　　　//unsigned char bInterval;　　　　　/* + 6, 1 */ 　　　　　　　　　　　　　　　　　　//(パディング)　　　　　　　　　　　 /* + 7, 1 */ }; D12_WriteEndpoint(1/*出力端点の指定*/, &endpoint_desc_ep2in, sizeof(ENDPOINT_DESCRIPTOR)); // 本当は D12_WriteEndpoint(1, &endpoint_desc_ep2in, 7) とすべきなのに、 // D12_WriteEndpoint(1, &endpoint_desc_ep2in, 8) になってしまう!! bLengthフィールドの値や送信バイト数が正しくないため、このプログラムは正しく動作しません。 bLengthフィールドや送信バイト数として、sizeof(ENDPOINT_DESCRIPTOR)を使うのではなく、明示的に"7"と書けば解決するのですが、ひとつひとつの構造体サイズを覚えるよりも、できるならばsizeofが使えたほうが楽ですよね。ちょっと細かい話になりますが、通常、エンドポイントディスクリプタは複数定義します。が、その際、初期化済みエンドポイントディスクリプタ構造体を、配列にしてはいけません。エンドポイントディスクリプタ構造体は、単体ならばパディング無しで適切なアライメントになっているのですけれど、配列にすると二つ目の要素の途中でアライメントが崩れ、アセンブラによる暗黙のアライメントが行われて、不要なパディングが入ってしまうからです。 const ENDPOINT_DESCRIPTOR endpoint_desc[2] = { { 　　sizeof(ENDPOINT_DESCRIPTOR),　　//unsigned char bLength;　　　　　　/* + 0, 1 */ 　　ENDPOINT_DESCRIPTOR_TYPE,　　　 //unsigned char bDescriptorType;　　/* + 1, 1 */ 　　0x82,　　　　　　　　　　　　　 //unsigned char bEndpointAddress;　 /* + 2, 1 */ 　　2,　　　　　　　　　　　　　　　//unsigned char bAttributes;　　　　/* + 3, 1 */ 　　EP2_NONISO_PACKET_SIZE,　　　　 //unsigned short wMaxPacketSize;　　 /* + 4, 2 */ 　　0,　　　　　　　　　　　　　　　//unsigned char bInterval;　　　　　/* + 6, 1 */ }, { 　　sizeof(ENDPOINT_DESCRIPTOR),　　//unsigned char bLength;　　　　　　/* + 7, 1 */ 　　ENDPOINT_DESCRIPTOR_TYPE,　　　 //unsigned char bDescriptorType;　　/* + 8, 1 */ 　　0x02,　　　　　　　　　　　　　 //unsigned char bEndpointAddress;　 /* + 9, 1 */ 　　2,　　　　　　　　　　　　　　　//unsigned char bAttributes;　　　　/* +10, 1 */ 　　EP2_NONISO_PACKET_SIZE,　　　　 //unsigned short wMaxPacketSize;　　 /* +11, 2 */ 　　0,　　　　　　　　　　　　　　　//unsigned char bInterval;　　　　　/* +13, 1 */ } };　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 /* =14 */ ↓コンパイルすると... 　　.align　2 endpoint_desc: 　　.byte　 7　　　　//unsigned char bLength;　　　　　　/* + 0, 1 */ 　　.byte　 5　　　　//unsigned char bDescriptorType;　　/* + 1, 1 */ 　　.byte　130　　　　//unsigned char bEndpointAddress;　 /* + 2, 1 */ 　　.byte　 2　　　　//unsigned char bAttributes;　　　　/* + 3, 1 */ 　　.half　 64　　　　//unsigned short wMaxPacketSize;　　 /* + 4, 2 */ 　　.byte　 0　　　　//unsigned char bInterval;　　　　　/* + 6, 1 */ 　　.byte　 7　　　　//unsigned char bLength;　　　　　　/* + 7, 1 */ 　　.byte　 5　　　　//unsigned char bDescriptorType;　　/* + 8, 1 */ 　　.byte　 2　　　　//unsigned char bEndpointAddress;　 /* + 9, 1 */ 　　.byte　 2　　　　//unsigned char bAttributes;　　　　/* +10, 1 */ 　　　　　　　　　　　//(ここにパディングが入ってしまう!!) /* +11, 1 */ 　　.half　 64　　　　//unsigned short wMaxPacketSize;　　 /* +12, 2 */ ずれてる!! 　　.byte　 0　　　　//unsigned char bInterval;　　　　　/* +14, 1 */ ずれてる!! 複数のエンドポイントディスクリプタを初期化済み構造体として定義する場合は、配列にするのでなく、ひとつひとつ定義し、実行時にくっつけて送信する必要があります。 const ENDPOINT_DESCRIPTOR endpoint_desc_ep2in = { sizeof(ENDPOINT_DESCRIPTOR), ENDPOINT_DESCRIPTOR_TYPE, 0x82, 2, EP2_NONISO_PACKET_SIZE, 0, }; const ENDPOINT_DESCRIPTOR endpoint_desc_ep2out = { sizeof(ENDPOINT_DESCRIPTOR), ENDPOINT_DESCRIPTOR_TYPE, 0x02, 2, EP2_NONISO_PACKET_SIZE, 0, }; memcpy(&tmpbuf[sizeof(ENDPOINT_DESCRIPTOR) * 0], &endpoint_desc_ep2in, sizeof(ENDPOINT_DESCRIPTOR)); memcpy(&tmpbuf[sizeof(ENDPOINT_DESCRIPTOR) * 1], &endpoint_desc_ep2in, sizeof(ENDPOINT_DESCRIPTOR)); D12_WriteEndpoint(1/*出力端点の指定*/, &tmpbuf, sizeof(ENDPOINT_DESCRIPTOR) * 2); ■■■■■ ■まとめ■ ■■■■■ 結論です。『P/ECE開発環境では、__attribute__((packed))による構造体パックは利用不可です。』確実に問題が回避できると確信できる場合に限って、__attribute__((packed))も利用可能ですが、それはまるで、生のアセンブラやバイナリエディタを使ってデータを操作しているような感覚です。もともと#pargma packや__attribute__((packed))は処理系依存の拡張機能ですし、使わずに済むならばそれに越したことはありません。 * Sat Nov 6 00:00:00 JST 2004 Naoyuki Sawa - 構造体パックに問題あり#1 P/ECE開発環境のCコンパイラには問題があり、構造体パックを行う場合に注意が必要です。今回は、この問題について記しておこうと思います。 P/ECE特有の問題点だけ読みたいかたは、■Ｐ／ＥＣＥの場合～問題発生!!■まで読み飛ばしてください。 ■■■■■■■■■■■■■■■■■ ■一般的な話～構造体アライメント■ ■■■■■■■■■■■■■■■■■ 通常、C言語で構造体を定義すると、各フィールドがフィールドサイズの倍数の位置に揃うように、暗黙の空白領域が追加されます。たとえば次のような構造体を定義したとします。 typedef struct _SAMPLE1 { 　　char c1; 　　short s2; 　　int i3; 　　char c4; } SAMPLE1; これだけ見ると、各フィールドのオフセットとサイズ、および構造体サイズは次のようになるように見えるのですけれど、 (コメント表記は /* +フィールドオフセット, フィールドサイズ */、/* =構造体サイズ */ です。) [誤った配置] typedef struct _STRUCT1 { 　　char c1;　　/* + 0, 1 */ 　　short s2;　　/* + 1, 2 */ 　　short s3;　　/* + 3, 2 */ 　　int i4;　　/* + 5, 4 */ 　　char c5;　　/* + 9, 1 */ } STRUCT1;　　　　/* =10 */ 実際には、各フィールドのオフセットとサイズ、および構造体サイズは次のようになります。 [本当の配置] typedef struct _STRUCT1 { 　　char c1;　　/* + 0, 1 */ 　　(パディング)　/* + 1, 1 */ 　　short s2;　　/* + 2, 2 */ 　　short s3;　　/* + 4, 2 */ 　　(パディング)　/* + 6, 2 */ 　　int i4;　　/* + 8, 4 */ 　　char c5;　　/* +12, 1 */ 　　(パディング)　/* +13, 3 */ } STRUCT1;　　　　/* =16 */ s2フィールド(2バイト整数)に注目してください。 [誤った配置]では、s2フィールドがオフセット1(2の倍数でない)から始まっています。 2の倍数でないアドレスに置かれた2バイト整数の読み書きは、CPUの種類によってはできなかったり、できても効率が悪かったりします。そこで、2バイト整数が2の倍数のアドレスから始まるよう、s2フィールドの直前に暗黙の空白領域が追加されるのです。暗黙の空白領域のことを、“パディング”(詰め物)と呼んだりします。 i4フィールド(4バイト整数)についても同様です。 4の倍数でないアドレスに置かれた4バイト整数の読み書きは、CPUの種類によってはできなかったり、できても効率が悪かったりします。そこで、4バイト整数が4の倍数のアドレスから始まるよう、i4フィールドの直前にパディングが追加されます。一見、構造体末尾のパディングは不要に見えます。なぜこれが必要かというと、構造体配列を定義したときのためです。もしも構造体末尾の空白領域がなかったとすると、次のような構造体配列を定義したときに、 STRUCT1 struct1[2]; メモリ上の配置は次のようになってしまいます。 [誤った配置] // struct1[0] char c1;　　/* + 0, 1 */ (パディング)　/* + 1, 1 */ short s2;　　/* + 2, 2 */ short s3;　　/* + 4, 2 */ (パディング)　/* + 6, 2 */ int i4;　　/* + 8, 4 */ char c5;　　/* +12, 1 */ // struct1[1] char c1;　　/* +13, 1 */ (パディング)　/* +14, 1 */ short s2;　　/* +15, 2 */ short s3;　　/* +17, 2 */ (パディング)　/* +19, 2 */ int i4;　　/* +21, 4 */ char c5;　　/* +25, 1 */ struct1[0]は適切なフィールド配置ですが、struct1[1]のs2やs3、i4の配置が適切でありません。 s2とs3は2バイト整数なのに2の倍数アドレスに配置されず、i4は4バイト整数なのに4の倍数アドレスに配置されていません。このような問題を避けるため、構造体サイズが「構造体の中のいちばん大きなフィールドのサイズの倍数」になるよう、構造体の末尾にもパディングが追加されます。 [正しい配置] // struct1[0] char c1;　　/* + 0, 1 */ (パディング)　/* + 1, 1 */ short s2;　　/* + 2, 2 */ short s3;　　/* + 4, 2 */ (パディング)　/* + 6, 2 */ int i4;　　/* + 8, 4 */ char c5;　　/* +12, 1 */ (パディング)　/* +13, 3 */ // struct1[1] char c1;　　/* +16, 1 */ (パディング)　/* +17, 1 */ short s2;　　/* +18, 2 */ short s3;　　/* +20, 2 */ (パディング)　/* +22, 2 */ int i4;　　/* +24, 4 */ char c5;　　/* +28, 1 */ (パディング)　/* +29, 3 */ 以上のように、コンパイラが自動的にパディングを追加して、各フィールドの配置を適切に保つことを、“構造体アライメント”と呼んだりします。 ■■■■■■■■■■■■■■■■■■■■■■ ■一般的な話～構造体アライメントを抑制する■ ■■■■■■■■■■■■■■■■■■■■■■ 通常は、コンパイラが自動的に構造体アライメントを行ってくれるので、プログラマは特に気にする必要はありません。が、稀に、構造体アライメントが行われては困る場合があります。ネットワークやデバイスとの通信など、あらかじめ仕様で決められたフィールド配置の構造体を送受信する場合です。ネットワークやデバイスとの通信では、通信データ量を少なくするために、2バイト整数や4バイト整数もパディング無しでびっちり詰め込まれている場合が多いです。メモリ上に構造体を作っておいて、そのメモリイメージを直接送信する場合や、メモリ上の構造体変数に直接受信する場合、構造体のフィールド配置はあらかじめ決められた仕様にきっちり合っていなければいけません。たとえば、MMC(Multi Media Card)との通信では、次のような構造体の仕様が定められています。 (まどかの世界さんの、MMC対応カーネルのソースから引用させていただきました) [正しい配置] //CID(Card IDentification number)　カードIDレジスタ情報構造体 typedef struct tag_MMC_CID_INFO { 　　unsigned char ucMID;　　　// + 0, 1: ManufactureID(8bit) 　　unsigned short usOID;　　　// + 1, 2: OEM/Application ID(16bit) 　　unsigned char ucPNM[6]; 　// + 3, 6: Product name(48bit) 　　unsigned char ucPRV;　　　// + 9, 1: Product revision(8bit) 　　unsigned long ulPSN;　　　// +10, 4: Product serial number(32bit) 　　unsigned char ucMDT;　　　// +14, 1: Manufacturing date(8bit) 　　unsigned char ucCRC;　　　// +15, 1: 7-bit CRC checksum(7bit) } MMC_CID_INFO; 　　　　　　　　// =16 ところが、コンパイラによって構造体アライメントが行われると、実際の配置は次のようになってしまいます。 [誤った配置] //CID(Card IDentification number)　カードIDレジスタ情報構造体 typedef struct tag_MMC_CID_INFO { 　　unsigned char ucMID;　　　// + 0, 1: ManufactureID(8bit) 　　(パディング) // + 1, 1: 　　unsigned short usOID;　　　// + 2, 2: OEM/Application ID(16bit) 　　unsigned char ucPNM[6]; 　// + 4, 6: Product name(48bit) 　　unsigned char ucPRV;　　　// +10, 1: Product revision(8bit) 　　(パディング) // +11, 1: 　　unsigned long ulPSN;　　　// +12, 4: Product serial number(32bit) 　　unsigned char ucMDT;　　　// +16, 1: Manufacturing date(8bit) 　　unsigned char ucCRC;　　　// +17, 1: 7-bit CRC checksum(7bit) 　　(パディング) // +18, 2: } MMC_CID_INFO; 　　　　　　　　// =20 これではダメです。そこで、コンパイラによる構造体アライメントを抑制し、パディングをなくす方法が用意されています。構造体アライメントを抑制する方法は、コンパイラ毎に違っています。たとえば、Visual C++の場合は、次のようにします。 #pragma pack(1) //CID(Card IDentification number)　カードIDレジスタ情報構造体 typedef struct tag_MMC_CID_INFO { 　　unsigned char ucMID;　　　// + 0, 1: ManufactureID(8bit) 　　unsigned short usOID;　　　// + 1, 2: OEM/Application ID(16bit) 　　unsigned char ucPNM[6]; 　// + 3, 6: Product name(48bit) 　　unsigned char ucPRV;　　　// + 9, 1: Product revision(8bit) 　　unsigned long ulPSN;　　　// +10, 4: Product serial number(32bit) 　　unsigned char ucMDT;　　　// +14, 1: Manufacturing date(8bit) 　　unsigned char ucCRC;　　　// +15, 1: 7-bit CRC checksum(7bit) } MMC_CID_INFO; 　　　　　　　　// =16 #pragma pack() GCCの場合は、次のようにします。 //CID(Card IDentification number)　カードIDレジスタ情報構造体 typedef struct tag_MMC_CID_INFO { 　　unsigned char ucMID;　　　　　　　// + 0, 1: ManufactureID(8bit) 　　unsigned short usOID;　　　　　　　// + 1, 2: OEM/Application ID(16bit) 　　unsigned char ucPNM[6]; 　　　　　// + 3, 6: Product name(48bit) 　　unsigned char ucPRV;　　　　　　　// + 9, 1: Product revision(8bit) 　　unsigned long ulPSN;　　　　　　　// +10, 4: Product serial number(32bit) 　　unsigned char ucMDT;　　　　　　　// +14, 1: Manufacturing date(8bit) 　　unsigned char ucCRC;　　　　　　　// +15, 1: 7-bit CRC checksum(7bit) } __attribute__((packed)) MMC_CID_INFO; // =16 ※厳密に言うと、MMCとの通信データはバイト順がモトローラ並びで、PentiumやS1C33(P/ECEのCPU)のインテル並びとは逆です。　だから、構造体アライメントだけ無くしても、メモリイメージそのままで送受信することはできません。　が、説明を簡単にするために、ここではバイト順の違いは考えないことにしてください。それでは、本当に構造体アライメントが抑制されているか、確認してみましょう。テストのために、メモリ上に初期化済みの構造体を用意し、その内容を1バイトづつ表示してみることにします。まずは、構造体アライメントを★抑制しない★場合のメモリ内容を確かめてみます。 [Windows PC & Visual C++ 6.0、構造体アライメントあり] #include //CID(Card IDentification number)　カードIDレジスタ情報構造体 typedef struct tag_MMC_CID_INFO { 　　unsigned char　 ucMID;　　　// + 0, 1: ManufactureID(8bit) 　　unsigned short　usOID;　　　// + 2, 2: OEM/Application ID(16bit) 　　unsigned char　 ucPNM[6];　 // + 4, 6: Product name(48bit) 　　unsigned char　 ucPRV;　　　// +10, 1: Product revision(8bit) 　　unsigned long　 ulPSN;　　　// +12, 4: Product serial number(32bit) 　　unsigned char　 ucMDT;　　　// +16, 1: Manufacturing date(8bit) 　　unsigned char　 ucCRC;　　　// +17, 1: 7-bit CRC checksum(7bit) } MMC_CID_INFO;　　　　　　　　 // =20 MMC_CID_INFO cid = { 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucMID;　　// + 0, 1: ManufactureID(8bit) 　　0xffff,　　　　　　　　　　　　　　　　 // unsigned short　usOID;　　// + 2, 2: OEM/Application ID(16bit) 　　{ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }, // unsigned char　 ucPNM[6]; // + 4, 6: Product name(48bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucPRV;　　// +10, 1: Product revision(8bit) 　　0xffffffff, 　　　　　　　　　　　　　　// unsigned long　 ulPSN;　　// +12, 4: Product serial number(32bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucMDT;　　// +16, 1: Manufacturing date(8bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucCRC;　　// +17, 1: 7-bit CRC checksum(7bit) }; int main() { 　　int i; 　　unsigned char* p; 　　p = (unsigned char*)&cid; 　　printf("size = %d\n", sizeof(MMC_CID_INFO)); 　　for(i = 0; i < sizeof(MMC_CID_INFO); i++) { 　　　　printf("%02x ", p[i]); 　　} 　　return 0; } ------------------------------------------------------------------------------------------- ■■ 結果 ■■ size = 20 ff 00 ff ff ff ff ff ff ff ff ff 00 ff ff ff ff ff ff 00 00 ------------------------------------------------------------------------------------------- 構造体アライメントありなので、パディングが追加されています。(00の部分) 構造体サイズもパディングの分増えて、MMC仕様よりも4バイト多い20バイトになっています。次に、構造体アライメントを★抑制した★場合のメモリ内容を確かめてみます。 [Windows PC & Visual C++ 6.0、構造体アライメント無し] #include #pragma pack(1) //CID(Card IDentification number)　カードIDレジスタ情報構造体 typedef struct tag_MMC_CID_INFO { 　　unsigned char　 ucMID;　　　// + 0, 1: ManufactureID(8bit) 　　unsigned short　usOID;　　　// + 1, 2: OEM/Application ID(16bit) 　　unsigned char　 ucPNM[6];　 // + 3, 6: Product name(48bit) 　　unsigned char　 ucPRV;　　　// + 9, 1: Product revision(8bit) 　　unsigned long　 ulPSN;　　　// +10, 4: Product serial number(32bit) 　　unsigned char　 ucMDT;　　　// +14, 1: Manufacturing date(8bit) 　　unsigned char　 ucCRC;　　　// +15, 1: 7-bit CRC checksum(7bit) } MMC_CID_INFO;　　　　　　　　 // =16 #pragma pack() MMC_CID_INFO cid = { 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucMID;　　// + 0, 1: ManufactureID(8bit) 　　0xffff,　　　　　　　　　　　　　　　　 // unsigned short　usOID;　　// + 1, 2: OEM/Application ID(16bit) 　　{ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }, // unsigned char　 ucPNM[6]; // + 3, 6: Product name(48bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucPRV;　　// + 9, 1: Product revision(8bit) 　　0xffffffff, 　　　　　　　　　　　　　　// unsigned long　 ulPSN;　　// +10, 4: Product serial number(32bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucMDT;　　// +14, 1: Manufacturing date(8bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucCRC;　　// +15, 1: 7-bit CRC checksum(7bit) }; int main() { 　　int i; 　　unsigned char* p; 　　p = (unsigned char*)&cid; 　　printf("size = %d\n", sizeof(MMC_CID_INFO)); 　　for(i = 0; i < sizeof(MMC_CID_INFO); i++) { 　　　　printf("%02x ", p[i]); 　　} 　　return 0; } ------------------------------------------------------------------------------------------- ■■ 結果 ■■ size = 16 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ------------------------------------------------------------------------------------------- パディングが消えて、構造体サイズもMMC仕様どおりの16バイトになりました。 GCCの場合も同様です。まずは、構造体アライメントを★抑制しない★場合。 [Linux PC & GCC 3.3.3、構造体アライメントあり] #include //CID(Card IDentification number)　カードIDレジスタ情報構造体 typedef struct tag_MMC_CID_INFO { 　　unsigned char　 ucMID;　　　// + 0, 1: ManufactureID(8bit) 　　unsigned short　usOID;　　　// + 2, 2: OEM/Application ID(16bit) 　　unsigned char　 ucPNM[6];　 // + 4, 6: Product name(48bit) 　　unsigned char　 ucPRV;　　　// +10, 1: Product revision(8bit) 　　unsigned long　 ulPSN;　　　// +12, 4: Product serial number(32bit) 　　unsigned char　 ucMDT;　　　// +16, 1: Manufacturing date(8bit) 　　unsigned char　 ucCRC;　　　// +17, 1: 7-bit CRC checksum(7bit) } MMC_CID_INFO;　　　　　　　　 // =20 MMC_CID_INFO cid = { 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucMID;　　// + 0, 1: ManufactureID(8bit) 　　0xffff,　　　　　　　　　　　　　　　　 // unsigned short　usOID;　　// + 2, 2: OEM/Application ID(16bit) 　　{ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }, // unsigned char　 ucPNM[6]; // + 4, 6: Product name(48bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucPRV;　　// +10, 1: Product revision(8bit) 　　0xffffffff, 　　　　　　　　　　　　　　// unsigned long　 ulPSN;　　// +12, 4: Product serial number(32bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucMDT;　　// +16, 1: Manufacturing date(8bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucCRC;　　// +17, 1: 7-bit CRC checksum(7bit) }; int main() { 　　int i; 　　unsigned char* p; 　　p = (unsigned char*)&cid; 　　printf("size = %d\n", sizeof(MMC_CID_INFO)); 　　for(i = 0; i < sizeof(MMC_CID_INFO); i++) { 　　　　printf("%02x ", p[i]); 　　} 　　return 0; } ------------------------------------------------------------------------------------------- ■■ 結果 ■■ size = 20 ff 00 ff ff ff ff ff ff ff ff ff 00 ff ff ff ff ff ff 00 00 ------------------------------------------------------------------------------------------- 次に、構造体アライメントを★抑制した★場合。 [Linux PC & GCC 3.3.3、構造体アライメント無し] #include //CID(Card IDentification number)　カードIDレジスタ情報構造体 typedef struct tag_MMC_CID_INFO { 　　unsigned char　 ucMID;　　　　　　　// + 0, 1: ManufactureID(8bit) 　　unsigned short　usOID;　　　　　　　// + 1, 2: OEM/Application ID(16bit) 　　unsigned char　 ucPNM[6];　　　　　 // + 3, 6: Product name(48bit) 　　unsigned char　 ucPRV;　　　　　　　// + 9, 1: Product revision(8bit) 　　unsigned long　 ulPSN;　　　　　　　// +10, 4: Product serial number(32bit) 　　unsigned char　 ucMDT;　　　　　　　// +14, 1: Manufacturing date(8bit) 　　unsigned char　 ucCRC;　　　　　　　// +15, 1: 7-bit CRC checksum(7bit) } __attribute__((packed)) MMC_CID_INFO; // =16 MMC_CID_INFO cid = { 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucMID;　　// + 0, 1: ManufactureID(8bit) 　　0xffff,　　　　　　　　　　　　　　　　 // unsigned short　usOID;　　// + 1, 2: OEM/Application ID(16bit) 　　{ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }, // unsigned char　 ucPNM[6]; // + 3, 6: Product name(48bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucPRV;　　// + 9, 1: Product revision(8bit) 　　0xffffffff, 　　　　　　　　　　　　　　// unsigned long　 ulPSN;　　// +10, 4: Product serial number(32bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucMDT;　　// +14, 1: Manufacturing date(8bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucCRC;　　// +15, 1: 7-bit CRC checksum(7bit) }; int main() { 　　int i; 　　unsigned char* p; 　　p = (unsigned char*)&cid; 　　printf("size = %d\n", sizeof(MMC_CID_INFO)); 　　for(i = 0; i < sizeof(MMC_CID_INFO); i++) { 　　　　printf("%02x ", p[i]); 　　} 　　return 0; } ------------------------------------------------------------------------------------------- ■■ 結果 ■■ size = 16 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ------------------------------------------------------------------------------------------- 期待通りです。構造体アライメントを抑制することを、“構造体パック”と呼んだりします。 ■■■■■■■■■■■■■■■■ ■Ｐ／ＥＣＥの場合～問題発生!!■ ■■■■■■■■■■■■■■■■ 上述のGCCの例は、PC上でLinux(FedoraCore2)を使って行いました。さて、P/ECE開発環境のCコンパイラもGCCです。ちょっとバージョンが古いけど、PC上でLinuxを使った場合と同じ結果が期待されます。まずは、構造体アライメントを★抑制しない★場合。 [P/ECE & pcc33.exe、構造体アライメントあり] #include unsigned char vbuff[128 * 88]; //CID(Card IDentification number)　カードIDレジスタ情報構造体 typedef struct tag_MMC_CID_INFO { 　　unsigned char　 ucMID;　　　// + 0, 1: ManufactureID(8bit) 　　unsigned short　usOID;　　　// + 2, 2: OEM/Application ID(16bit) 　　unsigned char　 ucPNM[6];　 // + 4, 6: Product name(48bit) 　　unsigned char　 ucPRV;　　　// +10, 1: Product revision(8bit) 　　unsigned long　 ulPSN;　　　// +12, 4: Product serial number(32bit) 　　unsigned char　 ucMDT;　　　// +16, 1: Manufacturing date(8bit) 　　unsigned char　 ucCRC;　　　// +17, 1: 7-bit CRC checksum(7bit) } MMC_CID_INFO;　　　　　　　　 // =20 MMC_CID_INFO cid = { 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucMID;　　// + 0, 1: ManufactureID(8bit) 　　0xffff,　　　　　　　　　　　　　　　　 // unsigned short　usOID;　　// + 2, 2: OEM/Application ID(16bit) 　　{ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }, // unsigned char　 ucPNM[6]; // + 4, 6: Product name(48bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucPRV;　　// +10, 1: Product revision(8bit) 　　0xffffffff, 　　　　　　　　　　　　　　// unsigned long　 ulPSN;　　// +12, 4: Product serial number(32bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucMDT;　　// +16, 1: Manufacturing date(8bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucCRC;　　// +17, 1: 7-bit CRC checksum(7bit) }; void pceAppInit() { 　　pceLCDSetBuffer(vbuff); 　　pceLCDDispStart(); } void pceAppProc(int count) { 　　int i; 　　unsigned char* p; 　　memset(vbuff, 0, sizeof vbuff); 　　pceFontSetType(2); 　　pceFontSetPos(0, 0); 　　p = (unsigned char*)&cid; 　　pceFontPrintf("size = %d\n", sizeof(MMC_CID_INFO)); 　　for(i = 0; i < sizeof(MMC_CID_INFO); i++) { 　　　　pceFontPrintf("%02x ", p[i]); 　　} 　　pceLCDTrans(); } void pceAppExit() { } ------------------------------------------------------------------------------------------- ■■ 結果 ■■ size = 20 ff 00 ff ff ff ff ff ff ff ff ff 00 ff ff ff ff ff ff 00 00 ------------------------------------------------------------------------------------------- あとは、構造体アライメントを★抑制した★場合が期待通りの結果ならば、全てＯＫなのですが・・・ [P/ECE & pcc33.exe、構造体アライメント無し] #include unsigned char vbuff[128 * 88]; //CID(Card IDentification number)　カードIDレジスタ情報構造体 typedef struct tag_MMC_CID_INFO { 　　unsigned char　 ucMID;　　　　　　　// + 0, 1: ManufactureID(8bit) 　　unsigned short　usOID;　　　　　　　// + 1, 2: OEM/Application ID(16bit) 　　unsigned char　 ucPNM[6];　　　　　 // + 3, 6: Product name(48bit) 　　unsigned char　 ucPRV;　　　　　　　// + 9, 1: Product revision(8bit) 　　unsigned long　 ulPSN;　　　　　　　// +10, 4: Product serial number(32bit) 　　unsigned char　 ucMDT;　　　　　　　// +14, 1: Manufacturing date(8bit) 　　unsigned char　 ucCRC;　　　　　　　// +15, 1: 7-bit CRC checksum(7bit) } __attribute__((packed)) MMC_CID_INFO; // =16 MMC_CID_INFO cid = { 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucMID;　　// + 0, 1: ManufactureID(8bit) 　　0xffff,　　　　　　　　　　　　　　　　 // unsigned short　usOID;　　// + 1, 2: OEM/Application ID(16bit) 　　{ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }, // unsigned char　 ucPNM[6]; // + 3, 6: Product name(48bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucPRV;　　// + 9, 1: Product revision(8bit) 　　0xffffffff, 　　　　　　　　　　　　　　// unsigned long　 ulPSN;　　// +10, 4: Product serial number(32bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucMDT;　　// +14, 1: Manufacturing date(8bit) 　　0xff,　　　　　　　　　　　　　　　　　 // unsigned char　 ucCRC;　　// +15, 1: 7-bit CRC checksum(7bit) }; void pceAppInit() { 　　pceLCDSetBuffer(vbuff); 　　pceLCDDispStart(); } void pceAppProc(int count) { 　　int i; 　　unsigned char* p; 　　memset(vbuff, 0, sizeof vbuff); 　　pceFontSetType(2); 　　pceFontSetPos(0, 0); 　　p = (unsigned char*)&cid; 　　pceFontPrintf("size = %d\n", sizeof(MMC_CID_INFO)); 　　for(i = 0; i < sizeof(MMC_CID_INFO); i++) { 　　　　pceFontPrintf("%02x ", p[i]); 　　} 　　pceLCDTrans(); } void pceAppExit() { } ------------------------------------------------------------------------------------------- ■■ 結果 ■■ size = 16 ff 00 ff ff ff ff ff ff ff ff ff 00 ff ff ff ff ------------------------------------------------------------------------------------------- 問題発生です!! 構造体サイズは確かに仕様どおりの16バイトになっているのですが、なぜかパディングが残っています。わかりやすいように、結果出力を並び替えてみます。 ------------------------------------------------------------------------------------------- ■■ 結果 ■■ size = 16 ff　　　　　　　　　// + 0, 1: ManufactureID(8bit) 00　　　　　　　　　// + 1, 1: なぜかパディングが残っている？ ff ff　　　　　　　 // + 2, 2: OEM/Application ID(16bit) ff ff ff ff ff ff　 // + 4, 6: Product name(48bit) ff　　　　　　　　　// +10, 1: Product revision(8bit) 00　　　　　　　　　// +11, 1: なぜかパディングが残っている？ ff ff ff ff　　　　 // +12, 4: Product serial number(32bit) ??　　　　　　　　　// +??, 1: Manufacturing date(8bit) はどこへ行った？ ??　　　　　　　　　// +??, 1: 7-bit CRC checksum(7bit) はどこへ行った？ ------------------------------------------------------------------------------------------- いったいどうなっているのでしょう？この問題、P/ECE開発環境のCコンパイラ(gcc33.exe)とアセンブラ(as33.exe)の協調が上手くいっていないことが原因なのです。詳しくは、次回に。 (続きます…) * Sat May 16 00:00:00 JST 2004 Naoyuki Sawa - Zlibを実装してみる#2 前回は、省メモリなZlib展開ルーチンを実装してみました。また、そのルーチンを使ってZlib形式の圧縮ファイルを展開し、画面表示するサンプルを作成しました。しかしながら、Zlib形式の圧縮ファイルは、そのままでは少々使いづらい面があります。いちばんの問題は、Zlib形式に対応した圧縮・展開ツールが普及していない、という点です。 Zlibの仕様書によると、実は「Zlib形式」とは、圧縮方法まで含めた仕様ではないそうです。圧縮方法を示したヘッダと、圧縮データ本体、そして検査用コードの並びを既定しているだけの仕様です。図で示すと、こんな感じです。＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋｜Ｚｌｉｂヘッダ　　　　　　　　　　　　　　　　　　　　｜←Zlib仕様＋－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜Ｚｌｉｂヘッダに書いてある圧縮方法を使った、圧縮データ｜＋－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜検査用コード　　　　　　　　　　　　　　　　　　　　　｜←Zlib仕様＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋ Windows WAVファイル形式が、PCM形式・ADPCM形式・MP3形式など、いろいろな内部形式を持っているのに似ています。さて、現在のところZlib形式で利用可能な圧縮方法としては、「Deflate圧縮形式」だけが規定されています。一般にZlib形式と呼ばれるのは、厳密には「Deflate圧縮形式の圧縮データを持った、Zlib形式のファイル」のことだったのです。もちろん、前回実装したZlib展開ルーチンも、Deflate圧縮形式に基くものです。先ほどの図を書き直すと、次のようになります。＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋｜Ｚｌｉｂヘッダ　　　　　　　　｜←Zlib仕様＋－－－－－－－－－－－－－－－＋｜Ｄｅｆｌａｔｅ形式の圧縮データ｜＋－－－－－－－－－－－－－－－＋｜検査用コード　　　　　　　　　｜←Zlib仕様＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋ Zlib形式の圧縮ファイルを扱うには、圧縮・展開ツールがZlib形式のヘッダや検査用コードを認識できなければいけません。複数の形式に対応した圧縮・展開ツールは様々ありますが、Zlib形式を扱うことのできるツールは見つけられませんでした。僕は、こちらのサンプルプログラムをそのままZlib圧縮・展開ツールとして使わせて頂いています。「Haruhiko Okumura's Home Page(http://www.matsusaka-u.ac.jp/~okumura/)」さんのサイトの、「zlib 入門(http://www.matsusaka-u.ac.jp/~okumura/compression/zlib.html)」のページの、「comptest.c(http://www.matsusaka-u.ac.jp/~okumura/compression/comptest.c)」。コンパイルするためには、オリジナルのZlib(http://www.gzip.org/zlib/)が必要です。さて、Zlib形式よりも圧倒的にメジャーな圧縮ファイル形式として、「Zip形式」があります。 Zip形式も、Zlib形式と同じく、圧縮方法までを定めた仕様ではありません。様々な圧縮方法を使った圧縮データの格納方法や、ファイル情報を付加する方法等を定めた仕様です。 Zip形式が扱う“様々な圧縮方法”の中でも特に良く利用されるのが、前出の「Deflate圧縮形式」です。同じDeflate圧縮形式を使ったZlib形式とZip形式は、ガワが違うだけで本質はほとんど同じ、と言えます。 Zlib形式と違って、Zip形式は複数のファイルをまとめて格納できるので、図で示すとこんな感じになります。＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋｜Ｚｉｐファイルヘッダ１、検査用コードも含む　　　　　　　　　　　｜←Zip仕様＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜Ｚｉｐファイルヘッダ１に書いてある圧縮方法を使った、圧縮データ１｜＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋｜Ｚｉｐファイルヘッダ２、検査用コードも含む　　　　　　　　　　　｜←Zip仕様＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜Ｚｉｐファイルヘッダ２に書いてある圧縮方法を使った、圧縮データ２｜＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋｜　　　　　　　　　　　　　　　・　　　　　　　　　　　　　　　　｜｜　　　　　　　　　　　　　　　・　　　　　　　　　　　　　　　　｜｜　　　　　　　　　　　　　　　・　　　　　　　　　　　　　　　　｜＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋｜ＺｉｐファイルヘッダＮ、検査用コードも含む　　　　　　　　　　　｜←Zip仕様＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜ＺｉｐファイルヘッダＮに書いてある圧縮方法を使った、圧縮データＮ｜＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋｜その他のＺｉｐファイル情報　　　　　　　　　　　　　　　　　　　｜←Zip仕様＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋あるZipファイル内の圧縮データが、全てDeflate圧縮形式を利用していたならば、先ほどの図は次のようになります。＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋｜Ｚｉｐファイルヘッダ１、検査用コードも含む｜←Zip仕様＋－－－－－－－－－－－－－－－－－－－－－＋｜Ｄｅｆｌａｔｅ形式の圧縮データ１　　　　　｜＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋｜Ｚｉｐファイルヘッダ２、検査用コードも含む｜←Zip仕様＋－－－－－－－－－－－－－－－－－－－－－＋｜Ｄｅｆｌａｔｅ形式の圧縮データ２　　　　　｜＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋｜　　　　　　　　　　・　　　　　　　　　　｜｜　　　　　　　　　　・　　　　　　　　　　｜＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋｜ＺｉｐファイルヘッダＮ、検査用コードも含む｜←Zip仕様＋－－－－－－－－－－－－－－－－－－－－－＋｜Ｄｅｆｌａｔｅ形式の圧縮データＮ　　　　　｜＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋｜その他のＺｉｐファイル情報　　　　　　　　｜←Zip仕様＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋ Zipファイルに格納する圧縮データの形式としては、Deflate圧縮形式以外にもいくつかの圧縮方法が規定されています。しかし、手元にある多くのZipファイルを調べてみたところ、実際に使われていた圧縮方法は二種類だけでした。・無圧縮・Deflate圧縮形式従って、これら二種類の圧縮形式に対応するだけで、実用上は充分なZip展開ルーチンとなるはずです。無圧縮形式については、格納されているデータをそのままコピーするだけです。 Deflate圧縮形式については、前回作成したZlib展開ルーチンの内部処理が流用できそうです。 Zlibヘッダと検査コードを扱っている部分のプログラムを少し修正するだけで、Zip展開ルーチンを作成できました。 Zip展開ルーチンを利用したサンプルはこちら。 P/ECE用とWindows用のテストプログラムを用意しました。 P/ECE用テストプログラムは、Zipファイルに格納された画像ファイルを、次々自動的に表示します。 Windowsテストプログラム用は、Zipファイルに格納されたファイル一覧から、選択された画像を展開して表示します。 http://www.piece-me.org/archive/pzltest-20040316-piece.zip http://www.piece-me.org/archive/pzltest-20040316-win32.zip 前回と今回とで、Zlib/Zip展開ルーチンを実装してみました。二年近く、よくわからないままに使っていたZlibライブラリでしたが、今回のプログラミングでやっと理解することができました。 Zlib/Zip形式の仕組みを理解するために、以下の記事がとても参考になりました。お礼を申し上げるとともに、ご紹介させて頂きます。「LabVIEW情報交換のページ(http://www.asahi-net.or.jp/~WR9K-OOHS/)」さんのサイトの、「ナイジェル山口コーナー(http://www.asahi-net.or.jp/~WR9K-OOHS/Pages/Nigel's/nigel.html)」のページ。 Zlibの仕様書の、いちばん重要な部分に関する和訳があります。また、圧縮技法の詳細について、わかりやすく論じられています。圧縮技法以外にも、興味深い記事がたくさんあります。「ＫＯＮＥ's Ｄ－Station(http://kone.vis.ne.jp/)」さんのサイトの、「気まぐれな戯れ言(http://kone.vis.ne.jp/diary/)」のページ。 CRCの計算方法が、順を追って解説されています。 Zip形式で使われているCRC-32の計算方法、多くの実装例はテーブルを利用していますが、そのテーブルはどこから出てくるのか？こちらのページを読んで疑問が解決しました。今回の作成したZip展開ルーチンは、テーブルを利用しない基本的な方法で実装してみました。 * Sat May 13 16:00:00 JST 2004 Naoyuki Sawa - Zlibを実装してみる#1 2002年6月14日～17日のP/ECE研究記録「zlibを使う#1～3」にて、P/ECE用プログラムでZlibを使う方法を調べました。その後、いくつかの自作プログラムで、実際にZlibを利用しました。それらは一応上手く動作したのですが、P/ECE用プログラムではZlibが使いづらいと感じる点もいくつかありました。いちばんの問題は、「zlibを使う#1～3」でも書いたように、メモリ消費量が多すぎる点です。圧縮データを格納しておく入力バッファ、展開データを作成するための出力バッファの他に、約35キロバイトの作業用メモリが必要です。 P/ECE用プログラムでは、実際に利用する圧縮データや展開データはさほど大きくありません。たいてい数キロバイト程度です。それよりも、Zlib内部の一時的な作業用メモリのために、35キロバイトも必要なのがかなり厳しいところです。 Zlibが作業用メモリを確保できないと、展開処理が失敗してしまいます。その後「P/ECE HAND BOOK」に、P/ECEカーネルソースの展開ルーチンを使う方法が掲載されました。 P/ECEカーネルソースの展開ルーチンも同じZlibですが、P/ECEのメモリ構成に特化していて、より少ないメモリで展開処理が可能です。また、「P/ECE HAND BOOK」の方法を元にして、複数の圧縮ファイルをまとめて扱う方法が、「てとら★ぽっと(http://www.zurachu.net/)」さんのサイトで紹介(http://www.zurachu.net/piece/tips/ppack.html)されています。 Zlibにこだわらなければ、より高速な圧縮・展開方法が「p/ware(http://park17.wakwak.com/~hitode/piece/index.html)」さんのサイトで紹介(http://park17.wakwak.com/~hitode/piece/index.html#plz)されています。これらの方法を使わせてもらえば実用上は問題解決なのですが、もう少しだけ素のZlibにこだわってみたいと思います。そもそも僕がZlibの内部動作を理解しないまま使っていたのが問題なので、この機会に勉強してみようというわけです。さて、なぜZlibはこんなに大きな作業用メモリを必要とするのでしょうか？ Zlibの圧縮・展開アルゴリズムは、「ハフマン符号化」と「スライド辞書圧縮」に基づいています。ハフマン符号化は、頻繁に現れる値に小さな符号、稀に現れる値に大きな符号を割り振って、全体のサイズを小さくする方法です。ハフマン符号化の展開処理には、「ハフマン木」というデータ構造が利用されます。「ハフマン木」は、ハフマン符号から元の値に変換するための辞書となります。「ハフマン木」を作成するために、いくらかのメモリが必要です。これが、Zlibが大きな作業用メモリを必要とする理由の一つ目です。しかし実際には、Zlibで利用される「ハフマン木」はさほど大きなデータではありません。せいぜい数キロバイト程度です。より大きなメモリを必要としているのは、スライド辞書圧縮アルゴリズムで利用される「スライド窓」データ構造です。スライド辞書圧縮とは、同じパターンのデータ並びを距離と長さに置き換えて、全体のサイズを小さくする方法です。例えば「012345678901234」というデータ並びがあった場合、次のような感じで圧縮します。「0123456789、10文字前から、5文字繰り返し」ところで、Zlibの実装は入力も出力も基本的にストリーミングです。つまり、一度読み込んだデータは再び読み込めない、一度出力したデータはもう忘れた、というわけです。しかし、10文字前のデータをもう一度出力するためには、10文字前に出力したデータを覚えておかなければいけません。そこで、いくらかの出力バッファを用意し、過去何文字分かの出力履歴を記憶しておきます。これを「スライド窓」と呼びます。 Zlibの仕様では、最大で「3万2千文字前から、258文字繰り返し」という指示が有り得ることになっています。従って、過去3万2千文字分の出力履歴を記憶しておかなければいけません。つまり、32キロバイトのスライド窓が必要となります。これで疑問が解決しました。35キロバイトの作業用メモリの大部分は、スライド窓に使われていたのです。さて、さきほど“Zlibの実装は入力も出力も基本的にストリーミング”だからスライド窓が必要、と書きました。より限定すると、“出力がストリーミングだから”出力履歴を記憶しておくためにスライド窓が必要となります。では、出力をストリーミングにする必要はあるのでしょうか？僕が作ったP/ECE＆Zlib使用のプログラムで、出力ストリーミングを活用したケースはたった一度だけでした。「VGMプレイヤー」です。 VGMプレイヤーでは、VGZ形式で圧縮された演奏データを少しづつ展開しながら演奏処理を行いました。しかしこれとて全展開データは充分P/ECEのメモリに収まる程度のサイズで、むしろ作業用メモリの方が大きいぐらいです。つまり、P/ECE上でZlibの出力ストリーミングが必要となるケースはなかった、と言えます。より大きな圧縮・展開データを扱う、PC上のプログラムではいくぶん事情も変わってくるのでしょうが、少なくともゲームプログラムにおいては全データをオンメモリに展開するケースが大部分なのではないかと思います。そんなわけで、どうやらZlibの出力ストリーミングは僕には必要ないようです。 Zlibの出力ストリーミングをとりやめて、作業用メモリの必要量を減らすことにしました。さっそくZlibのソース改造にとりかかったのですが・・・難解です(^^; Zlib展開の手順は、さほど複雑なものではありません。本家「The gzip home page(http://www.gzip.org/)」さんのサイトの、Zlib Home Site(http://www.gzip.org/zlib/)」 →「zlib Documentation(http://www.gzip.org/zlib/zlib_docs.html)」のページから、Zlibの仕様書が入手できます。ハフマン木作成のところが多少トリッキーですけれど、それ以外は解り易くてシンプルな仕様です。にも関わらずZlibのソースが難解なのは、移植性と高速化のため、プログラムが複雑化しているのが原因のようです。特にハフマン復号処理の高速化に関しては相当に力が入っているようで、ソース全体のかなりの部分を占めています。これらの複雑なルーチンに影響を与えないよう、出力ストリーミングだけを取りやめるのは、ちょっと危険な感じです。そこで今回は、Zlibのソースを改造するのではなく、自前で再実装してみることにしました。できあがったのがこちらです。 http://www.piece-me.org/archive/pzltest-20040313-piece.zip http://www.piece-me.org/archive/pzltest-20040313-win32.zip (ファイル内容は、README.TXTをご覧下さい。詳細は次回に。) ※2004/03/14追記: バグ修正および再調整しました。　この記事のいちばん最後に、更新版のURLがあります。 P/ECE用とWindows用のテストプログラムを用意してみました。いずれもZlib圧縮された画像ファイルを展開し、画面表示するテストプログラムです。テストプログラムはP/ECE用とWindows用で別々ですが、Zlib展開ルーチンのソースはほぼ共通となっています。出力ストリーミングを取りやめたので、スライド窓が不要となり、作業用メモリは8キロバイト程度に減りました。もっと減らしても大丈夫そうなのですが、それは今後の調整課題です。オリジナルのZlibと異なり、移植性・高速化に関する部分はバッサリです。移植性に関しては、僕は当面P/ECE、Windows、あとPC用のLinuxぐらいで動けば充分なので、ほとんど何も考えていません。 32ビット環境で、バイトオーダーもリトルエンディアンに決め打ちです。高速化も全く行っていませんが、P/ECEで扱う程度のデータサイズならば、あまり違いは感じられないはずです。大まかに言って、1秒当り10～15キロバイトぐらいの展開速度だと思います。徹底的に簡素化したので、プログラムサイズはヘッダとソース合わせて1000行程度に小さくなりました。オリジナルのZlibも、もともとはこれぐらい簡素だったと思うのです。長く使われていろいろな環境に移植され、また強力に高速化された結果、現在のように複雑な実装になったのでしょう。今回実装したZlibルーチンは、言わば先祖還りのようなものです。 P/ECEぐらいの規模の環境には、これぐらい簡素な実装で充分なのではないかなぁ、と思いました。・・・と、実装してみてからP/ECEカーネルソースの展開ルーチンを読み返すと、図らずも似た感じになってますね。考えることは同じですねぇ(^^; （続きます…） ---------------------------------------------------------------------------------------------------- 2004/03/14追記: ・バグ修正しました。　大きな圧縮データを展開すると、展開処理に失敗してしまっていたバグを修正しました。・作業用メモリサイズを調整しました。　昨日のバージョンでは、ハフマン木作成のために8キロバイトの作業用メモリを確保していました。　いくつかの圧縮データを試してみたところ、実際に使われているのはその1/6程度でした。　ちょっと余裕がありすぎるので、作業用メモリを半分の4キロバイトに減らしてみました。　まだ3倍程度の余裕がありますから、たぶん大丈夫だとは思いますが、ちょっと注意が必要です。　オリジナルのZlibでも、ハフマン木作成のための作業用メモリサイズは、実験で決めているようです。　作業用メモリの最大必要サイズは、理論で求められないみたいです。ダウンロードはこちら： http://www.piece-me.org/archive/pzltest-20040314-piece.zip http://www.piece-me.org/archive/pzltest-20040314-win32.zip ---------------------------------------------------------------------------------------------------- * Tue Dec 23 08:00:00 JST 2003 Naoyuki Sawa - ディレイド分岐命令の誤動作#4 （前回からの続き…）引き続き、ディレイド分岐命令の直前にメモリアクセス命令を置いた場合の、誤動作の有無を実験します。前々回は「jp.d %rb」、前回は「call.d %rb」「ret.d」について調べました。今回は、残りの「jp.d sign8」「jr.d sign8」「call.d sign8」について調べます。　　　　○ディレイド分岐命令　　　　 1. jp.d sign8 　　　　 2. jr.d sign8 　　　　 3. call.d sign8 　　　　○メモリアクセス命令　　　　 1. ld.b [%rb], %rs 　　　　 2. ld.ub [%rb], %rs 　　　　 3. ld.h [%rb], %rs 　　　　 4. ld.uh [%rb], %rs 　　　　 5. ld.w [%rb], %rs 　　　　 6. ld.b %rd, [%rb] 　　　　 7. ld.h %rd, [%rb] 　　　　 8. ld.w %rd, [%rb] 　　　　○分岐元・分岐先　　　　 1. 高速RAM 　　　　 2. SRAM 　　　　○メモリアクセス先　　　　 1. 高速RAM 　　　　 2. SRAM 前回までと異なり、分岐元と分岐先のメモリの種類が違うパターンについては実験していません。「jp.d sign8」「jr.d sign8」「call.d sign8」は前後256バイトまでの範囲にしか分岐できないため、高速RAM(0x0000～0x1fff)からSRAM(0x100000～0x13ffff)へ、あるいはSRAMから高速RAMへは、遠すぎて分岐できないからです。（「ext」命令と組み合わせれば前後256バイト以上の範囲に分岐できますが、メモリアクセス命令とディレイド分岐命令の間に「ext」命令が入ります。　ディレイド分岐命令の直前にメモリアクセス命令がある状況だけをテストしているので、「ext」命令を挟むケースは今回は除外することにしました。）検証用プログラムはこちら：　　　　「jp.d sign8」　　　 http://www.piece-me.org/archive/delyerr4-20031223.zip 　　　　「jr.d sign8」 http://www.piece-me.org/archive/delyerr5-20031223.zip 　　　　「call.d sign8」　　 http://www.piece-me.org/archive/delyerr6-20031223.zip 検証用プログラムの結果出力ファイル(生のCSV形式)はこちら：　　　　「jp.d sign8」　　　 http://www.piece-me.org/piece-lab/delyerr4-20031223-result.csv 　　　　「jr.d sign8」 http://www.piece-me.org/piece-lab/delyerr5-20031223-result.csv 　　　　「call.d sign8」　　 http://www.piece-me.org/piece-lab/delyerr6-20031223-result.csv 出力結果ファイルを読みやすいように加工してみたのがこちら：　　　　「jp.d sign8」　　　 http://www.piece-me.org/piece-lab/delyerr4-20031223-kekka.csv 　　　　「jr.d sign8」 http://www.piece-me.org/piece-lab/delyerr5-20031223-kekka.csv 　　　　「call.d sign8」　　 http://www.piece-me.org/piece-lab/delyerr6-20031223-kekka.csv 結果、　　　　-------------------------------- 　　　　全ての組み合わせで、誤動作無し！　　　　-------------------------------- 「jp.d sign8」「jr.d sign8」「call.d sign8」はいずれも非常に使用頻度の高いディレイド分岐命令で、これまでにも多用しています。これまでの使用において特に問題は発生していなかったので、誤動作条件が存在しないのも予想通りでした。 -------------------------------------------------------------------------------------------------- 以上、四回に渡って、ディレイド分岐命令の誤動作条件を調べてきました。まだ全てのメモリアクセス命令や全ての条件の組み合わせを試したわけではありませんが、とりあえずここで総括してみます。結局、マニュアルに記載されていない誤動作条件が存在するディレイド分岐命令は、「jp.d %rb」だけでした。ディレイド分岐命令を使ってプログラムを最適化する場合に、注意しなければいけないルールは次の通りです：　　　　『「jp.d %rb」命令の直前にメモリアクセス命令を置いてはいけない』とりあえずこのルールに従っておけば、誤動作することはないと思います。より詳しい誤動作条件については、前々回の研究記録『ディレイド分岐命令の誤動作#2』をご参照ください。このルール、S1C33209 CPUのマニュアルには載っていません。マニュアルの記載漏れか、あるいは想定外の誤動作なのか・・・いずれにせよ、危険度「大」です。 * Mon Dec 22 22:00:00 JST 2003 Naoyuki Sawa - ディレイド分岐命令の誤動作#3 （前回からの続き…）前回は、ディレイド分岐命令「jp.d %rb」の直前にメモリアクセス命令を置いた場合の、誤動作の有無を実験しました。その結果、いくつかの組み合わせで誤動作することがわかり、『「jp.d %rb」命令の直前にメモリアクセス命令を置いてはいけない』という結論が得られました。今回は、ディレイド分岐命令「call.d %rb」と「ret.d」について、同様に実験してみることにします。前回実験した「jp.d %rb」命令、実はディレイド分岐命令の中ではいちばん使用頻度が低いです。「jp %rb」を使う場面はテーブルジャンプ処理ぐらいしかなく、C言語ではswitch文に相当します。 switch文の実行性能がプログラム全体の性能に大きく影響するようなケースは、比較的少ないと思います。従って、「jp %rb」を「jp.d %rb」に置き換えてまで処理速度を稼ぐような場面も、あまりないと思うからです。「jp.d %rb」に較べて、「call.d %rb」と「ret.d」の使用頻度ははるかに高いです。「call.d %rb」は関数ポインタ呼び出しに限らず、頻繁に使う関数のアドレスをレジスタに保持するようなケースで頻出します。「ret.d」は・・・実は僕はあまり使っていないのですが、EPSON社純正ライブラリの除算ルーチンがこれを有効活用しています。以前の研究記録『実はディレイド命令』の回をご参照ください。というわけで、「call.d %rb」「ret.d」の直前にメモリアクセス命令を置いた場合の、誤動作の有無を実験してみました。　　　　○ディレイド分岐命令　　　　 1. call.d %rb 　　　　 2. ret.d 　　　　○メモリアクセス命令　　　　 1. ld.b [%rb], %rs 　　　　 2. ld.ub [%rb], %rs 　　　　 3. ld.h [%rb], %rs 　　　　 4. ld.uh [%rb], %rs 　　　　 5. ld.w [%rb], %rs 　　　　 6. ld.b %rd, [%rb] 　　　　 7. ld.h %rd, [%rb] 　　　　 8. ld.w %rd, [%rb] 　　　　○分岐元　　　　 1. 高速RAM 　　　　 2. SRAM 　　　　○分岐先　　　　 1. 高速RAM 　　　　 2. SRAM 　　　　○メモリアクセス先　　　　 1. 高速RAM 　　　　 2. SRAM 検証用プログラムはこちら：　　　　「call.d %rb」 http://www.piece-me.org/archive/delyerr2-20031222.zip 　　　　「ret.d」　　　http://www.piece-me.org/archive/delyerr3-20031222.zip 検証用プログラムの結果出力ファイル(生のCSV形式)はこちら：　　　　「call.d %rb」 http://www.piece-me.org/piece-lab/delyerr2-20031222-result.csv 　　　　「ret.d」　　　http://www.piece-me.org/piece-lab/delyerr3-20031222-result.csv 出力結果ファイルを読みやすいように加工してみたのがこちら：　　　　「call.d %rb」 http://www.piece-me.org/piece-lab/delyerr2-20031222-kekka.csv 　　　　「ret.d」　　　http://www.piece-me.org/piece-lab/delyerr3-20031222-kekka.csv 結果、　　　　-------------------------------- 　　　　全ての組み合わせで、誤動作無し！　　　　-------------------------------- （まだメモリアクセス命令「pushn %rs」「popn %rd」との組み合わせを試していませが、多分大丈夫じゃないかな？と思います。）これは助かりました！前述の通り、手作業で最適化を行う場合に「call.d %rb」「ret.d」を使うケースは、「jp.d %rb」よりもずっと多いです。「call.d %rb」と「ret.d」に誤動作条件があったら、かなりヤバイことになっているところでした。　　　　『「call.d %rb」「ret.d」の使用においては、仕様外の誤動作を心配する必要はありません』さて、残るディレイド分岐命令は「jp.d sign8」「jr.d sign8」「call.d sign8」です。これらの命令も非常に使用頻度が高いですが、これまでにさんざん使って特に問題が出ていないので、多分大丈夫だと思います。次回、実験予定です。 (続きます…) * Sat Dec 20 12:00:00 JST 2003 Naoyuki Sawa - ディレイド分岐命令の誤動作#2 （前回からの続き…）何通りかのパターンで検証を行ってみたところ、ディレイド分岐命令が誤動作する条件がおぼろげに見えてきました。その条件とは、おおよそ次のようなものです。　　　　『ディレイド分岐命令の直前にメモリアクセス命令があると、ディレイド命令が実行されないことがある』前回はインターロック条件について詳しく触れましたが、どうやらインターロックの有無は関係ない感じです。例えば、次のようなコードを高速RAMに置いて実行した場合にも誤動作となり、ディレイド命令が実行されません。　　　　; あらかじめ%r10に分岐先アドレスが入っているものとします。　　　　xld.w %r4, 0x100000 　　　　xld.w %r5, [%r4+100]　; 直前にメモリアクセス命令があると… 　　　　jp.d %r10　　　　　　 ; インターロックしていなくても… 　　　　add %r6, 1　　　　　　; ★実行されない!!★ 予想以上に、誤動作の影響を受ける範囲が広いような気がしてきました。これは詳細に検証してみる必要がありそうです。それでは、どれぐらいのパターンを検証する必要があるのでしょうか？少なく見積もっても、次に挙げるぐらいの検証は必要そうです。　　　　○ディレイド分岐命令　　　　 1. jp.d %rb 　　　　 2. call.d %rb 　　　　 3. ret.d 　　　　 4. jp.d sign8 　　　　 5. jr.d sign8 　　　　 6. call.d sign8 　　　　○メモリアクセス命令　　　　 1. ld.b [%rb], %rs 　　　　 2. ld.ub [%rb], %rs 　　　　 3. ld.h [%rb], %rs 　　　　 4. ld.uh [%rb], %rs 　　　　 5. ld.w [%rb], %rs 　　　　 6. ld.b %rd, [%rb] 　　　　 7. ld.h %rd, [%rb] 　　　　 8. ld.w %rd, [%rb] 　　　　 9. pushn %rs 　　　　10. popn %rd 　　　　○分岐元　　　　 1. 高速RAM 　　　　 2. SRAM 　　　　○分岐先　　　　 1. 高速RAM 　　　　 2. SRAM 　　　　○メモリアクセス先　　　　 1. 高速RAM 　　　　 2. SRAM 6×10×2×2×2＝480通り…ちょっと気が遠くなってきました(^^; さらに欲を言えば、　　　　・各命令がext命令を伴っているか否か　　　　・分岐先の最初にある命令の種類によって違いはあるか等の条件も変えて試してみたいところです。でも、いきなり全部は無理そうなので、とりあえず今回は次の組み合わせだけ検証してみることにしました。　　　　○ディレイド分岐命令　　　　 1. jp.d %rb 　　　　○メモリアクセス命令　　　　 1. ld.b [%rb], %rs 　　　　 2. ld.ub [%rb], %rs 　　　　 3. ld.h [%rb], %rs 　　　　 4. ld.uh [%rb], %rs 　　　　 5. ld.w [%rb], %rs 　　　　 6. ld.b %rd, [%rb] 　　　　 7. ld.h %rd, [%rb] 　　　　 8. ld.w %rd, [%rb] 　　　　○分岐元　　　　 1. 高速RAM 　　　　 2. SRAM 　　　　○分岐先　　　　 1. 高速RAM 　　　　 2. SRAM 　　　　○メモリアクセス先　　　　 1. 高速RAM 　　　　 2. SRAM 1×8×2×2×2＝64通り。これだけでも、ある程度の傾向はつかめるのではないかと思います。検証用プログラムはこちら：　　　　http://www.piece-me.org/archive/delyerr1-20031220.zip 検証用プログラムの結果出力ファイル(生のCSV形式)はこちら：　　　　http://www.piece-me.org/piece-lab/delyerr1-20031220-result.csv 出力結果ファイルを読みやすいように加工してみたのがこちら：　　　　http://www.piece-me.org/piece-lab/delyerr1-20031220-kekka.csv Microsoft Excel等のスプレッドシートソフトで読んでください。出力結果から、いくつかのルールが見て取れます。 ---------------------------- 分岐先メモリの種類は関係ない ---------------------------- 分岐先メモリの種類(高速RAM/SRAM)だけが異なり、他の条件が全て同じケースでは、必ず同じ結果となっています。分岐先メモリが高速RAMの場合に正常動作なら、分岐先メモリをSRAMに変えてみても正常動作。分岐先メモリが高速RAMの場合に誤動作なら、分岐先メモリをSRAMに変えてみても誤動作。このルールから推測すると、たぶん分岐先の最初にある命令の種類も関係ないんじゃないかな？と思います。 -------------------------------- メモリアクセスのサイズは関係ない -------------------------------- メモリアクセスのサイズ(BYTE/UNSIGNED BYTE/HALF/UNSIGNED HALF/WORD)だけが異なり、他の条件が全て同じケースでは、必ず同じ結果となっています。 SRAMへのメモリアクセスの場合、メモリアクセスのサイズによってタイミングが異なるのですが、それは誤動作の条件には関係ないようです。 ----------------------------------------- 分岐元メモリが高速RAMなら、必ず誤動作する ----------------------------------------- 今回の最初に提示した、誤動作するコードの条件がこれに相当します。高速RAMに転送して使うプログラムを最適化する場合は、ディレイド分岐命令の直前にメモリアクセス命令を置かないよう、注意しなければいけません。 ---------------------------------------------------------------- 書き込みアクセス先メモリと分岐元メモリが共にSRAMなら、誤動作する ---------------------------------------------------------------- 今回の検証で新たに見つけた誤動作条件です。例えば、次のようなコードをSRAM上で実行すると誤動作し、ディレイド命令が実行されません。　　　　; あらかじめ%r10に分岐先アドレスが入っているものとします。　　　　xld.w %r4, 0x130000　 ; アクセス先メモリ＝SRAM 　　　　xld.w [%r4], %r5　　　; メモリアクセス＝書き込み　　　　jp.d %r10 　　　　add %r6, 1　　　　　　; ★実行されない!!★ なお、このコードを高速RAM上で実行した場合は前出の条件に一致し、やはり誤動作します。つまり、SRAMへの書き込みの直後にディレイド分岐命令を置いた場合は、高速RAMに転送して実行するプログラムでなくても誤動作する、ということです。今回の検証のまとめです。出力結果を見ると、ディレイド分岐命令の直前にメモリアクセス命令を置いても誤動作しないケースはいくつか存在します。例えば、分岐元プログラムがSRAM上にあり、かつ、直前のメモリアクセスが読み込みならば、誤動作しません。しかしながら、最後に挙げたような特殊条件下で誤動作するケースがあるため、安全のためには次に示す単純なルールに従っておくのが良さそうです。　　　　『ディレイド分岐命令の直前にはメモリアクセス命令を置かない』さて、今回はディレイド分岐命令「jp.d %d」についてだけ実験しましたが、他のディレイド分岐命令「call.d %rb」や「jr.d sign8」等ではどうでしょうか？これまでの経験から推測すると、「jr.d sign8」は直前にメモリアクセス命令があっても大丈夫そうな気がするのですが・・・次回は、ディレイド分岐命令の種類を変えて試してみようと思います。 (続きます…) * Wed Dec 17 12:55:00 JST 2003 Naoyuki Sawa - ディレイド分岐命令の誤動作#1 「タンクバタリアン/EMU」にて、6502エミュレーション高速化のために手作業でアセンブラプログラムの最適化を行ったのですが、実はかなりハマリました。問題の個所は比較的小さなサブルーチンで、何度見直しても間違っていないはずなのに、どうやっても期待通りの動作をしないのです。使用頻度の高いサブルーチンだったので高速RAMに転送して実行していたところを、試しにSRAMに戻してみるとなぜか問題なく実行できてしまう・・・何故？散々悩んだ末に、どうやら原因らしきものが掴めました。S1C33209 CPUコアの★誤動作★、さもなくばCPUマニュアルの★記載漏れ★っぽいです。今回は、この件について記録しておこうと思います。 P/ECEのCPU S1C33209は、多くの一般的なRISCプロセッサと同じく、「ディレイド分岐機能」を備えています。ディレイド分岐機能については、以前の研究記録『実はディレイド命令』でも触れましたので、そちらも併せてご参照ください。今回問題となった個所は、次のような処理を行う部分でした。(※かなり簡略化しています) 　　　　『6502機械語命令を1バイト読み込み、その内容によって分岐する』 C言語で書くと、こんな感じの処理です。 -------------------------------------------------------------------------------------------------- 　　　　unsigned char* pc = ...; 　　　　switch(*pc++) { 　　　　case 0: ...; break; 　　　　case 1: ...; break; 　　　　　　　　... 　　　　case 9: ...; break; 　　　　} -------------------------------------------------------------------------------------------------- これをアセンブラで書くと、次のようになります。 -------------------------------------------------------------------------------------------------- 1|　　　　　; 2|　　　　　; %r0レジスタに変数pcが割り当てられているものとします。 3|　　　　　; 4|　　　　　ld.ub %r1, [%r0]　　　　; code = *pc 5|　　　　　xld.w %r2, TABLE　　　　; addr = TABLE[code] 6|　　　　　sll %r1, 2 7|　　　　　add %r1, %r2 8|　　　　　ld.w %r3, [%r1] 9|　　　　　jp.d %r3　　　　　　　　; goto addr 10|　　　　　add %r0, 1　　　　　　　; pc++ 11|　　　　　 12|　TABLE:　　　　　　　　　　　　　; switch用ジャンプテーブル 13|　　　　　.word CASE0 14|　　　　　.word CASE1 15|　　　　　... 16|　　　　　.word CASE9 17|　　　　 18|　CASE0: 19|　　　　　...　　　　　　　　　　 ; code=0の場合の処理 20|　CASE1: 21|　　　　　...　　　　　　　　　　 ; code=1の場合の処理 22|　　　　　... 23|　CASE9: 24|　　　　　...　　　　　　　　　　 ; code=9の場合の処理 -------------------------------------------------------------------------------------------------- ※これ以降の説明で個々の命令について実行サイクル数を調べて行きますが、とりあえずメモリアクセス時のウェイトサイクルは除外して考えます。 9～10行目にご注目ください。ディレイド分岐機能を使って、ジャンプ命令を1サイクル高速化しています。　　　　jp.d %r3　　　　; 1サイクル　　　　add %r0, 1　　　; 1サイクルもしディレイド分岐機能を使わずに普通に書けば、次のようになります。　　　　add %r0, 1　　　; 1サイクル　　　　jp %r3　　　　　; 2サイクル従って、ディレイド分岐機能を使った方が1サイクル速くなります。・・・と言いたいところですが、実はこの場合に限って言えば、ディレイド分岐機能を使った場合と使わない場合のサイクル数は変わらないのです。 8～9行目にご注目ください。　　　　08|　　　　ld.w %r3, [%r1] 　　　　09|　　　　jp.d %r3 8行目でメモリから読み込んだ%r3の値を、直後に9行目のジャンプ命令で飛び先アドレスとして参照しています。 S1C33209 CPUではこのような処理を行った場合に「インターロック」と呼ばれる遅延が発生し、命令の実行時間が1サイクル長くなるのです。詳しくは「S1C33000コアCPUマニュアル(33000Core-J.pdf)」34ページ『3.2 プログラム実行状態 (7) インターロックによる遅延』をご参照ください。結局、9～10行目の本当の実行サイクル数は次のようになります。　　　　jp.d %r3　　　　; 1サイクル＋1サイクル(インターロック) 　　　　add %r0, 1　　　; 1サイクルディレイド分岐命令を使わない場合は、ジャンプ命令の実行時間が1サイクル長い代わりにインターロックは発生せず、ディレイド分岐命令を使った場合は、ジャンプ命令の実行時間が1サイクル短い代わりにインターロックが発生します。従ってこの場合に限って言えば、どちらの方法を使っても全体のサイクル数は3サイクルとなり、実行速度は同じです。ではなぜディレイド分岐命令を使う方のプログラムを採用したかと言うと、次のような判断によります。ディレイド分岐命令を使わない方の合計実行サイクル数は、必ず3サイクルとなります。例外はありません。それに対し、ディレイド分岐命令を使った場合の合計実行サイクル数は、非常に幸運な場合に2サイクルとなる可能性があります。どんな幸運かと言いますと、8～9行目の間に割り込みが発生した場合です。 8行目の命令実行直後にタイマやサウンド等の割り込みが発生すると、8行目と9行目の間で割り込み処理を行うことになります。すると、8行目でメモリから読み込んだ%r3の値を、「直後に」9行目で参照するわけではなくなります。従って9行目でインターロックは発生せず、9行目と10行目の合計実行サイクル数は2サイクルとなります。・・・とは言えこんな幸運は滅多にあるわけでなし、全体の速度から見れば 0.00...01% 程度の違いでしかないでしょう。どちらの方法を使うかは全く“気分の問題”であり、重要なのは、どちらの方法でも正しく動く、ということです。 ■■■■■■■■■■　ここまでは問題ありません。仕様通りの動作です。問題はここから　■■■■■■■■■■ ところが実は、ある条件が重なった場合に、ディレイド分岐命令を使う方のプログラムは正しく動かなくなります。ある条件とは、　　　　このサブルーチンを高速RAM上で実行した場合です。わざわざ手作業で最適化するからには高速性が必要なサブルーチンであり、もちろん高速RAMに転送して実行するでしょう。今回が正にこのケースに相当しました。ディレイド分岐命令を使う方のプログラムを高速RAMに置いて実行すると、次のような振る舞いとなります。(※サイクル数は推測です) 　　　　 8|　　　　ld.w %r3, [%r1]　　　; 1サイクル　　　　 9|　　　　jp.d %r3　　　　　　 ; 1サイクル＋1サイクル(インターロック) 　　　　　|　　　　　　　　　　　　　　 ; ★ここでジャンプしてしまう!!★ 　　　　10|　　　　add %r0, 1　　　　　 ; ★実行されません!!★ すなわち、ディレイド命令であるはずの10行目「add %r0, 1」が実行されないのです。 C言語に例えると、　　　　switch(*pc++) { 　　　　　　　　... 　　　　} と書いたつもりが実際の動作は　　　　switch(*pc) { 　　　　　　　　... 　　　　} になってしまう、という事態。正しい結果が得られるはずもありません。これは危険です!! もう少し詳しく、症状が発現する条件を調べておく必要がありそうです。 (続きます…) * Mon May 5 05:30:00 JST 2003 Naoyuki Sawa - 警告の範囲が違う昨日書いた「距離を求める（誤差±約１％・30ビット版）」のアセンブラプログラム、実はかなりハマリました。どうやっても結果が合わず、さんざん悩んだ末に見つけた原因は次のようなものでした。正しくは　　　　xld.w %r13, 55 と書くべきところを　　　　ld.w %r13, 55 と書いてしまっていたのです。 P/ECEのCPU S1C33の命令セットは、たいていの場合、即値に6ビットまでの数値しか指定できません。それ以上のビット数の即値を使いたい場合は、ext命令を使って桁を拡張する必要があります。上の例に挙げた「ld」命令の場合、即値には符号付き6ビットまでしか指定できません。符号付き6ビットで表現できる数値は-32～31ですので、　　　　・　　　　・　　　　・　　　　ld.w %r13, 34 　　　　　; 間違い！　　　　ld.w %r13, 33 　　　　　; 間違い！　　　　ld.w %r13, 32 　　　　　; 間違い！　　　　ld.w %r13, 31 　　　　　; 正しい　　　　ld.w %r13, 30 　　　　　; 正しい　　　　ld.w %r13, 29 　　　　　; 正しい　　　　・　　　　・　　　　・　　　　ld.w %r13, 1　　　　　　; 正しい　　　　ld.w %r13, 0　　　　　　; 正しい　　　　ld.w %r13, -1 　　　　　; 正しい　　　　・　　　　・　　　　・　　　　ld.w %r13, -30　　　　　; 正しい　　　　ld.w %r13, -31　　　　　; 正しい　　　　ld.w %r13, -32　　　　　; 正しい　　　　ld.w %r13, -33　　　　　; 間違い！　　　　ld.w %r13, -34　　　　　; 間違い！　　　　ld.w %r13, -35　　　　　; 間違い！　　　　・　　　　・　　　　・となります。また別の例として、「add」命令などは即値に符号なし6ビットまでの数値しか指定できません。符号なし6ビットで表現できる数値は0～63ですので、　　　　・　　　　・　　　　・　　　　add %r13, 66　　　　　　; 間違い！　　　　add %r13, 65　　　　　　; 間違い！　　　　add %r13, 64　　　　　　; 間違い！　　　　add %r13, 63　　　　　　; 正しい　　　　add %r13, 62　　　　　　; 正しい　　　　add %r13, 61　　　　　　; 正しい　　　　・　　　　・　　　　・　　　　add %r13, 1 　　　　　　; 正しい　　　　add %r13, 0 　　　　　　; 正しい　　　　add %r13, -1　　　　　　; 間違い！　　　　add %r13, -2　　　　　　; 間違い！　　　　add %r13, -3　　　　　　; 間違い！　　　　・　　　　・　　　　・となります。さて、今回のミス　　　　ld.w %r13, 55 は、「ld」命令が扱える符号付き6ビットの範囲（-32～31）を外れた即値（55）を指定してしまったことです。確かに当方のミスなのですが、本来、こういうミスに対してはアセンブラが警告を発することになっています。　　　　「Warning: Numeric range.：インストラクションオペランドの数値が不正です。」　　　　S1C33 Family Cコンパイラパッケージマニュアル Ver.4 (S5U1C33000C_J.pdf) 179ページよりところが、アセンブラは上のコードに対して警告を発しませんでした。そして、55を無理やり符号付き6ビットと解釈した値で、命令コードを生成してしまっていたのです。　　　　ld.w %r13, -9 　　　　　; -9 … 55を無理やり符号付き6ビットと解釈した値なぜ警告が発せられなかったのでしょうか？いくつか試してみたところ、S1C33 CPUのアセンブラas33.exeは、警告とする数値の範囲を間違えているようです。「ld」命令といろいろな数値を組み合わせて、警告が発せられるかどうかを試してみました。　　　　・　　　　・　　　　・　　　　ld.w %r13, 66 　　　　　; 間違い！　　　; 警告あり　　　　ld.w %r13, 65 　　　　　; 間違い！　　　; 警告あり　　　　ld.w %r13, 64 　　　　　; 間違い！　　　; 警告あり　　　　ld.w %r13, 63 　　　　　; 間違い！　　　; 警告なし！危険！　　　　ld.w %r13, 62 　　　　　; 間違い！　　　; 警告なし！危険！　　　　ld.w %r13, 61 　　　　　; 間違い！　　　; 警告なし！危険！　　　　・　　　　・　　　　・　　　　ld.w %r13, 34 　　　　　; 間違い！　　　; 警告なし！危険！　　　　ld.w %r13, 33 　　　　　; 間違い！　　　; 警告なし！危険！　　　　ld.w %r13, 32 　　　　　; 間違い！　　　; 警告なし！危険！　　　　ld.w %r13, 31 　　　　　; 正しい　　　　; 警告なし　　　　ld.w %r13, 30 　　　　　; 正しい　　　　; 警告なし　　　　ld.w %r13, 29 　　　　　; 正しい　　　　; 警告なし　　　　・　　　　・　　　　・　　　　ld.w %r13, 1　　　　　　; 正しい　　　　; 警告なし　　　　ld.w %r13, 0　　　　　　; 正しい　　　　; 警告なし　　　　ld.w %r13, -1 　　　　　; 正しい　　　　; 警告なし　　　　・　　　　・　　　　・　　　　ld.w %r13, -30　　　　　; 正しい　　　　; 警告なし　　　　ld.w %r13, -31　　　　　; 正しい　　　　; 警告なし　　　　ld.w %r13, -32　　　　　; 正しい　　　　; 警告なし　　　　ld.w %r13, -33　　　　　; 間違い！　　　; 警告なし　　　　ld.w %r13, -34　　　　　; 間違い！　　　; 警告なし　　　　ld.w %r13, -35　　　　　; 間違い！　　　; 警告なし　　　　・　　　　・　　　　・ 32～63までの数値が、正しい命令コードが生成されないにも関わらず無警告となっています。「add」命令についても同様に試してみます。　　　　・　　　　・　　　　・　　　　add %r13, 66　　　　　　; 間違い！　　　; 警告あり　　　　add %r13, 65　　　　　　; 間違い！　　　; 警告あり　　　　add %r13, 64　　　　　　; 間違い！　　　; 警告あり　　　　add %r13, 63　　　　　　; 正しい　　　　; 警告なし　　　　add %r13, 62　　　　　　; 正しい　　　　; 警告なし　　　　add %r13, 61　　　　　　; 正しい　　　　; 警告なし　　　　・　　　　・　　　　・　　　　add %r13, 1 　　　　　　; 正しい　　　　; 警告なし　　　　add %r13, 0 　　　　　　; 正しい　　　　; 警告なし　　　　add %r13, -1　　　　　　; 間違い！　　　; 警告なし！危険！　　　　add %r13, -2　　　　　　; 間違い！　　　; 警告なし！危険！　　　　add %r13, -3　　　　　　; 間違い！　　　; 警告なし！危険！　　　　・　　　　・　　　　・　　　　add %r13, -30 　　　　　; 間違い！　　　; 警告なし！危険！　　　　add %r13, -31 　　　　　; 間違い！　　　; 警告なし！危険！　　　　add %r13, -32 　　　　　; 間違い！　　　; 警告なし！危険！　　　　add %r13, -33 　　　　　; 間違い！　　　; 警告あり　　　　add %r13, -34 　　　　　; 間違い！　　　; 警告あり　　　　add %r13, -35 　　　　　; 間違い！　　　; 警告あり　　　　・　　　　・　　　　・ -32～-1までの数値が、正しい命令コードが生成されないにも関わらず無警告となっています。どうやらas33.exeは、命令によって有効な数値の範囲が違うことを忘れ、常に-32～63が正しい数値の範囲だと思ってしまっているようです。今回は小さなプログラムだったので間違いに気付いたものの、大きなプログラムで間違ったコードが無警告で通ってしまっていたら･･･この危険を回避するには、「ld」や「add」等の命令で即値を使う場合は、たとえ小さな値でも常に「xld」「xand」等と表記しましょう。各命令の有効な数値範囲を超えると、コンパイラが自動的に「ext」命令を付加して、誤った命令コードの生成を防いでくれます。 * Sun May 4 15:00:00 JST 2003 Naoyuki Sawa - 距離を求める（誤差±約１％・30ビット版） P/wareさん（http://www.aw.wakwak.com/~hitode/piece/）のページの、距離を求める（http://www.aw.wakwak.com/~hitode/piece/index.html#dist2）高速な方法が更新されています。まず、前回と同じ誤差±約４％の方法で、より精度の高い係数が公開されました。前回のプログラムを、新しい係数で作り直したものがこちら。　　　　http://www.piece-me.org/archive/hypot2a-20030504.zip さらに、「誤差約１％」と「誤差約０．２％」の計算方法が追加されています。誤差約１％の方法が、速度と精度のバランスが取れていて、良さそうです。そこで今回は、誤差約１％の計算方法の30ビット版を作ってみました。　　　　/* 原点と点 (x, y) の距離を求めます。　　　　 * [in] 　　　　 *　　　x, y　　　　　　距離を求める座標　　　　 * [out] 　　　　 *　　　戻り値　　　　　原点と点 (x, y) の距離　　　　 * [note] 　　　　 *　　　* 距離の近似をもとめる計算式：　　　　 *　　　　　　　|x|>|y|のとき、|x|+((|y|*|y|/|x|*55)>>7) 　　　　 *　　　　　　　（誤差は±約１％）　　　　 */ 　　　　int hypot4(int x, int y); 　　　　　　　�