+===========+ |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); 　　　　　　　　asm(" 　　　　　　　　.code 　　　　　　　　.align 1 　　　　　　　　.global hypot4 　　　　hypot4: 　　　　　　　　ld.w %r10, %r12　　　　　; if(x == 0 && y == 0) return 0 　　　　　　　　or %r10, %r13 　　　　　　　　jreq hypot4_exit 　　　　　　　　; 　　　　　　　　cmp %r12, 0　　　　　　　; %r12 = |x| 　　　　　　　　jrge 3 　　　　　　　　 not %r12, %r12 　　　　　　　　 add %r12, 1 　　　　　　　　cmp %r13, 0　　　　　　　; %r13 = |y| 　　　　　　　　jrge 3 　　　　　　　　 not %r13, %r13 　　　　　　　　 add %r13, 1 　　　　　　　　cmp %r12, %r13 　　　　　; if(|x| < |y|) %r12 exch %r13 　　　　　　　　jrge 4 　　　　　　　　 xor %r13, %r12 　　　　　　　　 xor %r12, %r13 　　　　　　　　 xor %r13, %r12 　　　　　　　　; 　　　　　　　　mltu.w %r13, %r13　　　　; %r5:%r4 = |y|^2 　　　　　　　　ld.w %r4, %alr 　　　　　　　　ld.w %r5, %ahr 　　　　　　　　; 　　　　　　　　xld.w %r13, 55 　　　　　; %r6:%r5:%r4 = |y|^2 * 55 　　　　　　　　mltu.w %r4, %r13 　　　　　　　　ld.w %r4, %alr 　　　　　　　　ld.w %r6, %ahr 　　　　　　　　mltu.w %r5, %r13 　　　　　　　　ld.w %r5, %alr 　　　　　　　　add %r5, %r6 　　　　　　　　;{{ 　　　　　　　　jruge.d 3　　　　　　　　; (!C) 　　　　　　　　 ld.w %r6, %ahr 　　　　; (undoc'd delay) 　　　　　　　　 add %r6, 1 　　　　　　　　;}}または{{ 　　　　　　　　;ld.w %r6, %ahr 　　　　　　　　;adc %r6, %r8　　　　　　; -gp=0x0 を想定　　　　　　　　;}} 　　　　　　　　; 　　　　　　　　ld.w %r13, %r5 　　　　　; %r5:%r4 = (|y|^2 * 55) >> 7 　　　　　　　　xsll %r13, 25 　　　　　　　　xsrl %r4, 7 　　　　　　　　or %r4, %r13 　　　　　　　　xsll %r6, 25 　　　　　　　　xsrl %r5, 7 　　　　　　　　or %r5, %r6 　　　　　　　　; 　　　　　　　　ld.w %alr, %r4 　　　　　; %alr = ((|y|^2 * 55) >> 7) / |x| 　　　　　　　　div0u %r12 　　　　　　　　ld.w %ahr, %r5 　　　　　　　　div1 %r12　　　　　　　　; 1 　　　　　　　　div1 %r12　　　　　　　　; 2 　　　　　　　　div1 %r12　　　　　　　　; 3 　　　　　　　　div1 %r12　　　　　　　　; 4 　　　　　　　　div1 %r12　　　　　　　　; 5 　　　　　　　　div1 %r12　　　　　　　　; 6 　　　　　　　　div1 %r12　　　　　　　　; 7 　　　　　　　　div1 %r12　　　　　　　　; 8 　　　　　　　　div1 %r12　　　　　　　　; 9 　　　　　　　　div1 %r12　　　　　　　　; 10 　　　　　　　　div1 %r12　　　　　　　　; 11 　　　　　　　　div1 %r12　　　　　　　　; 12 　　　　　　　　div1 %r12　　　　　　　　; 13 　　　　　　　　div1 %r12　　　　　　　　; 14 　　　　　　　　div1 %r12　　　　　　　　; 15 　　　　　　　　div1 %r12　　　　　　　　; 16 　　　　　　　　div1 %r12　　　　　　　　; 17 　　　　　　　　div1 %r12　　　　　　　　; 18 　　　　　　　　div1 %r12　　　　　　　　; 19 　　　　　　　　div1 %r12　　　　　　　　; 20 　　　　　　　　div1 %r12　　　　　　　　; 21 　　　　　　　　div1 %r12　　　　　　　　; 22 　　　　　　　　div1 %r12　　　　　　　　; 23 　　　　　　　　div1 %r12　　　　　　　　; 24 　　　　　　　　div1 %r12　　　　　　　　; 25 　　　　　　　　div1 %r12　　　　　　　　; 26 　　　　　　　　div1 %r12　　　　　　　　; 27 　　　　　　　　div1 %r12　　　　　　　　; 28 　　　　　　　　div1 %r12　　　　　　　　; 29 　　　　　　　　div1 %r12　　　　　　　　; 30 　　　　　　　　div1 %r12　　　　　　　　; 31 　　　　　　　　div1 %r12　　　　　　　　; 32 　　　　　　　　; 　　　　　　　　ld.w %r10, %alr　　　　　; %r10 = ((|y|^2 * 55) >> 7) / |x| + |x| 　　　　　　　　add %r10, %r12 　　　　hypot4_exit: 　　　　　　　　ret 　　　　　　　　"); オリジナルの計算式は　　　　|x|+((|y|*|y|/|x|*55)>>7) なのですが、|y|*|y| と |x| の値が近いときに誤差が大きくなり、例えば (-13, 8) で約７％の誤差が発生してしまいます。そこで、ちょっと計算式をアレンジして、　　　　|x|+((|y|*|y|*55>>7)/|x|) としてみました。この関数を含む、動作検証用プログラムはこちら。　　　　http://www.piece-me.org/archive/hypot4-20030504.zip 前回と同じく、ランダムな座標 (x, y) と原点 (0, 0) 間の距離を求め、本当の値との誤差を表示します。 10万回程度繰り返してみたところ、ほとんど±１％以内に収まり、最悪でも１．５％を超えることはありませんでした。前回の４％・30ビット版は、一回あたり約30サイクル前後で完了していました。今回の１％・30ビット版は、一回あたり約90サイクル前後かかってしまいます。（いずれもソースコード上での合計値で、実測値ではありません。メモリウェイト等も考慮していません。）しかしながら、三倍程度の遅さで四倍の精度が得られるのなら、１％版の方を使おうかな？と思いました。 * Sat May 3 08:50:00 JST 2003 Naoyuki Sawa - 距離を求める（30ビット版） P/wareさん（http://www.aw.wakwak.com/~hitode/piece/）のページで、距離を求める（http://www.aw.wakwak.com/~hitode/piece/index.html#dist）高速な方法が説明されています。特に、誤差４％の近似式を使った方法 hypot2() が参考になります。僕はこれまでマトモに平方根を計算してました・・・これからはこの方法を使わせて頂きます。先のページにも説明されている通り、hypot2() は (x, y) が 16ビットまでの数値でないと正しく動きません。固定小数点数などを使っていると、16ビット以上の座標値や距離が必要になってくることも結構あります。そこで、誤差を増やさずに、30ビットまでの (x, y) に対応した版を作ってみました。なぜ30ビットまでなのか（31ビットや32ビットの座標値には対応できないのか）というと、 31ビット以上の座標値では結果の距離そのものが32ビット符号付き整数をオーバーフローしてしまうからです。　　　　/* 原点と点 (x, y) の距離を求めます。　　　　 * [in] 　　　　 *　　x, y　　　　　　距離を求める座標　　　　 * [out] 　　　　 *　　戻り値　　　　　原点と点 (x, y) の距離　　　　 * [note] 　　　　 *　　* 距離の近似をもとめる計算式：　　　　 *　　　|x|>|y|のとき、|x|*0.9604+|y|*0.3978 　　　　 *　　　（誤差は±約４％）　　　　 */ 　　　　int hypot2(int x, int y); 　　　　　　　　asm(" 　　　　　　　　.align 1 　　　　　　　　.global hypot2 　　　　hypot2: 　　　　　　　　cmp %r12, 0 　　　　　　　; %r12 = |x| 　　　　　　　　jrge 3 　　　　　　　　 not %r12, %r12 　　　　　　　　 add %r12, 1 　　　　　　　　cmp %r13, 0 　　　　　　　; %r13 = |y| 　　　　　　　　jrge 3 　　　　　　　　 not %r13, %r13 　　　　　　　　 add %r13, 1 　　　　　　　　cmp %r12, %r13　　　　　　; if(|x| < |y|) %r12 exch %r13 　　　　　　　　jrge 4 　　　　　　　　 xor %r13, %r12 　　　　　　　　 xor %r12, %r13 　　　　　　　　 xor %r13, %r12 　　　　　　　　xld.w %r4, 0xf5dcc63f 　　; %r10 = |x| * (0.9604 << 32) 　　　　　　　　mltu.w %r12, %r4 　　　　　　　　ld.w %r10, %ahr 　　　　　　　　xld.w %r4, 0x65d63886 　　; %r10 += |y| * (0.3978 << 32) 　　　　　　　　mltu.w %r13, %r4 　　　　　　　　ld.w %r4, %ahr 　　　　　　　　add %r10, %r4 　　　　　　　　ret 　　　　　　　　"); 使い方はオリジナルの hypot2() と同じです。この関数を含む、動作検証用プログラムはこちら。　　　　http://www.piece-me.org/archive/hypot-20030503.zip ランダムな座標 (x, y) と原点 (0, 0) 間の距離を求め、本当の値との誤差を表示します。 10000回程度繰り返してみたところ、確かに誤差が±４％を超えることはありませんでした。余談ながら、インラインアセンブラ asm("～") を関数定義の外側で使っている点にご注目ください。 Cコンパイラが暗黙に生成するコードの心配をしなくていいので、僕は最近この方法を好んで使ってます。（単独のアセンブラソースに分けるのが面倒なので・・・(^^;） * Fri Apr 12 20:30:00 JST 2003 Naoyuki Sawa - 実はディレイド命令 P/ECEのCPU S1C33209は、RISC CPUの特徴のひとつ、「ディレイド分岐機能」を持っています。ディレイド分岐機能とは、分岐命令の実行より先に分岐命令の直後の命令を実行し、実行効率を稼ぐ機能です。ディレイド分岐機能を使う分岐命令を、「ディレイド分岐命令」と呼びます。また、ディレイド分岐命令の直後に置かれる命令を、「ディレイド命令」と呼びます。ほとんどの分岐命令は、ディレイド分岐命令として利用可能です。しかし、ディレイド命令として利用可能な命令はある程度限られています。単純なレジスタ間ロード命令や加減算・論理演算命令は、だいたいディレイド命令として利用可能なのですが、直感に反してディレイド不可な命令もいくつかあるので注意が必要です。例えば、符号拡張・ゼロ拡張を伴うレジスタ間ロード命令がディレイド不可というのは、ちょっと戸惑います。　　　　ld.b %rd, %rs 　　　　×ディレイド不可　　　　ld.ub %rd, %rs　　　　×ディレイド不可　　　　ld.h %rd, %rs 　　　　×ディレイド不可　　　　ld.uh %rd, %rs　　　　×ディレイド不可　　　　ld.w %rd, %rs 　　　　○ディレイド可能その他に、汎用レジスタと特殊レジスタ間のロード命令もディレイド不可となっています。　　　　ld.w %rd, %ss 　　　　×ディレイド不可　　　　ld.w %sd, %rs 　　　　×ディレイド不可汎用レジスタと特殊レジスタ間のロード命令がディレイド不可というのは、感覚的に理解できなくもありません。・・・と思っていたのですが、実はディレイド可能でした。今回は、この件について記録しておこうと思います。 S1C33000コアCPUマニュアルによると、「ld.w %rd,%ss」「ld.w %sd,%rs」はディレイド不可となっています。（33000Core-J.pdf p.112「ld.w %rd,%ss」, p.117「ld.w %sd,%rs」, Appendix-1「Quick Reference」参照）しかし実際には、これらの命令もディレイド命令として利用できるようです。なぜなら、EPSON社純正ライブラリの除算ルーチンが、これらをディレイド命令として使っているからです。例えば、符号付き除算ルーチンは次のように実装されています。　　　　__divsi3: 　　　　　　　　ld.w %alr, %r12 　　　　　　　　div0s %r13 　　　　　　　　ld.w %r4, 0x4 　　　　　　　　ld.w %r5, %psr 　　　　__divsi3_loop_start: 　　　　　　　　div1 %r13 　　　　　　　　div1 %r13 　　　　　　　　div1 %r13 　　　　　　　　div1 %r13 　　　　　　　　div1 %r13 　　　　　　　　div1 %r13 　　　　　　　　div1 %r13 　　　　　　　　div1 %r13 　　　　　　　　sub %r4, 0x1 　　　　　　　　jrne.d __divsi3_loop_start　　　<= 次の命令がディレイド命令になります　　　　　　　　ld.w %psr, %r5　　　　　　　　　<= ld.w %sd(0),%rs(5) に相当します　　　　　　　　div2s %r13 　　　　　　　　div3 　　　　　　　　ret.d 　　　　　　　　　　　　　<= 次の命令がディレイド命令になります　　　　　　　　ld.w %r10, %alr 　　　　　　　　<= ld.w %rd(10),%ss(2) に相当します S1C33000コアCPUマニュアルによると、規定のディレイド可能な命令以外をディレイド命令として用いた場合、「動作が不安定となる」(p.30「ディレイド分岐機能」参照）とあります。前述の除算ルーチンのケースはたまたま動いていて、別の命令並びでは「動作が不安定となる」可能性もあるのですが、わざわざそんな危険な実装をするとは考えづらいので、たぶんいつでもディレイド可能なんじゃないかな、と思います。 * Fri Feb 14 12:30:00 JST 2003 Naoyuki Sawa - memcpy()でアドレス不整例外『ＸＭプレイヤー』作成において、なかなか消えない「アドレス不整例外」に悩まされました。今回は、その顛末をまとめておこうと思います。 P/ECEのCPU・S1C33209は、「不整アドレス」からのデータ読み出しを行おうとすると、「アドレス不整例外」を発生します。「不整アドレス」とは、読み出そうとしているデータ型のサイズの倍数になっていないアドレスのことです。例えば、int型データを読み出す場合、intは4バイトですので、読み出すアドレスも4の倍数でなければいけません。同様に、short型データを読み出す場合は、shortが2バイトですから、読み出すアドレスも2の倍数でなければいけません。「アドレス不整例外」が発生すると、画面には「Address error exception」と表示され、リセットを押すしかなくなります。以下に、「アドレス不整例外」を発生するコード例を、いくつか示します。　　　　int *p, v; p = (int*)0x120000; v = *p;　　/* 0x120000番地は4の倍数なので、「アドレス不整例外」は発生しません */ 　　　　int *p, v; p = (int*)0x120001; v = *p;　　/* 「アドレス不整例外」が発生します！ */ 　　　　int *p, v; p = (int*)0x120002; v = *p;　　/* 「アドレス不整例外」が発生します！ */ 　　　　int *p, v; p = (int*)0x120003; v = *p;　　/* 「アドレス不整例外」が発生します！ */ 　　　　int *p, v; p = (int*)0x120004; v = *p;　　/* 0x120004番地は4の倍数なので、「アドレス不整例外」は発生しません */ 　　　　shrot *p, v; p = (shrot*)0x120000; v = *p;　　/* 0x120000番地は2の倍数なので、「アドレス不整例外」は発生しません */ 　　　　shrot *p, v; p = (shrot*)0x120001; v = *p;　　/* 「アドレス不整例外」が発生します！ */ 　　　　shrot *p, v; p = (shrot*)0x120002; v = *p;　　/* 0x120002番地は2の倍数なので、「アドレス不整例外」は発生しません */ 通常のプログラムでは、「アドレス不整例外」に注意する必要はありません。 intデータは4の倍数アドレスに、shortデータは2の倍数アドレスに、コンパイラが適切に配置してくれるからです。注意が必要になるのは、あらかじめ決められた形式を持つデータ構造から、データを読み出す場合です。今回問題となったXM形式のデータ構造がまさにそれです。 XM形式のデータ構造では、奇数個のchar型データの直後に、空白なしでint型データが配置されていたりします。つまり、int型のデータが「不整アドレス」に配置されていることになります。メモリ上に読み込んだXM形式のデータ構造から、このようなint型データを読み出そうとすると、「アドレス不整例外」が発生します。 =============================================================================================================================== 「不整アドレス」からの読み出しができない、という制約を持つのは、S1C33209だけが特別ではありません。いちばんメジャーなPentiumシリーズCPUにはこの制約がないものの、他の多くのCPUは同様の制約を持っています。ですから、「不整アドレス」にデータが配置されている可能性のあるようなデータ構造からデータ読み出しを行う場合は、「アドレス不整例外」が発生しないよう、プログラム側で対処しなければいけません。いちばんオーソドックスなのは、次のような方法です。どんなアドレスからでも「アドレス不整例外」なしにint型データを読み出せるような、補助関数を用意します。　　　　int read_int(const int* p) { 　　　　　　　　const char* pp = (const char*)p; 　　　　　　　　return (pp[0] << 24) | (pp[1] << 16) | (pp[2] << 8) | (pp[3]); 　　　　} 4バイトの読み出しを1バイトづつ行ってから、int型に組み立てて返します。 1バイトづつの読み出しならば、絶対に「アドレス不整例外」は発生しません。（1の倍数でないアドレスはないから）この補助関数を使えば、引数pにどんなアドレスが指定されたとしても、そこからint型のデータが読み出せるわけです。それでは、この補助関数を使って、先ほど挙げた例を書き直してみます。　　　　int *p, v; p = (int*)0x120000; v = read_int(p);　　/* ＯＫ！ */ 　　　　int *p, v; p = (int*)0x120001; v = read_int(p);　　/* ＯＫ！ */ 　　　　int *p, v; p = (int*)0x120002; v = read_int(p);　　/* ＯＫ！ */ 　　　　int *p, v; p = (int*)0x120003; v = read_int(p);　　/* ＯＫ！ */ 　　　　int *p, v; p = (int*)0x120004; v = read_int(p);　　/* ＯＫ！ */ =============================================================================================================================== 以上の方法が、オーソドックスかつ正しい方法です。・・・が、しかし。僕はズボラなので、read_int()を次のように定義してしまいます。　　　　int read_int(const int* p) { int v; memcpy(&v, p, sizeof v); return v; } どこらへんがズボラかといいますと、いろいろな型のための補助関数を追加する場合、機械的な書き換えで対応できる点です。　　　　 int read_int (const int * p) { int v; memcpy(&v, p, sizeof v); return v; } 　　　　 short read_short (const short * p) { short v; memcpy(&v, p, sizeof v); return v; } 　　　　unsigned int read_unsigned_int (const unsigned int * p) { unsigned int v; memcpy(&v, p, sizeof v); return v; } 　　　　unsigned short read_unsigned_short(const unsigned short * p) { unsigned short v; memcpy(&v, p, sizeof v); return v; } 　　　　 float read_float (const float * p) { float v; memcpy(&v, p, sizeof v); return v; } 　　　　 double read_double (const double* p) { double v; memcpy(&v, p, sizeof v); return v; } ちなみに、オーソドックスな方法でread_short()やread_double()を実装すると、こうなります。　　　　short read_short(const short* p) { 　　　　　　　　const char* pp = (const char*)p; 　　　　　　　　return (pp[0] << 8) | (pp[3]); 　　　　} 　　　　float read_double(const double* p) { 　　　　　　　　const char* pp = (const char*)p; 　　　　　　　　char v[8]; 　　　　　　　　v[0] = pp[0]; 　　　　　　　　v[1] = pp[1]; 　　　　　　　　v[2] = pp[2]; 　　　　　　　　v[3] = pp[3]; 　　　　　　　　v[4] = pp[4]; 　　　　　　　　v[5] = pp[5]; 　　　　　　　　v[6] = pp[6]; 　　　　　　　　v[7] = pp[7]; 　　　　　　　　return *(double*)v; 　　　　} まあこの程度ですので大した手間ではないのですが、この程度の手間も惜しむほどズボラだという…(^^; これまでP/ECE以外の環境でも、memcpy()を使ったズボラ版補助関数を使っていましたし、それで上手くいっていると思っていました。・・・が、それは間違いでした。 =============================================================================================================================== ズボラ版補助関数は、memcpy()が内部でデータを1バイトづつコピーしてくれることを前提としています。いや、良く出来たmemcpy()の実装の場合、指定された転送元・転送先アドレスと転送サイズによっては、数バイトづつのコピーを行って処理を高速化するとは聞いていましたが、少なくとも「アドレス不整例外」が発生するような方法は採られないものと思い込んでいました。ところが、コンパイラによる最適化が絡んでくると、必ずしもそうとは言えないようなのです。それではまず、「アドレス不整例外」を発生するmemcpy()の使用例を示します。 ------------------------------------------------------------------------------------------------------------------------------- 　　　　#include 　　　　#include 　　　　　　　　volatile int* ptr; 　　　　volatile int val; 　　　　volatile char data[] = { 0,1,2,3,4,5 }; 　　　　/* ここを読みます ~~~~~~~ */ 　　　　　　　　int read_int(const int* p) { int v; memcpy(&v, p, sizeof v); return v; } 　　　　　　　　void pceAppInit() { } 　　　　void pceAppExit() { } 　　　　void pceAppProc(int count) { 　　　　　　　　ptr = (int*)&data[1]; 　　　　　　　　val = read_int(ptr); 　　　　} ------------------------------------------------------------------------------------------------------------------------------- 変数にvolatile指定を追加しているのは、最適化によって読み出し処理そのものが削られてしまわないようにするためです。特に重要な意味はありません。さて、このプログラムを最適化オプション「-O2」を指定してコンパイルします。そして実行すると・・・「アドレス不整例外」が発生します！「-ls」オプションを指定してシンボルファイルを作成してみると、data[]配列は0x100264番地に確保されていました。プログラムでは&data[1]から読み出そうとしているので、つまり0x100265番地からint型データを読み出していることになります。そのまま読み出したのでは「アドレス不整例外」が発生するのは必然ですが、今回はちゃんと補助関数を使っています。にもかかわらず「アドレス不整例外」発生。なぜ？ =============================================================================================================================== memcpy()のところで、コンパイラはどのようなコードを生成しているのでしょうか？「-b」オプションを指定して、コンパイラが生成したアセンブラソースを確認してみます。 ※読みやすいように、少し編集してあります。 ----------------------------------------[S1C33用gccの生成コード]--------------------------------------------------------------- 　　　　read_int: 　　　　　　　　xsub %sp, %sp, 4 　　　　　　　　xld.w %r10, [%r12] 　　　　　　　　xld.w [%sp], %r10 　　　　　　　　xadd %sp, %sp, 4 　　　　　　　　ret 　　　　　　　　pceAppProc: 　　　　　　　　xld.w %r12, data+1 　　　　　　　　xld.w [ptr], %r12 　　　　　　　　xcall read_int 　　　　　　　　xld.w [val], %r10 　　　　　　　　ret ------------------------------------------------------------------------------------------------------------------------------- なんと、単なるint型データの読み出し・格納になってしまっています！「アドレス不整例外」が発生するわけです。これは明らかに、コンパイラの最適化による副作用です。では、このような最適化が行われるのは・P/ECEのコンパイラ（S1C33用gcc）が特別なのでしょうか？・それとも、gccならどれでもそうなのでしょうか？・あるいは、どのコンパイラでもたいていこうなるのでしょうか？まずは、他のCPU用のgccで確認してみます。 SPARC用gccで同様のプログラムを試してみると、やはり「アドレス不整例外」になりました。（Linux上で試したので、画面表示は「Bus Error」となります。）コンパイラが生成したアセンブラソースは、次のようになります。 ※読みやすいように、少し編集してあります。 ----------------------------------------[SPARC用gccの生成コード]--------------------------------------------------------------- 　　　　read_int: 　　　　　　　　retl 　　　　　　　　ld [%o0], %o0 　　　　　　　　main: 　　　　　　　　save %sp, -104, %sp 　　　　　　　　sethi %hi(data+1), %o0 　　　　　　　　call read_int,0 　　　　　　　　or %o0, %lo(data+1), %o0 　　　　　　　　ret 　　　　　　　　restore %g0, %o0, %o0 ------------------------------------------------------------------------------------------------------------------------------- 僕は、SPARCプロセッサのアセンブラはぜんぜん読めませんが、read_int()が1バイトづつコピーしていないのはわかります。（あと余談ですが、ディレイスロットによる最適化で命令の順番が入れ替わったりしているのが見えます。　また、P/ECEのS1C33用gccは、SPARC用gccに較べて、不要なローカル変数の削除による最適化がまだまだ弱いこともわかります。）どうやらgccを使って最適化コンパイルを行うと、だいたい同じような結果になるようです。それでは、別のコンパイラではどうでしょうか？ VisualC++6.0を使って、同様のプログラムをコンパイルしてみます。最適化オプションは、Releaseビルドの初期設定のままとしました。 ※読みやすいように、少し編集してあります。 ----------------------------------------[Pentium用VisualC++6.0の生成コード]---------------------------------------------------- 　　　　read_int: 　　　　　　　　mov eax, dword ptr [esp+4] 　　　　　　　　mov eax, dword ptr [eax] 　　　　　　　　ret 　　　　　　　　main: 　　　　　　　　push offset data+1 　　　　　　　　call read_int 　　　　　　　　add esp, 4 　　　　　　　　ret ------------------------------------------------------------------------------------------------------------------------------- 同じです。やはり、read_int()は1バイトづつコピーしていません。（ただしPentiumの場合はそもそも「アドレス不整例外」の制約がありませんので、このプログラムを実行しても問題は出ません。）どうやらどのコンパイラでも、memcpy()が最適化されて不整アドレスからの読み出しが発生する可能性はあるようです。しかし、こんな重大な問題にこれまで気が付かなかったとは・・・例えば、P/ECEで仮想VRAMの(0,1)～(0,4)のピクセルを(1,1)～(1,4)へコピーしようとしたら、「アドレス不整例外」になるのでしょうか？ ------------------------------------------------------------------------------------------------------------------------------- 　　　　#include 　　　　　　　　unsigned char vbuff[128 * 88]; 　　　　　　　　void pceAppInit() { 　　　　　　　　pceLCDSetBuffer(vbuff); 　　　　　　　　pceLCDDispStart(); 　　　　} 　　　　void pceAppExit() { } 　　　　void pceAppProc(int count) { 　　　　　　　　unsigned char *src, *dst; 　　　　　　　　src = &vbuff[ 1]; 　　　　　　　　dst = &vbuff[129]; 　　　　　　　　memcpy(dst, src, 4); 　　　　　　　　pceLCDTrans(); 　　　　} ------------------------------------------------------------------------------------------------------------------------------- 試してみると・・・「アドレス不整例外」は発生しません。そりゃあ　、これで「アドレス不整例外」が発生するのなら、とっくに気付いているはずですよね。生成されるコードは次のようになります。 ※読みやすいように、少し編集してあります。 ------------------------------------------------------------------------------------------------------------------------------- 　　　　pceAppProc: 　　　　　　　　xld.w %r13, vbuff+1 　　　　　　　　xadd %r12, %r13, 128 　　　　　　　　xld.w %r14, 0x00000004 　　　　　　　　xcall memcpy 　　　　　　　　xcall pceLCDTrans 　　　　　　　　ret ------------------------------------------------------------------------------------------------------------------------------- 同じ4バイトのコピーなのに、こちらはちゃんとmemcpy()関数が呼び出されています。「アドレス不整例外」になる例との違いは・・・memcpy()に渡しているポインタの型でしょうか？それでは、プログラムを次のように変更して、もういちど試してみます。 ------------------------------------------------------------------------------------------------------------------------------- 　　　　#include 　　　　　　　　unsigned char vbuff[128 * 88]; 　　　　　　　　void pceAppInit() { 　　　　　　　　pceLCDSetBuffer(vbuff); 　　　　　　　　pceLCDDispStart(); 　　　　} 　　　　void pceAppExit() { } 　　　　void pceAppProc(int count) { 　　　　　　　　int *src, *dst; 　　　　　　　　src = (int*)&vbuff[ 1]; 　　　　　　　　dst = (int*)&vbuff[129]; 　　　　　　　　memcpy(dst, src, 4); 　　　　　　　　pceLCDTrans(); 　　　　} ------------------------------------------------------------------------------------------------------------------------------- で、実行してみると・・・「アドレス不整例外」が発生しました！生成されるコードは次の通り。 ※読みやすいように、少し編集してあります。 ------------------------------------------------------------------------------------------------------------------------------- 　　　　pceAppProc: 　　　　　　　　xld.w %r11, vbuff+1 　　　　　　　　xld.w %r10, [%r11] 　　　　　　　　xld.w [%r11+128], %r10 　　　　　　　　xcall pceLCDTrans 　　　　　　　　ret ------------------------------------------------------------------------------------------------------------------------------- vbuff[1]の位置からint型で読み出しを行い、vbuff[1+128]の位置に格納しようとしています。なんとなく見えてきました。　　　　memcpy()にint*型のポインタを渡すと、単なるint型データの読み出しとして最適化される可能性がある。　　　　その際、ポインタが「不整アドレス」を指しているかどうかは調べられない。　　　　結果、ポインタが「不整アドレス」を指していたなら、「アドレス不整例外」が発生する。 P/ECEの仮想VRAMを扱う場合は、たいていunsigned char*型のポインタを渡すので、問題にならなかったのですね。 =============================================================================================================================== 回避方法は次のとおりです。１．オーソドックスなread_int()を使う。　　つまり、memcpy()を使わず、明示的に1バイトづつ読み出して、組み立てる。２．ズボラ版read_int()の引数型を変更する。　　修正後のread_int()は、次のようになります。　　　　int read_int(const void* p) { int v; memcpy(&v, p, sizeof v); return v; } 　　『ＸＭプレイヤー』では、この方法で解決しました。３．最適化しない。　　「-O2」オプションを指定しません。しかしこれは、現実的な方法ではありません。　　S1C33用gccには「-mno-memcpy」というオプションがあります。　　gcc33コマンドの使い方表示には「inline functions 'strcpy' and 'memcpy'」と書かれており、　　このコンパイルオプションを使ってmemcpy()の最適化だけを制御できそうに見えます。　　が、実際にはこのオプションは、memcpy()の最適化には関係ないようです。　　　　gcc33 -S -O sample.c 　　　　gcc33 -S -O -mmemcpy sample.c 　　　　gcc33 -S -O -mno-memcpy sample.c 　　いずれの方法でコンパイルしてもmemcpy()は最適化されてしまい、「アドレス不整例外」が発生します。　　そもそもpcc33経由では、gcc33にこのオプションを渡せません。　　それに、一部のmemcpy()最適化による問題を回避するためだけに、全部の最適化を抑制してしまうというのはやりすぎです。 =============================================================================================================================== さて、コンパイラにケチを付けるのも身の程知らずですが、しかしこれはちょっと納得いかないような気もします。 memcpy()を最適化してくれるのはありがたいのですけれど、memcpy()のプロトタイプはもともと次のようなものです。　　　　void* memcpy(void* dst, const void* src, size_t len); memcpy()自身は、受け取ったポインタの正確な型を知っていてはいけないはずです。 int*型ポインタだから最適化するとか、char*型ポインタだから最適化しない、というやり方は不可だと思うのですが… Ｃ言語仕様的にはどうなのでしょうか？もしかしたら、int*型ポインタに「不整アドレス」を代入した時点で既にＣ言語仕様違反なのでしょうか？要調査です。 * Wed Dec 25 00:00:00 JST 2002 Naoyuki Sawa - ISDマニュアル#3 （前回からの続き…）今回は、残り三つのファイルシステムコマンドについてです。　　　　　　　　=r　　　　ファイルを読み出します。（P/ECE→PC）　　　　　　　　=d　　　　P/ECE上のファイルを削除します。　　　　　　　　=i　　　　ファイルシステムを初期化します。しかしながらこれら三つのコマンドは、前回の二つに較べてかなり使用頻度が低いです。例えば僕の場合、実験以外で「=r」「=d」は使ったことがなく、「=i」は一回使っただけです。ですので、これら三つのコマンドについてはざっと流してしまうことにしましょう。コマンド「=r」と「=d」でのファイル指定に関するルールは、コマンド「=w」の場合と同じなので、コマンド「=r」と「=d」に関する今回の説明は、前回のコマンド「=w」の説明とほとんど同じです。実際、今回の説明の大部分は前回のコピーなのですが(^^;、念のため、各入力例の動作確認は行いました。 ------------------------------------------------------------------------------------------------------------------------------- -------------------- =r：ファイル読み出し -------------------- 書式：　　　　　=r <ファイル名> P/ECE上にあるファイルを、PCに読み出します。 PC上に既に同名のファイルが存在した場合は、既存のファイルに上書きします。例１：　　　　　=r date.pex 　　　　　　　　P/ECE上にある「date.pex」を、PCの現在の作業フォルダに「date.pex」というファイル名で読み出します。　　　　　　　　読み出しに成功すると、次のような出力が画面に表示されます。　　　　　　　　reading 'date.pex' done 　　　　　　　　date.pexが存在しない場合は、読み出しに失敗します。　　　　　　　　画面には何も表示されず、すぐに次のコマンド待ちプロンプト「>」が表示されます。例２：　　　　　=r date 　　　　　　　　P/ECE上に「date.pex」があれば、PCの現在の作業フォルダに「date.pex」というファイル名で読み出します。　　　　　　　　ファイル名の拡張子を省略すると、拡張子「.pex」が自動的に補われます。　　　　　　　　もしP/ECE上に拡張子なしの「date」というファイルがあり、これを読み込みたかったのだとしても、ISDが「.pex」を補ってしまいます。　　　　　　　　従ってISDの「=r」コマンドでは、拡張子のないファイル名を持つファイルを読み出すことはできません。　　　　　　　　拡張子なしのファイルを読み出そうとして失敗した様子を、次に示します。　　　　　　　　C:\>isd 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　PIECE Monitor version 1.07 (C)2001-2002 by MIO.H　　　　　　　　　　　　>=　　　　　　　　　　　　　　　　　　　　　　　　　　　…P/ECE上のファイルリストを取得します。　　　　　　　　+ 0: 2703 startup.pex 　　　　　　　　　　　　　　　　　　　　　　　　+ 1: 1221 date　　　　　　　　　　　　　　　　　　　　…拡張子なしの「date」というファイルがあります。　　　　　　　　 85 sectors (348160 bytes) free　　　　　　　　　　　　　　　　　　　>=r date　　　　　　　　　　　　　　　　　　　　　　　　…「date」を読み出してみます。　　　　　　　　> 　　　　　　　　　　　　　　　　　　　　　　　　　　　…ISDは「date.pex」を読み出そうとして失敗し、何も表示されません。例３：　　　　　=r readme.txt 　　　　　　　　「.pex」以外の拡張子を持つファイルを読み出す場合は、拡張子を省略することはできません。　　　　　　　　必ず、拡張子まで含めて指定してください。例４：　　　　　=rdate.pex 　　　　　　　　コマンド「=w」の場合と同じく、「=r」とファイル名の間の空白文字は、あってもなくても構いません。　　　　　　　　この例のように、「=r」とファイル名を続けて書いても大丈夫です。以下は悪い例です。例５：　　　　　=r hello.pex world.pex 　　　　　　　　複数のファイルを一度に読み出すことはできません。　　　　　　　　この例の場合、「hello.pex」は読み出されますが、「world.pex」の指定は完全に無視されます。　　　　　　　　すなわち、　　　　　　　　=r hello.pex 　　　　　　　　と指定したのと全く同じ結果となります。　　　　　　　　「world.pex」を指定したことに対するエラーや警告等も表示されません。例６：　　　　　=w *.pex 　　　　　　　　ワイルドカードによるファイル指定はできません。 ---------------- =d：ファイル削除 ---------------- 書式：　　　　　=d <ファイル名> P/ECE上にあるファイルを削除します。例１：　　　　　=d date.pex 　　　　　　　　P/ECE上にある「date.pex」を削除します。　　　　　　　　削除に成功すると、次のような出力が画面に表示されます。　　　　　　　　FlashErase c28000 0 　　　　　　　　FlashWrite c28000 130000 1000 0 　　　　　　　　date.pexが存在しない場合は、削除に失敗します。　　　　　　　　画面には何も表示されず、すぐに次のコマンド待ちプロンプト「>」が表示されます。例２：　　　　　=d date 　　　　　　　　P/ECE上に「date.pex」があれば、「date.pex」を削除します。　　　　　　　　ファイル名の拡張子を省略すると、拡張子「.pex」が自動的に補われます。　　　　　　　　もしP/ECE上に拡張子なしの「date」というファイルがあり、これを削除したかったのだとしても、ISDが「.pex」を補ってしまいます。　　　　　　　　従ってISDの「=d」コマンドでは、拡張子のないファイル名を持つファイルを削除することはできません。　　　　　　　　拡張子なしのファイルを削除しようとして失敗した様子を、次に示します。　　　　　　　　C:\>isd 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　PIECE Monitor version 1.07 (C)2001-2002 by MIO.H　　　　　　　　　　　　>=　　　　　　　　　　　　　　　　　　　　　　　　　　　…P/ECE上のファイルリストを取得します。　　　　　　　　+ 0: 2703 startup.pex 　　　　　　　　　　　　　　　　　　　　　　　　+ 1: 1221 date　　　　　　　　　　　　　　　　　　　　…拡張子なしの「date」というファイルがあります。　　　　　　　　 85 sectors (348160 bytes) free　　　　　　　　　　　　　　　　　　　>=d date　　　　　　　　　　　　　　　　　　　　　　　　…「date」を削除してみます。　　　　　　　　> 　　　　　　　　　　　　　　　　　　　　　　　　　　　…ISDは「date.pex」を削除しようとして失敗し、何も表示されません。例３：　　　　　=d readme.txt 　　　　　　　　「.pex」以外の拡張子を持つファイルを削除する場合は、拡張子を省略することはできません。　　　　　　　　必ず、拡張子まで含めて指定してください。例４：　　　　　=ddate.pex 　　　　　　　　コマンド「=w」や「=r」の場合と同じく、「=d」とファイル名の間の空白文字は、あってもなくても構いません。　　　　　　　　この例のように、「=d」とファイル名を続けて書いても大丈夫です。以下は悪い例です。例５：　　　　　=d hello.pex world.pex 　　　　　　　　複数のファイルを一度に削除することはできません。　　　　　　　　この例の場合、「hello.pex」は削除されますが、「world.pex」の指定は完全に無視されます。　　　　　　　　すなわち、　　　　　　　　=d hello.pex 　　　　　　　　と指定したのと全く同じ結果となります。　　　　　　　　「world.pex」を指定したことに対するエラーや警告等も表示されません。例６：　　　　　=w *.pex 　　　　　　　　ワイルドカードによるファイル指定はできません。 -------------------------- =i：ファイルシステム初期化 -------------------------- 書式：　　　　　=i P/ECEのフラッシュメモリファイルシステムを初期化します。例：　　　　　　=i 　　　　　　　　P/ECEのフラッシュメモリファイルシステムを初期化します。　　　　　　　　確認のため、ISDから次のような問い合わせが表示されます。　　　　　　　　Init file system. Sure?(Y/N) 　　　　　　　　本当に初期化してよければ「y」、やっぱりやめるなら「y」以外のキーを押します。　　　　　　　　「y」キーを押すとファイルシステムが初期化され、次のような出力が画面に表示されます。　　　　　　　　FlashErase c28000 0 　　　　　　　　FlashWrite c28000 130000 1000 0 　　　　　　　　「y」以外のキーを押して初期化を取りやめた場合は、なぜかファイル一覧が表示されます。　　　　　　　　“初期化しなかったのでご安心を”というメッセージでしょうか？(^^; なにかの拍子にP/ECEのファイルシステムが壊れてしまった場合は、コマンド「=i」で回復できる可能性があります。ただし、P/ECE上のファイルは全て消えてしまいますので、ご注意ください。また、「P/ECEカーネル・アップデート」(WinPku.exe)や「P/ECEコミュニケータ」(WinIsd.exe)を使って、うっかり2MB版P/ECEにカーネルアップデートをかけてしまった場合にも、コマンド「=i」のお世話になることになります。「P/ECEカーネル・アップデート」や「P/ECEコミュニケータ」でカーネルアップデートを行うと、 512KB以降のセクタが“無効なセクタ”とマークされてしまい、せっかくの2MB版P/ECEが通常の512KB版P/ECEになってしまいます。 2MB版P/ECEに戻すには、「FLASH2MB向け改造カーネル及びシステム」のreadme.txtファイルに書かれているように、 2MB版カーネルを転送した後、2MB用ISDのコマンド「=i」でファイルシステムを初期化する必要があります。 2MB版カーネルを転送しただけでは、512KB以降のセクタは有効になりません！僕も先日これをやってしまって、ちょっとハマリました。参照：　　　　　「六波羅さんのスペース」（http://rokuhara.jp.org）　　　　　　　　→「めっちゃ幸せFRASHメモリ4倍化計画」（http://www2s.biglobe.ne.jp/~rokuhara/piece/flash2mb.htm）　　　　　　　　→「FLASH2MB向け改造カーネル及びシステム」（http://www2s.biglobe.ne.jp/~rokuhara/piece/flash2mb.lzh） ------------------------------------------------------------------------------------------------------------------------------- ファイルシステムコマンドは以上です。次回は、メモリダンプ等の低水準コマンドについて見ていこうと思います。（続きます…） * Sun Dec 22 08:26:00 JST 2002 Naoyuki Sawa - ISDマニュアル#2 （前回からの続き…）今回は、ISDコマンドの中でも特に使用頻度が高いと思われる、ファイルシステムコマンドについて見ていきます。その前に、コマンド説明全般に関する注意点です。 ISDは既に「入力オペレーションモード」でコマンド待ち状態になっているものと仮定して、説明を行うことにします。 ISDの起動・終了手順については、コマンド入力例に含めません。例えば、次のようなコマンド入力例があった場合、　　　　　　　　=d hello.pex 　　　　　　　　=w world.pex ISDの起動・終了手順も含めると、実際には次のようにタイプしてください。　　　　　　　　isd 　　　　　　　　…「入力オペレーションモード」でISDを起動します。　　　　　　　　=d hello.pex　　　　　　　　　　　　=w world.pex　　　　　　　　　　　　q 　　　　　　　　　…ISDを終了します。「入力オペレーションモード」については、前回の説明を参照してください。 ------------------------------------------------------------------------------------------------------------------------------- ======================== ファイルシステムコマンド ======================== ファイルシステムコマンドは、ファイル一覧表示やファイル転送など、ファイルシステムに関する操作を行うコマンドです。全部で５つのコマンドがあります。　　　　　　　　= 　　　　ファイル一覧を表示します。　　　　　　　　=w　　　　ファイルを書き込みます。（PC→P/ECE）　　　　　　　　=r　　　　ファイルを読み出します。（P/ECE→PC）　　　　　　　　=d　　　　P/ECE上のファイルを削除します。　　　　　　　　=i　　　　ファイルシステムを初期化します。ご覧のように、ファイルシステムコマンドは全て「=」で始まります。ところで、ISDのヘルプ（コマンド「?」で表示されます）を見ると、もう一つ「=」で始まるコマンドが載っています。時刻設定コマンド「=t」です。が、これはISDヘルプのミスプリントで、正しい時刻設定コマンドは「t」です。時刻設定コマンド「t」については、次回以降に説明します。 --------------- =：ファイル一覧 --------------- 書式：　　　　　= P/ECE上にあるファイル一覧と、開きセクタ数・バイト数を表示します。例１：　　　　　= 　　　　　　　　出力結果は次のようになります。　　　　　　　　+ 0: 2703 startup.pex 　　　　　　　　+ 1: 92352 rt.pex 　　　　　　　　+ 2: 11408 rt.fpk 　　　　　　　　+ 3: 57400 padv.pex 　　　　　　　　+ 4:137719 padv.fpk 　　　　　　　　 11 sectors (45056 bytes) free ファイル一覧コマンドについては、特に注意点もありません。ファイル一覧はP/ECEコミュニケータ等を使っても見られるのですが、ISDのファイル一覧コマンドも意外と便利です。標準の開発環境を使ってP/ECEアプリケーションの作成を行う場合、ほとんどの作業はDOS窓での作業となります。その際、ファイル一覧を見るためだけにP/ECEコミュニケータを起動しなくても、コマンドプロンプトから　　　　　　　　isd = とタイプするだけで、P/ECE上のファイル一覧が調べられます。 DOSの「DIR」コマンドと同じ感覚ですね。 -------------------- =w：ファイル書き込み -------------------- 書式：　　　　　=w <ファイル名> PC上にあるファイルを、P/ECEに書き込みます。 P/ECE上に既に同名のファイルが存在した場合は、既存のファイルに上書きします。例１：　　　　　=w date.pex 　　　　　　　　現在の作業フォルダにある「date.pex」を、P/ECEに書き込みます。　　　　　　　　書き込みに成功すると、次のような出力が画面に表示されます。　　　　　　　　date.pex 　　　　　　　　FlashErase c77000 0 　　　　　　　　FlashWrite c77000 130000 4c5 0 　　　　　　　　FlashErase c28000 0 　　　　　　　　FlashWrite c28000 130000 1000 0 　　　　　　　　date.pexが存在しない場合は、書き込みに失敗します。　　　　　　　　ファイル名だけが画面に表示され、エラーメッセージ等は特に表示されないので要注意です。　　　　　　　　date.pex 　　　　　　　　空き容量が足りなくて書き込みに失敗した場合は、ちゃんとエラーメッセージも表示されます。　　　　　　　　date.pex 　　　　　　　　空きが足りません。例２：　　　　　=w C:\usr\PIECE\app\date.pex 　　　　　　　　「C:\usr\PIECE\app\date.pex」を、P/ECEに書き込みます。　　　　　　　　現在の作業フォルダ以外の場所にあるファイルを書き込むときは、この例のようにフルパスで指定してください。例３：　　　　　=w date 　　　　　　　　現在の作業フォルダに「date.pex」があれば、「date.pex」をP/ECEに書き込みます。　　　　　　　　ファイル名の拡張子を省略すると、拡張子「.pex」が自動的に補われます。　　　　　　　　もし本当に「date」というファイルを書き込みかったのだとしても、ISDが「.pex」を補ってしまいます。　　　　　　　　従ってISDの「=w」コマンドでは、拡張子のないファイル名を持つファイルを書き込むことはできません！例４：　　　　　=w readme.txt 　　　　　　　　「.pex」以外の拡張子を持つファイルを書き込む場合は、拡張子を省略することはできません。　　　　　　　　必ず、拡張子まで含めて指定してください。例５：　　　　　=wdate.pex 　　　　　　　　実は、「=w」とファイル名の間の空白文字は、あってもなくても構いません。　　　　　　　　この例のように、「=w」とファイル名を続けて書いても大丈夫です。以下は悪い例です。例６：　　　　　=w hello.pex world.pex 　　　　　　　　複数のファイルを一度に書き込むことはできません。　　　　　　　　この例の場合、「hello.pex」は書き込まれますが、「world.pex」の指定は完全に無視されます。　　　　　　　　すなわち、　　　　　　　　=w hello.pex 　　　　　　　　と指定したのと全く同じ結果となります。　　　　　　　　「world.pex」を指定したことに対するエラーや警告等も表示されません。例７：　　　　　=w *.pex 　　　　　　　　ワイルドカードによるファイル指定はできません。ファイル書き込みコマンドが役に立つのは、MakefileでpexをP/ECEに転送する場合です。例えば次のような内容のMakefileがあった場合　　　　　　　　all: hello.srf 　　　　　　　　pex: hello.pex 　　　　　　　　hello.srf: hello.c 　　　　　　　　　　　　pcc33 hello.c 　　　　　　　　hello.pex: hello.srf 　　　　　　　　　　　　ppack -e hello.srf -ohello.pex 「make」で「hello.srf」が作成され、「make pex」で「hello.pex」が生成されます。 P/ECEへのpexファイル転送も自動化するためには、次の二行を追加します。　　　　　　　　all: hello.srf 　　　　　　　　pex: hello.pex 　　　　　　　　hello.srf: hello.c 　　　　　　　　　　　　pcc33 hello.c 　　　　　　　　hello.pex: hello.srf 　　　　　　　　　　　　ppack -e hello.srf -ohello.pex 　　　　　　　　install: hello.pex　　　　　　　　　←これを追加　　　　　　　　　　　　isd =w hello.pex　　　　　　←これを追加「make install」とタイプすれば、「hello.pex」の作成・転送までが自動的に行われます。 hello.pexから利用するデータファイル等がある場合は、データファイルの転送も追加しておきましょう。　　　　　　　　all: hello.srf 　　　　　　　　pex: hello.pex 　　　　　　　　hello.srf: hello.c 　　　　　　　　　　　　pcc33 hello.c 　　　　　　　　hello.pex: hello.srf 　　　　　　　　　　　　ppack -e hello.srf -ohello.pex 　　　　　　　　install: hello.pex 　　　　　　　　　　　　isd =w hello.pex 　　　　　　　　　　　　isd =w hell_dat.fpk　　　　←これを追加 ------------------------------------------------------------------------------------------------------------------------------- ちょっと長くなったので、今回はここまでです。残り３つのファイルシステムコマンドについては、次回へ。（…続きます） * Fri Dec 20 12:30:00 JST 2002 Naoyuki Sawa - ISDマニュアル#1 P/ECE開発ツールの中でも特に重要なのが、USB転送ツール/簡易モニター『ISD』です。地味ながら非常に多機能で、PC側のツールとして必要な機能をほとんど全部備えています。バージョンチェック、ファイル転送、画面キャプチャ、プログラムの一時停止、カーネル更新などが、これ一つでまかなえます。コマンドラインツールを好む開発者さんは、既に使いこなしておられるのではないでしょうか。 ISDを使う際の問題点として、P/ECE開発環境にはISDの詳しい説明が入っていない、という点が挙げられます。 ISDのソース（C:\usr\PIECE\tools\isd）や、「isd ?」で表示されるヘルプで充分とも言えますが、やはりまとまった説明が欲しいところです。（僕はたまにしかISDを使わないので、そのたびに使い方を忘れて、ISDのソースを読みかえしたりしてます…(^^;）そこで、今回より数回に分けて、ISDの使い方をまとめてみようと思います。今回はまず、ISDの起動方法についてです。 ------------------------------------------------------------------------------------------------------------------------------- ======== 起動方法 ======== ISDは、三つの起動モードを持っています。・「プログラム実行モード」・「引数オペレーションモード」・「入力オペレーションモード」です。 ※「引数オペレーションモード」と「入力オペレーションモード」のネーミングは、ISDのソースのコメントに由来します。　「プログラム実行モード」は便宜上、僕が勝手に名付けました。 -------------------- プログラム実行モード -------------------- 起動方法１：　　isd [#<デバイス番号>] -run 起動方法２：　　isd [#<デバイス番号>] -run 起動方法３：　　isd [#<デバイス番号>] -run srfファイルを直接実行するモードです。 srfファイルの実行開始後、ISDはすぐに終了します。起動方法１のように、srfファイル名を指定すると、そのsrfファイルを実行します。例１：　　　　　isd -run C:\usr\PIECE\app\hello\hello.srf 　　　　　　　　「C:\usr\PIECE\app\hello\hello.srf」を実行します。起動方法２のように、srfファイルの拡張子「.srf」を省略しても構いません。例２：　　　　　isd -run C:\usr\PIECE\app\hello\hello 　　　　　　　　「C:\usr\PIECE\app\hello\hello.srf」を実行します。起動方法３のように、ファイル名の指定を完全に省略すると、現在の作業フォルダからsrfファイルを探して、最初に見つかったsrfファイルを実行します。現在の作業フォルダに複数のsrfファイルがあった場合は、どのsrfファイルが実行されるかは予測できません。例３：　　　　　C: 　　　　　　　　cd \usr\PIECE\app\hello\ 　　　　　　　　isd -run 　　　　　　　　「C:\usr\PIECE\app\hello\」フォルダの中にある「hello.srf」を実行します。 P/ECEが複数台接続されているときは、デバイス番号を指定して、二台目以降のP/ECEでsrfファイルを実行することもできます。デバイス番号は、0が一台目のP/ECE、1が二台目のP/ECE、2が三台目のP/ECE、...を表します。デバイス番号を指定しなければ、一台目のP/ECEでsrfファイルを実行します。デバイス番号を指定することは滅多にありませんが、赤外線通信プログラムなどを開発している場合はこの機能が便利に使えます。 Makefileやバッチファイルなどに、　　　　　　　　isd #0 -run ir.srf 　　　　　　　　isd #1 -run ir.srf と書いておくと、「ir.srf」を二台のP/ECEで実行することができます。「プログラム実行モード」については、以上です。「プログラム起動モード」を簡単に使うために、バッチファイル「C:\usr\PIECE\bin\run.bat」が用意されています。「C:\usr\PIECE\bin\run.bat」の内容は、次のとおりです。　　　　　　　　@isd -run %1 srfファイルを実行するためによく「run」コマンドを使いますが、「run」コマンドはISDの「プログラム実行モード」の別名なのです。ちなみに先頭の「@」は、バッチファイルの中から実行するコマンド名を、画面に表示しないようにするための記号です。だから、「run」コマンドを使っても、バッチファイルの中からISDを呼んでいる様子は画面に表示されません。 ------------------------ 引数オペレーションモード ------------------------ 起動方法１：　　isd [#デバイス番号] <コマンド> 起動方法２：　　isd [#デバイス番号] <コマンド>;<コマンド>;... ISDへのコマンドを、ISD起動時にいっしょに指定するモードです。各コマンドを実行後、ISDはすぐに終了します。なお、デバイス番号については「プログラム実行モード」と同じですので、説明を省略します。起動方法１は、コマンドを一つだけ指定する、いちばん基本的な方法です。例１－１：　　　isd v 　　　　　　　　P/ECEカーネルのバージョン情報を表示します。　　　　　　　　コマンド「v」は、バージョン情報を表示するためのコマンドです。　　　　　　　　（※個々のコマンドの詳細については後述します。以下同様）コマンドが空白を含む場合は、コマンド全体を「"」で囲むのが一般的ですが、必須ではありません。例１－２：　　　isd "d 100000" 　　　　　　　　isd d 100000 　　　　　　　　どちらも同じく、0x100000番地から128バイト分のメモリ内容をバイナリダンプします。コマンド「d」は、メモリ内容をバイナリダンプするためのコマンドです。有効なコマンドの後ろに不要な文字列がくっついていても、警告もなく単に無視されますが、このふるまいに依存するのは望ましくありません。次の例は、間違ったコマンド指定の例です。例１－３：　　　isd vHOGE 　　　　　　　　コマンド「v」の後の「HOGE」は無視されます。　　　　　　　　「isd v」と指定したのと同じ結果となり、「HOGE」に対する警告なども表示されません。一度に複数のコマンドを指定することもできます。複数のコマンドを指定する場合は、起動方法２のように、各コマンドを「;」で区切って並べます。例２－１：　　　isd v;= 　　　　　　　　バージョン情報と、ファイル一覧を表示します。　　　　　　　　コマンド「=」は、ファイル一覧を表示するためのコマンドです。コマンド並びが空白を含む場合は、コマンド並び全体を「"」で囲むのが一般的ですが、必須ではありません。例２－２：　　　isd "d 100000;d 200000" 　　　　　　　　isd d 100000;d 200000 　　　　　　　　どちらも同じく、0x100000番地からの128バイト分のメモリ内容をバイナリダンプし、　　　　　　　　続けて、0x200000番地からの128バイト分のメモリ内容をバイナリダンプします。コマンドを区切る「;」の左右には、空白文字を置かないほうがいいでしょう。実際には、「;」左側には空白を含めてどんな文字があっても無視されるのですが、このふるまいに依存するのは望ましくありません。「;」の右側に空白文字を置いた場合は、警告が表示されます。次の例は、間違ったコマンド指定の例です。例２－３：　　　isd vHOGE;= 　　　　　　　　例１－３と同じく、コマンド「v」の後の「HOGE」は無視されます。　　　　　　　　「isd v;=」と指定したのと同じ結果となり、「HOGE」に対する警告なども表示されません。例２－４：　　　isd "v ; =" isd v ; = 　　　　　　　　どちらも同じく、「;」の後ろにある空白文字に対して、次のような警告が表示されます。　　　　　　　　skip ' ' 　　　　　　　　警告は出るもののコマンド自体は正しく実行され、バージョン情報とファイル一覧が表示されます。　　　　　　　　「;」の左側にある空白文字に対しては、警告は表示されません。　　　　　　　　空白文字だから無視されたのではなく、「;」の左側にはどんな文字があっても無視されるのです。（空白もHOGEも同じです） ------------------------ 入力オペレーションモード ------------------------ 起動方法：　　　isd [#<デバイス番号>] ISDへのコマンドを、対話形式で一行づつ指定するモードです。このモードでISDを起動すると、P/ECEに接続後、プロンプトを表示してコマンド待ち受け状態となります。コマンド「q」（終了）を指定するまで、ISDは終了しません。なお、デバイス番号については「プログラム実行モード」と同じですので、説明を省略します。例１：　　　　　isd 　　　　　　　　v 　　　　　　　　= 　　　　　　　　q 　　　　　　　　一行目：「入力オペレーションモード」でISDを起動します。　　　　　　　　二行目：コマンド「v」を指定し、バージョン情報を表示します。　　　　　　　　三行目：コマンド「=」を指定し、ファイル一覧を表示します。　　　　　　　　四行目：コマンド「q」を指定し、ISDを終了します。「引数オペレーションモード」と同じく、「入力オペレーションモード」でも一度に複数のコマンドを指定できます。例２：　　　　　isd 　　　　　　　　v;= 　　　　　　　　d 100000;d 200000 　　　　　　　　q 　　　　　　　　一行目：「入力オペレーションモード」でISDを起動します。　　　　　　　　二行目：バージョン情報を表示し、続けてでファイル一覧を表示します。　　　　　　　　三行目：0x100000番地からの128バイト分をバイナリダンプし、続けて0x200000番地からの128バイト分をバイナリダンプします。　　　　　　　　四行目：コマンド「q」を指定し、ISDを終了します。「引数オペレーションモード」では、コマンドを「"」で囲ってはいけません。次の例は、間違ったコマンド指定の例です。例３：　　　　　isd 　　　　　　　　"v;=" 　　　　　　　　q 　　　　　　　　二行目先頭の「"」に対する警告が表示され、次に「;」が見つかるまでの全ての文字が無視されます。　　　　　　　　従って、コマンド「v」は実行されず、バージョン情報は表示されません。　　　　　　　　「;」の後ろにあるコマンド「=」は実行されます。 ------------------------------------------------------------------------------------------------------------------------------- 次回は、各コマンドの詳細について見ていこうと思います。（続きます…） * Thu Dec 12 06:30:00 JST 2002 Naoyuki Sawa - strtok()に大問題 S1C33 Family Cコンパイラパッケージ（P/ECEの標準Ｃライブラリ）のstrtok()関数には、重大な問題があります。指定した文字列の終端を突き抜けてトークン分割を続けてしまう、というものです。 --------------------------------------------------------------------------------------------------- まず、PC上のCコンパイラを使って、次のプログラムを実行してみましょう。 #include #include #include char s1[] = "a/b/c\0d/e/f"; int main() { 　　　　char* p; 　　　　p = strtok(s1, "/"); 　　　　while(p != NULL) { 　　　　　　　　fprintf(stderr, "(%s)", p); 　　　　　　　　p = strtok(NULL, "/"); 　　　　} 　　　　fprintf(stderr, "\n"); 　　　　return 0; } 文字列s1の中の「/」で区切られた各部分を、順に「(」～「)」で囲って表示するプログラムです。文字列s1は「a/b/c\0d/e/f」ですが、「c」の後ろのヌル文字で終端しているので、「a/b/c」と等価です。従って、結果は次のようになります。「(a)(b)(c)」 --------------------------------------------------------------------------------------------------- では次に、P/ECEで次のプログラムを実行してみましょう。ソースのダウンロードはこちら：　http://www.piece-me.org/archive/strtok1-20021212-src.zip #include #include #include #include unsigned char vbuff[DISP_X * DISP_Y]; /* 仮想VRAM */ char s1[] = "a/b/c\0d/e/f"; void pceAppInit() { 　　　　char* p; 　　　　/* 一般的な初期化 */ 　　　　pceLCDDispStop(); 　　　　pceLCDSetBuffer(vbuff); 　　　　pceLCDDispStart(); /* 画面クリア */ 　　　　memset(vbuff, 0, sizeof vbuff); 　　　　pceFontSetPos(0, 0); 　　　　/*{{この部分が実験コードの本体です*/ 　　　　p = strtok(s1, "/"); 　　　　while(p != NULL) { 　　　　　　　　pceFontPrintf("(%s)", p); 　　　　　　　　p = strtok(NULL, "/"); 　　　　} 　　　　/*}}この部分が実験コードの本体です*/ 　　　　/* 画面転送 */ 　　　　pceLCDTrans(); } void pceAppProc(int count) { /* SELECTボタンが押されたら終了します */ if(pcePadGet() & TRG_SELECT) pceAppReqExit(0); } void pceAppExit() { } 実験内容はPC用のプログラムと同じですので、「(a)(b)(c)」と表示されるはずですが、実際には、「(a)(b)(c)(d)(e)(f)」と表示されてしまいます！ --------------------------------------------------------------------------------------------------- S1C33 Family Cコンパイラパッケージのstrtok()関数は、文字列終端のヌル文字の検出に問題があります。どうやら、ヌル文字が二つ以上連続していた場合にのみ、文字列終端を認識するようです。例えば、先ほどのプログラムで、 char s1[] = "a/b/c\0d/e/f"; を、 char s1[] = "a/b/c\0\0d/e/f"; に変更すると、「(a)(b)(c)」と表示されます。先ほどのプログラムで、表示が「(f)」までで終わっていたのも、たまたま「f」の後ろにヌル文字がいくつか並んでいたためで、もしそうなっていなければ永遠に終わらず、「(a)(b)(c)(d)(e)(f)(ゴミ)(ゴミ)(ゴミ)...」と表示されてしまっていたでしょう。 --------------------------------------------------------------------------------------------------- 結論： S1C33 Family Cコンパイラパッケージのstrtok()関数は、使ってはいけません。回避方法：アプリケーションプログラムの中でstrtok()を実装して、ライブラリ内のstrtok()を置き換えてしまいましょう。 char* strtok(char* s1, const char* s2) { /* find next token in s1[] delimited by s2[] */ 　　　　static char* ssave = ""; /* for safety */ 　　　　char *sbegin, *send; 　　　　sbegin = s1 ? s1 : ssave; 　　　　sbegin += strspn(sbegin, s2); 　　　　if(*sbegin == '\0') { /* end of scan */ 　　　　　　　　ssave = ""; /* for safety */ 　　　　　　　　return NULL; 　　　　} 　　　　send = sbegin + strcspn(sbegin, s2); 　　　　if(*send != '\0') *send++ = '\0'; 　　　　ssave = send; 　　　　return sbegin; } // P.J.プラウガー著「標準Ｃライブラリ ANSI/ISO/JIS C規格」（トッパン） // 初版 467ページ図14.20 strtok.c をそっくりそのまま使わせて頂きました。そういえば、おでマルのソースも標準のstrtok()を使わず、自前のstrtok()関数を用意してそれを使っていました。（\usr\PIECE\app\odemaru\piece_ex.c 56行目～ PIECE_StrTok()関数）標準strtok()関数の問題を回避するためだったのですね。 * Sun Oct 13 10:03:00 JST 2002 Naoyuki Sawa - 64ビット整数演算ライブラリ C言語で64ビット整数演算を行うには「long long」を使います。符号無しの場合は「unsigned long long」です。「long long」型は、1999年に取り決められた新しいC言語規格に含まれている仕様です。 P/ECEのCコンパイラは古いC言語規格に沿って作られていますが、「long long」型は既にサポートされています。それでは、64ビット整数演算を試してみましょう。次のようなプログラムを書いて： void smain() { long long a, b, c; a = 15372468987LL; b = 12345678901LL; c = a + b; } コンパイルすると... test1.o: Warning: Unresolved external symbol '__adddi3'. あれ？リンクエラーになってしまいました。__adddi3という関数が定義されていない、と言っています。そんな関数は呼んだ覚えがないのですが、これはいったいどういうことでしょうか？ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - P/ECEのCPU S1C33209は、64ビット整数演算を行うためのハードウェアを持っていません。 64ビット整数演算は直接アセンブラコードに変換されるのではなく、64ビット整数演算を行う関数の呼び出しに置き換えられます。例えば、先ほどのプログラムの「c = a + b」の部分は、次のようなアセンブラコードにコンパイルされます。 xld.w %r12,[%sp+12] /* (%r13,%r12) に足される数(a)を入れます。 */ xld.w %r13,[%sp+16] xld.w %r14,[%sp+20] /* (%r15,%r14) に足す数(b)を入れます。 */ xld.w %r15,[%sp+24] xcall __adddi3 /* (%r11,%r10) = (%r13,%r12) + (%r15,%r14) を行うサブルーチン */ xld.w [%sp+28],%r10 /* 結果をメモリに書き戻します。 */ xld.w [%sp+32],%r11 ちなみに、関数呼び出しに置き換えられるのは64ビット整数演算に限ったことではなく、浮動小数点演算や32ビット除算なども、実は関数呼び出しに置き換えられているのです。 32ビット除算に関しては、CPUが除算命令を持っていますが、35命令も必要とします。あちこちで32ビット除算を行う場合、その場その場に展開していてはプログラムサイズが非常に大きくなってしまうので、プログラムサイズを小さくするために、まとめて関数呼び出しにしているのですね。浮動小数点演算を行う関数（__addsf3や__divsf3など）は、浮動小数点演算ライブラリとして、\usr\PIECE\lib\fp.lib に入っています。 32ビット除算を行う関数（__divsi3や__modsi3など）は、整数剰余演算ライブラリとして、\usr\PIECE\lib\idiv.lib に入っています。このあたりの説明は、『S1C33 Family Cコンパイラパッケージマニュアル』（\usr\PIECE\docs\datasheet\EPSON\S5U1C33000C_J.pdf）７．エミュレーションライブラリ（93～95ページ）に載っていますので、ご参照ください。 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - それでは、64ビット整数演算を行う関数は、どのライブラリに入っているのでしょうか？・・・入っていません！入っていないのです。 Cコンパイラは確かに「long long」を認識し、64ビット整数演算関数を呼び出すアセンブラコードを生成しているのですが、肝心の64ビット整数演算ライブラリが提供されていません。 P/ECEのCD-ROMに入れ忘れた、というわけではなさそうです。先ほどの資料でも、64ビット整数演算ライブラリについては全く触れられていませんから、どうやら、EPSONさんのCコンパイラパッケージ配布セットにもともと含まれていないようです。 Cコンパイラは対応しているのに、ライブラリが提供されていない、というのはどういうことでしょうか？考えられるのは、Cコンパイラの「long long」対応が不充分で、ライブラリを用意しただけでは正しく使えないため、 64ビット整数演算ライブラリも作ったけど配布しなかった、というケースです。しかしながら、いくつかプログラムを書いて試してみた限りでは、生成されるコードに特に問題があるようには見えませんでした。そこで、64ビット整数演算ライブラリを自前で用意してみることにしました。 64ビット整数演算の関数名は次のとおりです： __negdi2 (%r11,%r10) ← -(%r13,%r12) __adddi3 (%r11,%r10) ← (%r13,%r12) + (%r15,%r14) __subdi3 (%r11,%r10) ← (%r13,%r12) - (%r15,%r14) __muldi3 (%r11,%r10) ← (%r13,%r12) * (%r15,%r14) __divdi3 (%r11,%r10) ← (%r13,%r12) / (%r15,%r14) ※符号付き __udivdi3 (%r11,%r10) ← (%r13,%r12) / (%r15,%r14) ※符号無し __moddi3 (%r11,%r10) ← (%r13,%r12) % (%r15,%r14) ※符号付き __umoddi3 (%r11,%r10) ← (%r13,%r12) % (%r15,%r14) ※符号無しこれらの関数を実装したソースはこちら。テスト用プログラムも含んでいます： http://www.piece-me.org/archive/int64-20021013-src.zip テストプログラムの結果の画面はこうなります： http://www.piece-me.org/int64-20021013.png とりあえず、ちゃんと動いているみたいですね。 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 今回実装した64ビット整数演算ライブラリには、まだ次のような問題点・不安点があります。一部未実装の関数があります -------------------------- 浮動小数点⇔64ビット整数の変換を行うための関数をまだ実装していません。浮動小数点⇔64ビット整数の変換に必要な関数は、__fixsfdi,__fixunssfdi,__floatdisfです。浮動小数点が絡んでくるとちょっと面倒なのと、このような型変換は当面必要ないと考えたので、今回は実装しませんでした。また、なぜか浮動小数点⇔64ビット整数の変換時に__cmpdi2という関数が呼ばれることもあります。関数名から推測すると「long long」同士の比較のようですが、通常の「long long」同士の比較は関数呼び出しに置き換えられず、直接アセンブラコードに展開されているのです。例えば、次のようなプログラムは： void test(long long a, long long b) { if(a > b) return; ... } 直接アセンブラコードに展開されます。__cmpdi2は呼ばれていません。 cmp %r13,%r15 /* 上位32ビットの比較 */ xjrgt __L1 xjrne __L2 cmp %r12,%r14 /* 下位32ビットの比較 */ xjrugt __L1 __L2: ... __L1: ret 予想ですが、たぶん昔は通常の「long long」同士の比較も__cmpdi2の呼び出しに変換されていたのだと思います。その後、Cコンパイラの最適化により、効率の良いコードが生成できるようになって、通常の比較は関数呼び出しではなく、直接アセンブラコードに展開されるようになったのではないでしょうか。浮動小数点⇔64ビット整数の中の比較処理（なぜ型変換に比較が必要なのかよくわかっていないのですが(^^;）は、何らかの理由により（もしかしたら最適化忘れ？）昔の名残で__cmpdi2の呼び出しのままになっているのではないかと思います。 %r4と%r12～%r15が破壊されます ----------------------------- S1C33 Family Cコンパイラの関数呼び出し規約により、関数は%r4～%7・%r12～%r15を破壊してもいいことになっています。今回実装した64ビット整数演算ライブラリも、これらのレジスタを作業用に使うので、呼び出されたときの値を保持しません。たぶんこれで問題ないとは思うのですが、浮動小数点演算ライブラリや整数剰余演算ライブラリ、64ビット整数演算ライブラリは Cコンパイラそのものに深く関わっていますので、もしかしたらCコンパイラはこれらのライブラリ関数に対して、通常の関数とは異なる、特別な関数呼び出し規約を期待しているかもしれません。もしもCコンパイラがこれらの関数に対して“全レジスタが保存されること”を期待していた場合、予期しないレジスタが破壊されてしまうことによって、間違った動作を引き起こす可能性があります。これまで実験したところ問題ないので、たぶん大丈夫だとは思うのですが、『S1C33 Family Cコンパイラパッケージマニュアル』にこの点に関する説明がないため、まだ少し不安です。乗算・除算は遅いです -------------------- 乗算ルーチン（__muldi3）は、古典的な１ビットづつの筆算方式を採っています。 S1C33 CPUの乗算命令を利用して、32ビットづつまとめて計算すれば、もっと高速化できると思います。除算・剰余ルーチン（__divdi3，__moddi3など）は、S1C33 CPUのdiv0s，div1，div2s，div3s命令の動作をそっくりそのまま真似て作りました。これらの命令が32ビットで処理しているところを、単に64ビット分行うように拡張しただけです。 div1命令などがハードウェアで行っている処理をソフトウェアに置き換えましたので、1ビット当たり10倍以上遅くなっています。さらにビット数が2倍ですので、20倍以上。他の処理も考えると、30倍以上は遅くなっていると思います。 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - バグ・高速化方法など、お気付きの点がありましたら、ご一報くだされば幸いです。 64ビット整数演算が実際にどの程度必要なのか？と考えると、あまり力を入れる部分ではないような気もしますが、実用性はともかく、小さなサブルーチンのアセンブラコーディングは楽しいですよね。 * Thu Sep 19 12:30:00 JST 2002 Naoyuki Sawa - calloc()が失敗する ---- 状況 ---- 標準Ｃライブラリには、主に二種類のメモリ割り当て関数があります。 malloc()とcalloc()です。 malloc()が単にメモリを割り当てるだけなのに対し、calloc()は割り当てたメモリのゼロクリアも行ってくれます。プログラム側でゼロクリアを行わなくて済む分calloc()の方が便利なので、malloc()よりもcalloc()の方を好んで使っていたのですが、 P/ECE開発環境のcalloc()（以下、P/ECE版calloc()と呼ぶことにします）にはちょっと落とし穴があることに気付きました。同じサイズのメモリ割り当てで、malloc()を使えば成功するのにcalloc()を使うと失敗することがある、というものです。サンプルプログラムを用意しました。 http://www.piece-me.org/archive/calloc-20020919-src.zip このサンプルプログラムは、16キロバイトのヒープ領域から、五種類の方法で8キロバイトのメモリ割り当てを試行します。五種類の方法は、次のようなものです。１．　calloc(2048, 4) 4バイト×2048個のメモリ割り当て２．　calloc(4, 2048) 2048バイト×4個のメモリ割り当て３．　calloc(8192, 1) 1バイト×8192個のメモリ割り当て４．　calloc(1, 8192) 8192バイト×1個のメモリ割り当て５．　malloc(8192) 8192バイトのメモリ割り当ていずれも結果的には8キロバイトのメモリ割り当てが行われるはずなので、すべて成功するはずです。ところが、サンプルプログラムを実行してみると、３．　calloc(8192, 1) 1バイト×8192個のメモリ割り当てが失敗するのです。それ以外の１，２，４，５は成功します。なぜでしょうか？ ---- 原因 ---- calloc()の引数仕様は、次のとおりです。 void* calloc(size_t num, size_t size); num 要素数 size 各要素のバイト単位での長さ一般的な処理系のcalloc()の実装は、だいたい次のようになっています。 void* calloc(size_t num, size_t size) { int n; void* p; n = num * size; /* 割り当てバイト数を計算 */ p = malloc(n); /* 割り当てを行ってみる */ if(p != NULL) memset(p, 0, n); /* 成功ならゼロクリア */ return p; } ところが、P/ECE版calloc()の実装は、次のようになっているみたいです。 void* calloc(size_t num, size_t size) { int n; void* p; size = size + 3 & ~3; /* 要素サイズを4バイト単位に切り上げ */ n = num * size; /* 割り当てバイト数を計算 */ p = malloc(n); /* 割り当てを行ってみる */ if(p != NULL) memset(p, 0, n); /* 成功ならゼロクリア */ return p; } 割り当てバイト数を計算する前に、要素サイズを4バイト単位に切り上げています。これを踏まえて、先ほどの五種類の割り当て方法でそれぞれ何バイトの割り当てが行われようとしていたのかを考えてみると、１．　calloc(2048, 4) 4バイト×2048個のメモリ割り当て → (4+3&~3) * 2048 = 4 * 2048 = 8192[バイト] ２．　calloc(4, 2048) 2048バイト×4個のメモリ割り当て → (2048+3&~3) * 4 = 2048 * 4 = 8192[バイト] ３．　calloc(8192, 1) 1バイト×8192個のメモリ割り当て → (1+3&~3) * 8192 = 4 * 8192 = 32768[バイト] ４．　calloc(1, 8192) 8192バイト×1個のメモリ割り当て → (8192+3&~1) * 1 = 8192 * 1 = 8192[バイト] ５．　malloc(8192) 8192バイトのメモリ割り当て → 8192[バイト] ３だけが32KBもの割り当てを行おうとしています。ヒープ領域は16KBしか準備していませんから、なるほど失敗するはずです。ヒープ領域が32KB以上あれば成功しますが、24KB分もの領域が無駄になってしまいます。ではなぜP/ECE版calloc()は、わざわざ要素サイズを4バイト単位に切り上げているのでしょうか？確かにcalloc()の仕様では、割り当てられた各要素が適切なバイト境界に配置されるよう、引数sizeによって割り当てサイズを調整しても構わないことになっています。たぶん、int，short，char型のメンバ変数が混在している構造体のための配慮だと思います。 struct TEST { int a; /* +0～3 */ char b; /* +4 */ }; /* =5バイト */ 構造体TESTのサイズは5バイトなので（※実はそうではありません。後述します）、すき間なく並べると、メンバ変数aは5バイトごとに配置されてしまいます。 S1C33 CPUでは、int変数は4バイト境界に配置されていなければいけません。二つ目以降の要素のメンバ変数aは4バイト境界に配置されていないので、読み書きしようとするとアドレスエラーが発生してしまいます。 struct TEST +=========+ +0 | | | int a | | | | | +---------+ +4 | char b | +=========+ +5 <- 二つ目の要素のメンバ変数aにアクセスするとアドレスエラー！ | | | int a | | | | | +---------+ +9 | char b | +=========+ +10 : : アドレスエラーを防ぐには、メンバ変数bの後ろに3バイト分のパディング（詰め物）を追加して、構造体TESTのサイズを4の倍数にする必要があります。 struct TEST +=========+ +0 | | | int a | | | | | +---------+ +4 | char b | +---------+ +5 | | | 詰め物 | | | +=========+ +8 <- ＯＫ！ | | | int a | | | | | +---------+ +12 | char b | +---------+ +13 | | | 詰め物 | | | +=========+ +16 : : P/ECE版calloc()は、このパディングの分のサイズを考慮して、要素サイズを4バイト単位に切り上げているのだと思います。しかしながら実際には、このような配慮は不要です。構造体の各メンバが適切なバイト境界に配置されるようにパディングを追加するのは、ライブラリ関数の役割ではなくＣコンパイラの役割だからです。先ほどの構造体TESTのサイズを調べてみると、 sizeof(struct TEST) → 8 8バイトになっています。構造体TESTの配列を作成した場合に、二つ目以降の要素のメンバ変数aが4バイト境界に配置されるよう、最後に3バイトのパデイングが追加されたからです。単に次のように書くだけで大丈夫です。 calloc(num, sizeof(struct TEST));　←同じ→　calloc(num, 8); というわけで、P/ECE版calloc()の実装は明らかに間違いというわけではありません。適切なバイト境界への配置を心配しすぎたあまり、割り当てサイズが大きくなりすぎてしまっただけです。しかし、1バイト単位のメモリ割り当て（いちばんよく使うパターンです）が常に3倍もの無駄な領域を伴うというのは、ちょっとキビシイところです。 calloc(1000, sizeof(char)) /* 1000文字分のメモリ割り当て。しかし実際には4000文字分！3000文字分は無駄 */ ---- 対策 ---- アプリケーションプログラムの中でcalloc()を実装して、ライブラリ内のcalloc()を置き換えてしまいましょう。 void* calloc(size_t num, size_t size) { int n; void* p; n = num * size; /* 割り当てバイト数を計算 */ p = malloc(n); /* 割り当てを行ってみる */ if(p != NULL) memset(p, 0, n); /* 成功ならゼロクリア */ return p; } * Fri Aug 15 12:30:00 JST 2002 Naoyuki Sawa - Cコンパイラの最適化ミス・レポート P/ECE開発環境のCコンパイラの、最適化ミスによる不具合レポートです。まず、僕が作ろうとした関数「hit_test()」について説明します。この関数の目的は、盤面上に4×4のコマが置けるかどうか？を調べることです。コマを置きたい位置の左上座標を指定して、置けるなら0、置けなければ1を返します。置けない理由としては、次のようなものがあります。・指定された座標を左上原点とする4×4の範囲が、盤面をはみ出している場合。・指定された座標を左上原点とする4×4の範囲に、既にコマが置かれている場合。この関数を使って不具合を再現する、サンプルプログラムを示します。 (プロジェクト一式はこちら: http://www.piece-me.org/archive/forbug-20020815-src.zip) --------------------------------------------------------------------------------------------------- C01| /* C02| * forbug.c C03| * C04| * for()文の最適化バグ再現プログラム C05| * Copyright (C) 2002 Naoyuki Sawa C06| * C07| * * Thu Aug 15 04:30:00 JST 2002 Naoyuki Sawa C08| * - 作成開始。 C09| */ C10| #include C11| C12| /* 最適化コンパイル（問題発生する）： C13| * pcc33 -b -gp=0x0 -near -O2 -Wall forbug.c pat.c C14| * 最適化しないコンパイル（問題発生しない）： C15| * pcc33 -b -gp=0x0 -near -Wall forbug.c pat.c C16| */ C17| C18| /* 16x16マスの盤面定義 C19| * 各位置の要素が、0ならコマが置かれていません。 C20| * 1ならコマが置かれています。 C21| */ C22| #define COLS 16 C23| #define ROWS 16 C24| unsigned char field[COLS][ROWS]; C25| C26| /* (x,y)～(x+3,y+3)の4x4マスの範囲に、既にコマが置かれているかを調べます。 C27| * * (x,y)～(x+3,y+3)の一部でも盤面をはみ出していたら、1を返します。 C28| * (x,y)～(x+3,y+3)の範囲にひとつでもコマが置かれていたら、1を返します。 C29| * * (x,y)～(x+3,y+3)が盤面内で、その範囲にひとつもコマがない場合のみ、0を返します。 C30| */ C31| int C32| hit_test(int x, int y) C33| { C34| int x0, y0; /* 縦横のループカウンタ */ C35| int x1, y1; /* 盤面を走査する座標変数 */ C36| C37| for(y0 = 0, y1 = y; y0 < 4; y0++, y1++) { C38| if(y1 < 0 || ROWS - 1 < y1) { /* 縦はみ出しチェック */ C39| return 1; /* はみ出してたら1を返す */ C40| } C41| for(x0 = 0, x1 = x; x0 < 4; x0++, x1++) { C42| if(x1 < 0 || COLS - 1 < x1) { /* 横はみ出しチェック */ C43| return 1; /* はみ出してたら1を返す */ C44| } C45| if(field[y1][x1]) { /* 既にコマが置かれてるかチェック */ C46| return 1; /* 置かれてたら1を返す */ C47| } C48| } C49| } C50| C51| return 0; C52| } C53| C54| void C55| smain() C56| { C57| int retval; C58| C59| /* (-1,8)～(2,11)の4x4の範囲が盤面内で、ひとつもコマが置かれていないか？ C60| * 明らかに盤面外（左にはみ出している）なので、1が帰るはずなのですが、 C61| * 最適化コンパイルすると0が帰ってきます! C62| */ C63| retval = hit_test(-1, 8); C64| cls(); C65| printnum(retval); C66| while(!pad()) { } C67| } --------------------------------------------------------------------------------------------------- hit_test()関数は、特に複雑な処理を行っているわけではありません。ゲームに限らない、ごく一般的な重なり判定のロジックだと思います。ところが、このソースを「-O2」オプション付きで最適化コンパイルすると、正しい結果が帰ってきません。サンプルプログラムでは、(-1,8)を基準とする4×4の範囲にブロックが置けるかどうかを判定しています。明らかに左側にはみ出ていますので、C42行目の判定に引っかかり、「コマが置けない＝1」が帰ってくるはずです。しかし実際に試してみると、「コマが置ける＝0」が帰ってくるのです。試しに「-O2」オプション無しで最適化しないコンパイルを行ってみると、正しく1が帰ってきます。ということは、どうやらCコンパイラの最適化ミスのようです。そこで、上記hit_test()関数を最適化コンパイルした場合の、アセンブラソースを調べてみました。 --------------------------------------------------------------------------------------------------- A01| /* int hit_test(int x, int y) A02| * [in] A03| * r12 x A04| * r13 y A05| * [out] A06| * r10 result A07| */ A08| .align 1 A09| .global hit_test A10| hit_test: A11| ; .frame %sp,4,$31 # vars= 0, regs= 1/0, args= 0, extra= 0 A12| ; .mask 0x80000000,-4 A13| ; .fmask 0x00000000,0 A14| ld.w %r5,0x0 /* r5 <- 0 (r5が変数y0に対応) */ A15| xld.w %r11,field /* r11 <- &field[0][0] */ A16| ld.w %r10,%r13 /* r10 <- y */ A17| xsll %r10,4 /* r10 <- y * 16 */ A18| add %r10,%r11 /* r10 <- &field[y][0] */ A19| __L5: A20| xcmp %r13,15 /* IF y > 15 THEN L16 */ A21| xjrugt __L16 /* (符号無し比較なので、y<0の場合もこれで判定できます) */ A22| ld.w %r14,0x0 /* r14 <- 0 (r14が変数x0に対応) */ A23| ld.w %r11,%r12 /* r11 <- x */ A24| add %r11,%r10 /* r11 <- &field[y][ x] */ A25| xadd %r4,%r10,15 /* r4 <- &field[y][15] */ A26| __L10: A27| cmp %r11,%r4 /* IF &field[y][x] > &field[y][15] THEN L16 */ A28| xjrugt __L16 /* (※ここが問題！これではx<0の場合を判定できません) */ A29| xld.ub %r15,[%r11] /* r15 <- field[y][x] */ A30| cmp %r15,0x0 /* IF field[y][x] = 0 THEN L9 */ A31| xjreq __L9 A32| __L16: A33| xld.w %r10,0x00000001 /* return 1 */ A34| xjp __L15 A35| __L9: A36| xadd %r14,%r14,1 /* r14 <- r14 + 1 (r14が変数x0に対応) */ A37| xadd %r11,%r11,1 /* r11 <- &field[y][x+1,2,3] (ポインタを右隣へ) */ A38| xcmp %r14,3 /* IF x0 <= 3 THEN L10 */ A39| xjrle __L10 A40| xadd %r5,%r5,1 /* r5 <- r5 + 1 (r5が変数y0に対応) */ A41| xadd %r10,%r10,16 /* r10 <- &field[y+1,2,3][0] (ポインタを下隣へ) */ A42| xadd %r13,%r13,1 /* y <- y + 1 */ A43| xcmp %r5,3 /* IF y0 <= 3 THEN L5 */ A44| xjrle __L5 A45| ld.w %r10,%r15 /* return 0 (r15は必ず0になっています。A30～A31行参照) */ A46| __L15: A47| ret --------------------------------------------------------------------------------------------------- まず注目していただきたい点は、元のCソースの縦方向はみ出し判定ロジック： C38| if(y1 < 0 || ROWS - 1 < y1) { /* 縦はみ出しチェック */ が、次のように最適化されている点です。 A20| xcmp %r13,15 /* IF y > 15 THEN L16 */ A21| xjrugt __L16 /* (符号無し比較なので、y<0の場合もこれで判定できます) */ これは問題ありません。 if((int)y1 < 0 || 15 < (int)y1) { ... } /* 元のCソースのロジック */ と、 if(15 < (unsigned)y1) { ... } /* 最適化されたアセンブラソースのロジック */ は、等価だからです。例えば、「y1 = -1」の場合、元のCソースのロジックでは「-1 < 0」で条件が成立します。 -1は符号無し整数と見なせば0xffffffffなので、アセンブラのロジックでも「15 < 0xffffffff」で成立します。というわけで、縦方向のはみ出し判定には問題ありません。問題は、横方向のはみ出し判定です。元のCソースの横方向はみ出し判定ロジック： C42| if(x1 < 0 || COLS - 1 < x1) { /* 横はみ出しチェック */ が、次のように最適化されている点に注目してください。 A27| cmp %r11,%r4 /* IF &field[y][x] > &field[y][15] THEN L16 */ A28| xjrugt __L16 /* (※ここが問題！これではx<0の場合を判定できません) */ これはダメです！ X座標そのままでの比較ではなく、盤面上へのポインタにした後で、アドレス値を比較するように最適化されています。アドレス値で比較するのは構わないのですが、アドレス比較と先ほどの符号無し比較による最適化の方法は併用できません。例えば「&field[0][0] = 0x110000, x = -1, y = 8」の場合、最適化後のロジックでは次のような判定を行ってしまいます。 IF &field[8][-1] > &field[8][15] THEN L16 アドレス値を展開すると、 IF 0x11007f > 0x11008f THEN L16 本当はL16へ分岐しなければいけないのですが、このロジックでは左側へのはみ出しが判定できません。だからサンプルプログラムの結果が、「コマが置けない＝1」ではなく、「コマが置ける＝0」になってしまうのです。コンパイラの最適化ミスというのは、P/ECEのCコンパイラに限らず、よくあることです。最適化ミスが発生する状況と、回避方法がきちんとわかっていれば、重大な問題にはなりません。が、今回のケースでちょっとキビシイなあ...と感じるのは、あまりにも普通のケースで問題が生じているため、どういう状況で最適化ミスが発生するのか推測できない点。また、問題を発生するコードがそもそも単純ですので、別の方法に置き換えても確実に回避できそうにない点です。 for()のかっこの中に「,」を使ってマルチステートメントを書くのがマズイのかと考えて、次のように書き換えてみました。 --------------------------------------------------------------------------------------------------- /* こう書き換えてもダメな例！ */ int hit_test(int x, int y) { int x0, y0; /* 縦横のループカウンタ */ int x1, y1; /* 盤面を走査する座標変数 */ y1 = y; for(y0 = 0; y0 < 4; y0++) { if(y1 < 0 || ROWS - 1 < y1) { /* 縦はみ出しチェック */ return 1; /* はみ出してたら1を返す */ } x1 = x; for(x0 = 0; x0 < 4; x0++) { if(x1 < 0 || COLS - 1 < x1) { /* 横はみ出しチェック */ return 1; /* はみ出してたら1を返す */ } if(field[y1][x1]) { /* 既にコマが置かれてるかチェック */ return 1; /* 置かれてたら1を返す */ } x1++; } y1++; } return 0; } --------------------------------------------------------------------------------------------------- が、結果は同じ。やっぱり左方向のはみ出し判定に失敗し、「コマが置ける＝0」が帰ってきます。いろいろ試した結果、最適化ミスに失敗しない書き方の一例として、次のようなCソースならOKみたいです： --------------------------------------------------------------------------------------------------- /* 一応、こう書き換えればOKみたい... */ int hit_test(int x, int y) { #define x1 (x + x0) #define y1 (y + y0) int x0, y0; /* 縦横のループカウンタ */ for(y0 = 0; y0 < 4; y0++) { if(y1 < 0 || ROWS - 1 < y1) { /* 縦はみ出しチェック */ return 1; /* はみ出してたら1を返す */ } for(x0 = 0; x0 < 4; x0++) { if(x1 < 0 || COLS - 1 < x1) { /* 横はみ出しチェック */ return 1; /* はみ出してたら1を返す */ } if(field[y1][x1]) { /* 既にコマが置かれてるかチェック */ return 1; /* 置かれてたら1を返す */ } } } return 0; #undef x1 #undef y1 } --------------------------------------------------------------------------------------------------- 一応、正しい結果「コマが置けない＝1」が帰ってきます。しかしこれは、hit_test()関数の場合はたまたま最適化ミスに引っかからなくなったというだけで、根本的な解決にはなっていません。この不具合の確実な回避方法をご存知のかたがおられましたら、ぜひ教えてください。よろしくお願いいたします。さて、今回のレポートで言いたいのは、「P/ECEのCコンパイラはダメ」ということではありません。前述の通り、どんなコンパイラにも多かれ少なかれ最適化ミスはあると思います。 P/ECEの場合に問題なのは、現時点ではCコンパイラの選択肢がなく、付属のCコンパイラを使うしかないことです。また、Cコンパイラに不具合があっても、バージョンアップで修正される見込みがほとんどないことです。もしかしたらEPSONさんは新しいバージョンのCコンパイラを配布しているのかも知れませんが、エンドユーザーがCコンパイラだけを入手するのはかなり困難だと思われます。なければ作るしかありません。新しいgccをS1C33 CPU用に移植…気が遠くなりそうですが、実際に他のCPU用に移植なさっているユーザーさんも大勢いらっしゃいますので、不可能ではないはず。また壮大な目標ができてしまいました。組み込みCPUの勉強・USBの勉強・電子回路の勉強の後はコンパイラの移植…やること目白押しです(^^; * Fri Jul 19 05:00:00 JST 2002 Naoyuki Sawa - コピーするのは instdef.c だけ自作プログラムに音楽ライブラリを組み込む場合、P/ECE開発環境のフォルダからプログラム作成用のフォルダへ、いくつかのファイルをコピーしなければいけません。おさんぽ綾香のチュートリアルでは、次のように指示されています。綾香の画像ファイルがあるフォルダ（標準ではc:\usr\piece\docs\tutorial\ayaka）に「wavetbl」というフォルダがありますので、その中身の「wavetbl.c」と「sndフォルダ」を貴方の作業フォルダ（ayaka）にコピーしてください。（C:\usr\PIECE\HTML\tutorial_f.htm 【綾香が歩くプログラムに音楽を追加する】より）また、P/ECE Hand Bookでは、次のように指示されています。 sysdev\music\makefile sysdev\music\wavetable.c sysdev\music\instdef.c sysdev\music\musdef.h sysdev\music\wave\*.* （P/ECE Hand Book 『開発Tips』音楽を演奏したい (p.098) より）僕は記憶力がよくないので、二つ以上のファイル名は覚えてられません(^^; 音楽ライブラリを使った練習プログラムを作るたびに、これらの資料を読み返してコピーするファイルを調べていました。毎回同じファイルをコピーしなければいけないのなら、なぜライブラリに入れておいてくれなかったのでしょうか？・・・実は入っていました。自作プログラムに音楽ライブラリを組み込ために、P/ECE開発環境からコピーする必要があるファイルは、 sysdev\music\instdef.c これひとつだけです。 instdef.cだけをコピーしたサンプルプログラム、ソースはこちら： http://www.piece-me.org/archive/musprg1-20020719-src.zip instdef.cの中には、音色テーブルだけが定義されています。 INST *inst[] = { ... }; 音色テーブルは小さいので、instdef.cファイル自体をコピーしなくても、アプリケーションプログラムのソースの中に instdef.cの内容だけをカット＆ペーストしてしまっても良いと思います。音色データ本体はmuslib.libの中にあり、音色テーブルから参照されている音色データだけが、実際にリンクされます。さて、instdef.cの音色テーブルは全ての音色への参照を含んでいますので、instdef.cの内容をそのまま使うと、 muslib.libの中にある全ての音色データがリンクされてしまいます。アプリケーションの曲データが使っていない音色データをリンクすると、プログラムが無駄に大きくなってしまいます。不要な音色を削除してプログラムを小さくする方法が、"P/ECE" Official WebPage 開発者掲示板に載っています。参照記事はこちら： http://www.piece-me.com/kyview/article/d/devpiece/8/opcilm/index.html 音色テーブルを編集して、不要な音色への参照を削除してしまいましょう。不要な音色をリンクしないサンプルプログラム、ソースはこちら： http://www.piece-me.org/archive/musprg2-20020719-src.zip 先ほどのプログラムはSRFファイルサイズが48KBぐらいありましたが、音色を減らすと8KB程度に小さくなりました。 * Mon Jul 15 21:23:00 JST 2002 Naoyuki Sawa - 1.25の1乗はゼロ？ "P/ECE" Official WebPage 開発者掲示板にて質問させて頂いた件の備忘録です。元記事はこちら。 http://www.piece-me.com/kyview/article/d/devpiece/10/kaxilm/index.html ご回答くださった、１６びっとさん(http://www.interq.or.jp/www-user/wanderer/)に感謝いたします。「S1C33 Family Cコンパイラパッケージ」のpow()関数は、ちょっと不具合があるようです。特定の状況で、ぜんぜん間違った値(ゼロ)を返すことがあります。微妙なコーディングの違いで、症状が発生したりしなかったりするようで、原因不明です。再現プログラムはこちら： http://www.piece-me.org/archive/powtest-src.zip "P/ECE" Official WebPage 開発者掲示板にてアドバイス頂いた回避方法は次のとおりです。 pow()を直接呼ぶのではなく、pow()を呼び出すだけの単純な関数pow_wrap()を経由させます。つまり、 fn() { ... c = pow(a, b); ... } の部分を、 double pow_wrap(double x, double y) { return pow(x, y); } fn() { ... c = pow_wrap(a, b); ... } に変更するのです。なぜこれで治るのかさっぱりわかりませんが…(^^; 回避方法サンプルプログラムはこちら： http://www.piece-me.org/archive/powtest2-src.zip 現在のところこの方法で回避できていますが、原因不明なだけに不気味です。 pow()へのパラメータの取り得る範囲が予測できず、取り得るパラメータの範囲に対して充分なテストができないケースでは、なるべくpow()は使わない方が良さそうです。追記：もう一つの回避方法「pow(x, y)」は「exp(log(x) * (y)」に展開できるそうです。（Webで“べき乗”について調べました）もしも、pow()関数単体に問題があるのならば、pow()関数を使わなければ問題を回避できるはずです。そこで、#include の直後で次のように定義して、pow()を置き換えてしまいます。 #include #define pow(x,y) (exp(log(x) * (y))) /* pow()を使わないべき乗の計算 */ サンプルプログラムはこちら： http://www.piece-me.org/archive/powtest3-src.zip この方法でも問題回避できることを確認しましたが、関数呼び出しが増えるため、前述の回避方法よりもかなり実行速度が遅くなってしまいます。速度が要求される場面では、前述の回避方法を使った方がいいと思います。ところで、リンカの生成するマップファイルから、pow()関数のサイズを調べたところ、かなり大きいです。次のような、単純な実装ではないようです。 double pow(double x, double y) { return exp(log(x) * y); } たぶん高速化のため、複雑に最適化された実装になっているのだと思います。そこに、問題発生の原因があるのではないでしょうか？ * Sat Jul 6 22:38:00 JST 2002 Naoyuki Sawa - PCEWAVEINFOは開放されない昨年12月25日の研究記録「PCEWAVEINFOはauto変数にしてはいけない」で、 pceWaveDataOut()に渡すPCEWAVEINFO構造体は、auto変数にしてはいけない理由を調べました。 pceWaveDataOut()は再生終了時に、PCEWAVEINFO構造体のstatメンバにPW_STAT_ENDを書き込むので、 pceWaveDataOut()に渡したPCEWAVEINFO構造体のメモリ領域を別の用途に再利用したりしていると、その領域にPW_STAT_ENDが書き込まれて、データが壊れてしまう、という理由でした。その後、BIOS 1.14から1.18へのアップグレード時に、この問題は修正されました。 BIOS 1.18の更新内容（http://www.piece-me.com/dl/update118.html）には、次のような記述があります。 ●バグフィックス・Wave再生で解放済みのバッファに書き込むバグ修正また、カーネルソース（c:\usr\piece\sysdev\pcekn\snd.c）にも、次のようなコメントがあります。 v1.16 2002.01.05 MIO.H 解放済みのバッファに書き込むバグ修正そして実際に、カーネルソースも修正されているようです。（snd.cの286行目と349行目） //newp->stat = PW_STAT_START; 要らない //wp->pwiee->stat = PW_STAT_END; 要らないこのように、PCEWAVEINFO構造体の開放問題が修正されたことは知っていたのですが、ちかごろは、効果音付きのプログラムは全部シンプルライブラリで組んでいたので、本当にPCEWAVEINFO構造体をauto変数にしてpceWaveDataOut()が使えるのかどうか、実験していませんでした。先日から、久しぶりにコアAPIを使ってプログラムを組んでいます。で、PCEWAVEINFO構造体をauto変数にしてpceWaveDataOut()を使ってみました。・・・やっぱり落ちます・・・なぜ？カーネルソースを見る限り、問題のか所は修正されているようですが… 原因は、statメンバへの「書込み」ではなく、pfEndProcメンバの「参照」にありました。 PCEWAVEINFOのpfEndProcに関数アドレスを指定しておくと、WAVEデータが再生終了したときに関数がコールバックされます。 pfEndProcがNULLなら、コールバックは行われません。いずれにせよ、サウンドドライバはどこかにpfEndProcの内容を保存しておかなければいけません。ところが現在(1.18)の実装では、再生終了時に、pceWaveDataOut()に渡されたポインタを経由してpfEndProcの内容を参照してしまっています。具体的には、pceWaveDataOut()に渡されたポインタが、WAVEPLAY.pwi00にそのまま保存され(snd.c:setpwi())、再生終了時にWAVEPLAY.pwieeに移され(snd.c:make_xwave())、このpwieeを経由してpfEndProcが参照されます(snd.c:make_xwave())。 pceWaveDataOut()に渡されたポインタの指す先のPCEWAVEINFO構造体は既に開放されていることになっているので、 pfEndProcメンバのメモリ領域もアプリケーションによって別の用途に再利用され、内容は変わっているはずです。その結果、関数アドレスじゃないデータを関数アドレスとして取得してしまい、でたらめなアドレスへの関数呼び出しを行ってしまい、TRAPが発生するのです。これは、auto変数の件とは別の問題です。たとえPCEWAVEINFO構造体をグローバル変数やスタティック変数にしていても、再生終了するまではPCEWAVEINFO構造体の内容をうかつに変更できません。再生中のPCEWAVEINFO（本当ならばPCEWAVEINFOは即座に開放されるはずなので、“再生中のPCEWAVEINFO”という概念自体ありえないのですが…）のpfEndProcメンバを書き換えてしまうと、pceWaveDataOut()を呼んだときのpfEndProcではなく、書き換えた後のpfEndProcに従ってコールバックが行われてしまうのです。実験プログラムを作成してみました。バイナリ： http://www.piece-me.org/archive/endproc-20020706-bin.zip ソース　： http://www.piece-me.org/archive/endproc-20020706-src.zip ・PCEWAVEINFO構造体はグローバル変数にしてあります。・Ａボタンを押すと、表示メッセージを「再生中です」に設定した後、１秒程度の効果音を再生開始します。　PCEWAVEINFO.pfEndProc=NULLにしてありますので、再生終了時にはコールバックは行われず、何も起こりません。　再生終了しても、表示メッセージは「再生中です」のままです。・Ｂボタンを押すと、PCEWAVEINFO.pfEndProcに関数アドレスを設定します。　その関数では、表示メッセージを「再生終了しました」に変更します。・Ａボタンを押して効果音が再生されているあいだに、Ｂボタンを押してpfEndProcを設定してみてください。　再生終了時に、表示メッセージが「再生終了しました」に変わります。　pceWaveDataOut()を呼んだ後のPCEWAVEINFO.pfEndProcへの変更が、反映されてしまうことが確認できます。回避方法は、次のとおりです。・PCEWAVEINFO構造体はグローバル変数またはスタティック変数にする。　以前のauto変数の件とは別問題ですが、再生終了時までpfEndProcの内容を保持しなければいけないので、　やはりauto変数にすることはできません。・再生終了まで、PCEWAVEINFOの内容を書き換えてはいけない。　PCEWAVEINFO構造体がグローバル変数またはスタティック変数なので、毎回使いまわすことになりますが、　新しいWAVE情報のセットアップ前に前回の再生が完了していなければいけません。・再生完了待ちを行わない場合は、pceWaveAbort()で確実に再生停止してから、PCEWAVEINFOの内容を書き換えます。　 PCEWAVEINFOのセットアップ→pceWaveAbort()→pceWaveDataOut() /* 悪い例 */ 　という順ではダメです！　 pceWaveAbort()→PCEWAVEINFOのセットアップ→pceWaveDataOut() /* 良い例 */ 　という手順で行わなければいけません。 * Sat Jul 6 22:38:00 JST 2002 Naoyuki Sawa - 音色ベンチマーク#2 今回は、リファレンスの記述に反して「高速」音色が通常の音色よりも速い原因を調べる予定でした。しかし、実際に音色処理を行っている c:\usr\piece\sysdev\music\musfast.s を少し見てみたところ、「高速」音色の方が速いのは調べるまでもなく一目瞭然です。どうやら、「高速」音色の方が遅い、というのは、リファンレンスの単純な書き間違いだったようです。というわけで、音色ベンチマークの話題はここまでにして、今回は別の話題を取り上げてみたいと思います。上の記事へどうぞ。 * Fri Jul 5 00:00:00 JST 2002 Naoyuki Sawa - 音色ベンチマーク#1 「P/ECE Hand Book」の『初心者のためのアプリケーション講座・P/ECEで音楽を楽しもう！』を読んで、 MMLの使い方を勉強中です。 P/ECE開発環境の音楽ライブラリマニュアルでは理解しづらかった点も、わかりやすく解説されています。特に、リズムパートの解説が秀逸！これまで「!!」や「?」の意味がよくわからず、どこかに書いてある説明を見落としてるのかな…と思っていました。この記事では「!!」や「?」などの謎な表記法は使わず、「F =1」も使わずに、リズムパートを記述しています。リズム音色も他の音色と同じように扱う。気付いてみれば簡単なことだったのですが、目から鱗です。僕は、音楽はぜんぜんダメ（MSXの音楽環境「MuSICA」をちょっとかじっただけ）なのですが、この機会にもう一度チャレンジしてみようかな、という気になってきてます。と言った傍から、音楽そのものを離れて細かい話に入って行くのですが(^^; 『P/ECEで音楽を楽しもう！』の記事の音色に関する説明には、次のような記述があります。名前に「高速」が付く音色の方が処理が重いので、処理を軽くするためには「高速」が付かない音色を使った方がいい（086ページあたりの要約）つまり、音色@0,@1,@2を使うとゲームが遅くなるので、@3,@4,@5を使え、ということですね。 P/ECE開発環境の音楽ライブラリマニュアルにも、同様の記述があります。しかし、ちょっと待ってください。「高速」音色の方が「低速」？何となく直感に反します。というわけで、確かめてみることにしました。同じ曲で、音色だけを変えたデータを、6つの音色分用意します。それらの曲をBGMに流しながら、プログラムで1000万回空ループを回して、所要時間を計ります。空ループが回っている間はpceAppProc()を抜けませんので、音楽ライブラリの処理の重さが直接影響するはずです。実験プログラムはこちら：バイナリ　http://www.piece-me.org/archive/musbench-20020705-bin.zip ソース　　http://www.piece-me.org/archive/musbench-20020705-src.zip 上下カーソルで曲を変更し、Aボタンで計測開始を開始します。計測終了したら、所要時間が表示されます。結果は次のようになりました。＋－－－－－－－－－－－－－＋－－－－＋｜　　　　　ＢＧＭ　　　　　｜所要時間｜＋－－－－－－－－－－－－－＋－－－－＋｜音楽なし　　　　　　　　　｜10.158秒｜｜音色０の曲：矩形波(高速)　｜13.741秒｜｜音色１の曲：のこぎり(高速)｜14.616秒｜｜音色２の曲：三角波(高速)　｜14.976秒｜｜音色３の曲：矩形波　　　　｜26.240秒｜｜音色４の曲：のこぎり　　　｜26.241秒｜｜音色５の曲：三角波　　　　｜26.245秒｜＋－－－－－－－－－－－－－＋－－－－＋所要時間が少ないほど、処理が軽いことを示します。 1000万回の空ループの処理は変化しないので、所要時間の差は音楽ライブラリの処理時間の差。音色以外の曲データは同じですので、すなわち、音色の処理の重さの差ということになります。結果を見ると、名前に「高速」が付く音色の方が圧倒的に処理が軽い＝「高速」です。「高速」音色の方が「高速」という、納得のいく結果が得られました。なぜ、音色によってこんなにも処理の重さが違ってくるのでしょうか？（続きます…） * Fri Jun 17 00:00:00 JST 2002 Naoyuki Sawa - zlibを使う#3 （…前回からの続き）前々回の「zlibを使う#1」で、こんなことを書きました。 | pceZlibExpand()をコピー： | pceZlibExpand()のソースをアプリケションプログラムにコピーして使う、という手はどうでしょうか。 | 可能だとは思うのですが、僕は断念しました。 | pceZlibExpand()はpexファイルの展開に特化していて、ちょっと特殊なメモリ割り当て状況を前提として作られているようです。 pceZlibExpand()の使用はあきらめて、前回「zlibを使う#2」で、オリジナルのzlibライブラリを使ってみました。しかし実は、zlibライブラリをそのまま使う方法には、ちょっと問題があったのです。 zlibの展開ルーチンを使うには、１５～３５KB程度の作業領域が必要最近のPCは数百MBものRAMを持っているので、この程度のメモリ消費は問題にならないのですが、 P/ECEは元々256KBしかRAMを持っていないので、35KBものメモリ消費はかなりきびしいです。 pceZlibExpand()はRAMが少ない環境に特化したつくりになっていて、メモリ消費はかなり小さく抑えられているみたいです。できればpceZlibExpand()を使いたいところなのですが、どうも使い方がよくわからない… と思っていたところ、「ぱずるのP/ECE (http://www.marchen.to/~piece/)」のまかべひろしさんから、アプリケーションプログラムにpceZlibExpand()を組み込む方法について、サンプルプログラム等の情報を頂きました。さっそく組み込んでみたところ、確かにpceZlibExpand()を使うことができました。まかべさん、ありがとうございました。というわけで、自作プログラムの展開ルーチンは、zlibライブラリからpceZlibExpand()へ切り替えることにしました。 pceZlibExpand()の組み込み方については、６月２８日発売の「P/ECE Hand Book」をご覧下さい。（なんていいタイミング…） zlibライブラリの方も、もうちょっとだけ使い込んでみようと思います。 * Fri Jun 15 22:00:00 JST 2002 Naoyuki Sawa - zlibを使う#2 （…前回からの続き） P/ECE用zlibライブラリを作りましょう。手順は次の通り。 zlibのソース一式をダウンロードします ------------------------------------ zlibの本家サイト「zlib Home Page」から、zlibのソース一式をダウンロードします。 http://www.gzip.org/zlib/ zlibのソース一式は、いくつかのミラーサイトからダウンロードすることができます。僕は、こちらのミラーサイトを利用させてもらいました。 http://www.libpng.org/pub/png/src/zlib-1.1.4.tar.gz ソース一式を展開します ---------------------- ダウンロードしたファイルを展開してください。「zlib-1.1.4」という名前のフォルダができて、その中にソース一式が展開されます。 P/ECE用Makefileを用意します --------------------------- zlib-1.1.4フォルダの中には既にMakefileがありますが、P/ECE開発環境ではそのまま使うことができません。コンパイラオプションやライブラリ構築用のコマンドなどが、P/ECE開発環境とは違っているからです。修正するよりも、書き直した方が早そうです。というわけで、書き直してみたのがこちら：（前回、紹介したのと同じものです） http://www.piece-me.org/archive/zlib-1.1.4-piece.mk ダウンロードしたら、ファイル名を「Makefile」に変更してください。そして、zlib-1.1.4フォルダの中のMakefileに、上書きコピーしてください。コンパイルします ---------------- コマンドプロンプトを開き、zlib-1.1.4フォルダの中へ移動して、「make」とタイプしてください。しばらく待って、「Librarian Completed」というメッセージが出たら、コンパイル完了です。必要なファイルだけ取り出します ------------------------------ zlib-1.1.4フォルダの中には、たくさんのファイルがありますが、アプリケーションからzlibライブラリを使うために、これらが全て必要なわけではありません。必要なファイルは、次の三つだけです： zlib.h … 最初からあります。 zutil.h … 最初からあります。 libz.lib … さっきコンパイルしてできたライブラリがこれです。他のファイルは今のところ必要ないので、消してしまっても大丈夫です。それでは、zlibライブラリ使って、圧縮された画像ファイルを展開し、画面に表示してみます。サンプルプログラムはこちら： http://www.piece-me.org/archive/zapp-20020615-src.zip （続きます…） * Fri Jun 14 22:20:00 JST 2002 Naoyuki Sawa - zlibを使う#1 P/ECEの実行ファイル(以下、pexファイルと呼びます)は、フラッシュメモリの容量を節約するために、zlibで圧縮してあります。通常のpexファイル作成手順では、コンパイル・リンクしてできたファイル(*.srf)、タイトル文字、アイコンデータ(*.pid)を、 ppack.exeを使ってまとめて、pexファイルに変換します。このとき、srfファイルの部分が、zlibによって圧縮されます。 pexファイルが圧縮されているので、P/ECE上で実行するためには、これを展開しなければいけません。 P/ECEカーネルには、pexファイルを展開するための関数「pceZlibExpand()」が用意されています。(inflate.c) 残念ながら、アプリケーションプログラムからpceZlibExpand()を呼び出すことはできません。もしアプリケーションからもpceZlibExpand()のような圧縮ファイル展開APIが使えたなら、役に立つ場面はかなりあると思います。例えば、グラフィックデータや音楽データをプログラムといっしょにコンパイル・リンクせず、独立した別ファイル(*.pgd,*.pmd)にしたり、まとめてファイルパック形式(*.fpk)にすることがあります。プログラムとデータを分けると、場面・場面で必要なデータだけをロードできるので、たくさんのデータを使うことができます。しかしこの方法では、データファイルにはppack.exeによる圧縮がかからないので、全てpexファイルに詰め込んだ場合に較べて、フラッシュメモリ容量ををたくさん消費する、という欠点があります。もし圧縮ファイル展開APIが使えたなら、データファイルも圧縮しておいて、必要な部分だけを展開しながらロードすることで、フラッシュメモリ容量を節約できるはずです。前述の通り、現状ではアプリケーションプログラムからpceZlibExpand()を呼ぶことができないので、自前で用意しましょう。いくつか、方法があります。おでマル圧縮を使う：おでマルは、非常にたくさんのグラフィックデータを使うために、データファイル(odemaru.grp)を圧縮して持っています。圧縮してもP/ECEのフラッシュメモリ容量ぎりぎりですが… おでマルのデータファイルは、pexファイルの圧縮に使われているzlibとは違う、独自の方法で圧縮されています。展開プログラムは、おでマルのソースファイルに含まれているので、これをコピーして使うことができそうです。が、残念ながら、圧縮プログラムがありません。よって、この方法は却下です。 pceZlibExpand()をコピー： pceZlibExpand()のソースをアプリケションプログラムにコピーして使う、という手はどうでしょうか。可能だとは思うのですが、僕は断念しました。 pceZlibExpand()はpexファイルの展開に特化していて、ちょっと特殊なメモリ割り当て状況を前提として作られているようです。 zlibを使う：というわけで、今回はzlibの勉強も兼ねて、オリジナルのzlibソースからP/ECE用zlibライブラリを構築してみることにしました。これまで、zlibを使ったアプリケーション(gzipやunzipなどの圧縮・展開ツール、png画像形式など)はいろいろ使ってきましたが、 zlibライブラリそのものをプログラムから直接利用したことはなかったので、いい機会です。 P/ECE用zlibライブラリを構築する、といっても、特に難しい点はありませんでした。ソース一式をダウンロードして、P/ECE用のMakefileを書いただけです。プログラム修正などの移植作業は、一切必要ありませんでした。 P/ECE用zlibライブラリ構築用のMakefileはこちら http://www.piece-me.org/archive/zlib-1.1.4-piece.mk 詳しくは次回に。（続きます…） * Wed Jun 12 21:30:00 JST 2002 Naoyuki Sawa - S1C3320８(#2) （…前回からの続き）「S1C33208」と「S1C33209」の特徴を、データシートで比較してみました。＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜　　　　　　　　　　　　　　　　　　｜　　　　　　　　　　　　　　　　Ｓ１Ｃ３３２０８　　　　　　　　　　　　　　　　　｜　　　　　　　　　　　　　　　　　　Ｓ１Ｃ３３２０９　　　　　　　　　　　　　　　　　　｜＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＋｜ＣＭＯＳ　ＬＳＩ　３２ビット並列処理｜Ｓ１Ｃ３３０００（＝Ｅ０Ｃ３３０００）ＲＩＳＣコア　　　　　　　　　　　　　　　　｜←　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜メインクロック　　　　　　　　　　　｜６０ＭＨｚ（Ｍａｘ．、外部クロック入力　１５ＭＨｚ　　　　　　　　　　　　　　　　｜←　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜サブクロック　　　　　　　　　　　　｜３２．７６８ｋＨｚ（Ｔｙｐ．）　水晶発信　　　　　　　　　　　　　　　　　　　　　｜←　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜命令セット　　　　　　　　　　　　　｜１６ビット固定長、直交性の良い１０５種類の命令　　　　　　　　　　　　　　　　　　｜←　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜｜　　　　　　　　　　　　　　　　　　｜積和演算命令（ＭＡＣ命令　２サイクル実行）　　　　　　　　　　　　　　　　　　　　｜　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜内蔵ＲＡＭ容量　　　　　　　　　　　｜８，１９２バイト　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜←　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜クロックタイマ　　　　　　　　　　　｜１ｃｈ．　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜←　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜プログラマブルタイマ　　　　　　　　｜８ビット×４ｃｈ．、１６ビット×６ｃｈ．　　　　　　　　　　　　　　　　　　　　　｜８ビット×６ｃｈ．、１６ビット×６ｃｈ．　　　　　　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜ＰＷＭタイマ　　　　　　　　　　　　｜１６ビットプログラマブルタイマにより実現　　　　　　　　　　　　　　　　　　　　　｜（記載無し）　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜ウォッチドッグタイマ　　　　　　　　｜１６ビットプログラマブルタイマにより実現　　　　　　　　　　　　　　　　　　　　　｜←　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜シリアルインターフェース　　　　　　｜２ｃｈ．　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜４ｃｈ．　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜｜　　　　　　　　　　　　　　　　　　｜クロック同期式・調歩同期式を選択可能　　　　　　　　　　　　　　　　　　　　　　　｜クロック同期式・調歩同期式を選択可能　　　　　　　　　　　　　　　　　　　　　　　　　　｜｜　　　　　　　　　　　　　　　　　　｜赤外線（ＩｒＤＡ）インターフェイスとしても使用可能　　　　　　　　　　　　　　　　｜赤外線（ＩｒＤＡ）インターフェイスとしても使用可能　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜１０ビットＡ／Ｄ変換器　　　　　　　｜逐次比較方式　入力８ｃｈ．　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜←　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜高速ＤＭＡ　　　　　　　　　　　　　｜４ｃｈ．　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜←　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜インテリジェントＤＭＡ　　　　　　　｜１２８ｃｈ．　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜←　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜汎用入出力ポート　　　　　　　　　　｜入力１３ビット、出力２９ビット　　　　　　　　　　　　　　　　　　　　　　　　　　｜←　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜割り込みコントローラ　　　　　　　　｜外部割込み：１０種類　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜←　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜｜　　　　　　　　　　　　　　　　　　｜内部割込み：２９種類　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜外部バスインターフェース　　　　　　｜アドレス２４ビット、データ１６ビット、チップイネーブル７本　　　　　　　　　　　　｜←　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜｜　　　　　　　　　　　　　　　　　　｜ＤＲＡＭ、バーストＲＯＭ直結可能　　　　　　　　　　　　　　　　　　　　　　　　　｜　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜出荷形態　　　　　　　　　　　　　　｜ＱＦＰ５－１２８ｐｉｎ／ＱＦＰ１５－１２８ｐｉｎ　　　　　　　　　　　　　　　　　｜←　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜電源電圧　　　　　　　　　　　　　　｜内部動作電圧：１．８～３．６Ｖ　　　　　　　　　　　　　　　　　　　　　　　　　　｜←　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜｜　　　　　　　　　　　　　　　　　　｜Ｉ／Ｏ電圧　：１．８～５．５Ｖ　　　　　　　　　　　　　　　　　　　　　　　　　　｜　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋｜消費電流　　　　　　　　　　　　　　｜ＨＡＬＴ時：２７μＡ（３．３Ｖ、３２．７６８ｋＨｚ　クロックタイマ動作　Ｔｙｐ．）｜ＳＬＥＥＰ時：１０μＡ　　（３．３Ｖ、３２．７６８ｋＨｚ　クロックタイマ動作　Ｔｙｐ．）｜｜　　　　　　　　　　　　　　　　　　｜　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜　　　　　　：２．５μＡ　（２．０Ｖ、３２．７６８ｋＨｚ　クロックタイマ動作　Ｔｙｐ．）｜｜　　　　　　　　　　　　　　　　　　｜通常動作時：６５ｍＡ（３．３Ｖ、５０ＭＨｚ　Ｔｙｐ．）　　　　　　　　　　　　　　｜通常動作時　：６５ｍＡ　　（３．３Ｖ、５０ＭＨｚ　Ｔｙｐ．）　　　　　　　　　　　　　　｜＋－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋ご覧の通りほとんど同じですが、いくつか違っている項目もあります。これらの項目が、S1C33208からS1C33209への変更点なのでしょうか？・PWMタイマ　S1C33208のデータシートには記載があるのに、S1C33209のデータシートには記載がありませんでした。　しかしこれは単に、S1C33209データートの記載漏れ（または単に“特徴”から外しただけ）だと思います。　現にP/ECEは、16ビットプログラマブルタイマを使って、PWM方式のサウンド出力を行っています。　というわけで、PWMタイマに関しては、S1C33208とS1C33209は同じと考えていいと思います。・消費電流　通常動作時の消費電流は同じですが、省電力モードの消費電流の記載が異なっています。　S1C33208はHALT時（ちょっと省電力なモード）、S1C33209はSLEEP時（すごく省電力なモード）の値なので、単純に比較できません。　S1C33209のデータシートには様々な条件でのHALT時の消費電流も載っているので、比較は可能だと思うのですが、知識不足でよくわかりませんでした。　僕にはまだ、消費電流を気にするほどのハード知識がないので、この話題はまたいずれ興味が出たときに取り上げることにします。・プログラマブルタイマ　8ビットタイマが増設され、S1C33208の4チャネルから、S1C33209では6チャネルになりました。　新しく追加されたのは、Ch.4とCh.5です。　S1C33209データシートのI/Oポートアドレス表を見ると、Ch.0～3の設定用I/Oポートは並んで集まっているのに、　Ch.4～5設定用I/Oポートだけが離れたところにあったりするのは、後から追加されたからだったのですね。　さて、「P/ECE研究室～S1C33分室 8ビットプログラマブルタイマ」の回： http://www.piece-me.org/piece-lab/s1c33/20020115.html 　でも取り上げましたように、Ch.4～5は、Ch.0～3に較べて、ちょっと機能が限定されています。　端子へのクロック出力や、タイマ割り込みの発生源として利用できない（または利用しづらい）のです。　Ch.4～5を追加した目的は何だったのでしょうか？それは… ・シリアルインターフェース　シリアルインターフェースが増設され、S1C33208の2チャネルから、S1C33209では4チャネルに倍増しました。　なるほど、計測機器をつないだりする場合、2チャネルではちょっとこころもとない。　4チャネル欲しい、という要望があったのかも知れません。　新しく追加されたのはCh.2とCh.3で、既存のCh.0～1と同じ機能を備えています。　シリアルインターフェースを使うには、どこからかクロックを供給しなければいけません。　内部クロックを使う場合、シリアルインターフェースCh.0は8ビットタイマCh.2から。　シリアルインターフェースCh.1は8ビットタイマCh.3から、クロック供給を得ます。　8ビットタイマCh.0とCh.1は既に用途が決まっています（DRAMリフレッシュ、A/D変換開始トリガ、OSC3の発信安定待ち時間など）ので、　8ビットタイマCh.0～1を使ってシリアルインターフェースCh.2～3にクロックを供給することはできません。　また、16ビットタイマは汎用的なつくりなので、シリアルインターフェースへのクロック供給のような専用的な用途には不向きのようです。　そこで、シリアルインターフェースCh.2～3へのクロック供給のために、8ビットタイマにもCh.4～5が追加されたのだと思います。　この用途に特化しているので、他の既存の8ビットタイマCh.0～3よりも機能が限定されているのですね。結論。S1C33208からS1C33209への変更点：「シリアルインターフェースが、２チャネルから４チャネルに増えました。」（増えたチャネルのために、８ビットタイマも２チャネル追加されました。） * Tue Jun 11 21:00:00 JST 2002 Naoyuki Sawa - S1C3320８(#1) P/ECEのCPU「S1C33209」の周辺回路を直接操作する実験プログラムを作成するために、 I/Oポートアドレス定義ファイル「c33208.h」を使ってきました。この定義ファイル、名前からもわかるように、S1C33209用ではありません。同じS1C33シリーズのCPUですが、S1C33209よりも旧いモデル「S1C33208」用の定義ファイルです。 c33208.hの内容と、S1C33209のデータシートを見較べたところ、両者の内容の大部分は合っています。しかし一部、データシートには載っているのに、c33208.hには定義されていないI/Oポートもあります。 S1C33209がS1C33208のマイナーアップグレード版であることはたぶん間違いないのですが、具体的にどこが変わったか？に関する資料が、これまで見つけられませんでした。というのも、本家EPSONのデータシート置き場：トップページ http://www.epsondevice.com/domcfg.nsf -> ドキュメント http://www.epsondevice.com/www/jp/doc.nsf -> 32-bitマイクロコンピュータ (S1C33 Family) http://www.epsondevice.com/www/PDFS/epdoc.nsf/selectView?OpenForm&32mcu (2002/06/11現在) には、既にS1C33208に関する資料はなく、Webを検索してみても、ほとんど資料が見つからないのです。 c33208.hの中のコメントから推察するに、S1C33208が登場したのはたぶん1999年頃だったと思われます。また、こちらのロードマップ： http://www.epson-esec2002.com/prdct/MCU.html (2002/06/11現在) によると、S1C33209の登場は2001年です。（P/ECEの登場と同じ年ですね） S1C33208は二年間も使われていたはずなのに、この情報の少なさはいったい… S1C33209も検索にヒットするのはほとんどP/ECEがらみなので、もともとマイナーなシリーズなのかも？半ばあきらめていたのですが、今日、S1C33208のデータシートを見つけることができました。これまで「S1C33208」の名前で検索していたのが、なかなか見つけられなかった原因でした。旧名称の「E0C33208」で検索すればよかったのですね。情報が少ないことに変わりはありません（Google検索でたった2ページ）が、先頭にPDFがヒットしました。というわけで、S1C33208（旧名称E0C33208）のデータシートはこちら： http://www.2k1.co.uk/products/epson/downloads/ds_33208.pdf (2002/06/11現在) なぜここだけに残っているのか不思議ですが、とりあえず残っているうちに捕獲しておきましょう。 S1C33208とS1C33209のデータシートを見較べると、やはり周辺回路がいくつか強化されているようです。前置きが長すぎたため、本題に入ったところで今日はおしまい。（続きます…） * Sat Jun 01 20:35:00 JST 2002 Naoyuki Sawa - 一部書き換えは不可最近になって、やっとpceFile系APIを使い始めました。今回は、pceFileWriteSct()を使っていて気付いたことのメモです。セクタの一部だけを、pceFileWriteSct()を使って書き換えることはできません。例えば、次のような内容のテキストファイル「hello.txt」をP/ECEに転送しておきます。 hello, world このファイルの一部を、pceFileWriteSct()を使って書き換えようとしてみます。 pceFileOpen(&fa, "hello.txt", FOMD_WR); pceFileWriteSct(&fa, "HELL!", 0, 5); 先頭から５文字分に書き込みますので、結果は HELL!, world となりそうに見えますが、実際にはこうなります。 HELL! ・・・・「HELL!」よりも後ろは、ゴミになってしまいます。なぜこうなるのでしょうか？ pceFileWriteSct()の内部動作は、次のようなものです。・指定されたセクタを、いったんぜんぶ消去する。・指定された長さの分だけ、データを書き込む。従って、指定されたセクタのうち、書き込まなかった部分の既存のデータは消去されてしまいます。消去されないようにするには、アプリケーションプログラム側で対策しなければいけないようです。・変更したいデータを含むセクタ全体(4096バイト)を、RAMに読み込む。(pceFileReadSct使用) ・RAMに読み込んだデータを、必要に応じて変更する。・変更が終わったら、セクタ全体(4096バイト)をファイルに書き戻す。(pceFileWriteSct使用) * Fri May 31 21:00:00 JST 2002 Naoyuki Sawa - make メモ P/ECE開発環境に入ってる「make」ユーティリティは、一般的なUnix上のmakeや、VisualC++のnmake等に較べて、一部、機能制限されたものとなっています。機能制限されている点につきましては、同じくP/ECE開発環境に入ってる資料の『S1C33ファミリCコンパイラパッケージマニュアル』(C:\usr\PIECE\docs\datasheet\EPSON\S5U1C33000C_J.pdf) の「17.1 make (463ページ～)」を参照してください。率直に言って、P/ECE開発環境のmakeは、かなり機能制限されています。でも僕の場合、元々、GNU makeなどの一般的なmakeは、機能豊富すぎて全然使いこなせていませんでした。何度マニュアルを読んでも、$*と$<と$@の違いが覚えられなかったり…（歳かなTT） P/ECE開発環境のmakeぐらいが、僕にはちょうどいいかも知れません。さて、P/ECE開発環境のmakeを使っていて、ちょっと気付いたことをメモしておきます。 ------------------------------------------------------------- コメントの開始を示す「#」は、行の先頭に書かなければいけません ------------------------------------------------------------- 例えば、Unix上のmakeならば、次のようなコメント行を書くことができます。 all: # *** この行はコメント *** echo "OK!" しかしP/ECEのmakeでは、「# *** この行はコメント ***」をコマンドとして実行しようとして、エラーになります。 VisualC++のnmakeでも、P/ECEのmakeの場合と同じように、エラーになります。では、Unix上のmakeでは、なぜエラーにならなかったのでしょうか？ Unixでは、「#」この文字がメイクファイルに対するコメント開始文字であると同時に、シェルに対するコメント開始文字でもあるからです。 Unix上のmakeも、「# *** この行はコメント ***」をコマンドとして実行しようとしますが、コマンドの実行を仲介するシェルが、「#」この文字以降をコメントと見なして捨ててくれるようです。つまり、Unix上のmakeでエラーならなかったのは、たまたま、と言えるかもしれません。（「#」が行の先頭になければいけないって、P/ECEのmakeでエラーに遭遇するまで知りませんでした...(^^;）上の例を正しく書き直すと、次のようになります。 all: # *** この行はコメント *** echo "OK!" なんとなく見づらいですが、仕方がありません。あるいは次のような手段で、行の途中からコメントを始めることもできますが、ここまでやる必要はなさそう。 all: cmd /c rem *** この行はコメント *** echo "OK!" なお、依存関係行に関しては、行の途中から「#」でコメントを始めても大丈夫です。次の例は、P/ECEのmake、nmake、Unix上のmakeのいずれでも、正しく動作します。 all: # *** この部分はコメント *** echo "OK!" ---------------------------------------------------------------------- 別のフォルダにあるメイクファイルを実行するには、-Cオプションを使います ---------------------------------------------------------------------- Unix上のmakeなら、次のようにするところ、 cd lib; make all P/ECEのmakeではエラーになってしまいます。 Windowsのシェルは、「;」を使ったマルチステートメントに対応していないためです。 P/ECEのmakeで、上の例と同じことを行うには、 make -Clib all と書きます。 -Cオプションを使うと、指定されたフォルダへ移動してからメイクファイルを読み込みます。 -Cオプションは、Unix上のmakeにはない、P/ECE開発環境のmakeに特有のオプションみたいです。 * Fri May 26 00:00:00 JST 2002 Naoyuki Sawa - 関数アドレスをシンボル定義して呼び出す「関数ポインタ型にキャストしてはいけない」の回（以下、前回と略します）の続きです。絶対アドレスcallを行うには、インラインアセンブラを使って、次のように： asm("xld.w %r1, 0x00c034aa"); asm("call %r1"); 書かなければいけない、というのが、前回の結論でした。ちなみに0x00c034aaは、BIOS 1.18における、pceLCDTrans()のアドレスです。関数アドレスを直接プログラム中に記述すると、プログラムが読みづらくなります。上のコードは、次のように書ければ、読みやすくなるでしょう。 asm("xld.w %r1, pceLCDTrans"); asm("call %r1"); そこでまずは、カーネル内の関数アドレス一覧を定義した、.hファイルを用意します。カーネル内の関数アドレスは、「c:\usr\piece\sysdev\pcekn\pcekn.sym」から得られますので、スクリプトを使って.hファイルに変換しましょう。 pcekn.symを.hファイルに変換するスクリプトはこちら http://www.piece-me.org/archive/pcekn_sym.sed （※前回のサンプルプログラムのおまけフォルダに入ってたのと、同じものです）使い方は、次の通りです： sed -nf pcekn_sym.sed c:\usr\piece\sysdev\pcekn\pcekn.sym > pcekn_sym.h （※P/ECE開発環境を「c:\usr\piece」以外にインストールした場合は、適宜変更）これで、カーネル内の関数アドレス一覧を定義した、pcekn_sym.hファイルが作成されます。以下に、pcekn_sym.hの一部を示します： #define pcekn_BootEntry00 0x00c02004 #define pcekn_BootEntry 0x00c02078 #define pcekn_pceGUID 0x00c02048 #define pcekn_InitVector 0x00c02208 #define pcekn_pceVectorSetTrap 0x00c021aa #define pcekn_pceVectorSetKs 0x00c021d2 #define pcekn_UnusedTrapVector 0x00c021fa #define pcekn_UnusedKsVector 0x00c021fe シンボル名の先頭に「pcekn_」というプレフィクスを付けて定義することにしました。このようにした理由は、シンボル名をそのまま使うと、公開されているAPIの名前とぶつかってしまうことがあるからです。（pceVectorSetTrapやpceVectorSetKsがそうです）さて、pcekn_sym.hを使って、次のように書くことが出来るでしょうか： #include "pcekn_sym.h" （略） asm("xld.w %r1, pcekn_pceLCDTrans"); asm("call %r1"); 実は、このように書くことはできません。「pcekn_pceLCDTrans」というシンボルは、Cプリプロセッサによって展開されるのですが、 asm("～")文の中は単なる文字列と見なされるようで、展開の対象外だからです。 pcekn_pceLCDTransは、Cプリプロセッサの段階で展開されなければいけません。そこで、次のような関数を用意します。 int call(int addr) { asm("call %r12"); } S1C33の仕様では、関数への引数は、%r12,%r13,%r14,%r15,およびスタックに渡すことになっています。引数addrは既に%r12レジスタに入っているので、そのまま「call %r12」とすればいいのです。また、S1C33の仕様では、戻り値がある場合、%r10,および%r11レジスタに返すことになっています。「call %r12」の呼び出し先からの戻り値は、そのままcall()関数の呼び出し元へ返されるのです。 {{ちょっと寄り道、C言語の話 call()関数の戻り値は、上記のような動きによって、直接%r10レジスタに格納されるため、 intを返す関数であるにもかかわらず、return命令がありません。 C言語のプログラムとしては間違っているように見え、コンパイラが警告かエラーを出しそうなものですが、実際には、コンパイラは警告もエラーも出しません。この場合は、警告もエラーも出なくてうれしいのですが、なぜ出なかったのでしょうか？「プログラミング言語Ｃ第２版」を読み直してみたところ、どうやらこれは、C言語として正しいようです。『値を返す関数に「return 式」がなかったり、単なる「return」で抜けたりするのは、文法的には正しい』ということがわかりました。（1.7「関数」の、31～32ページあたりです）例えば次のような関数は、いずれもC言語の文法としては正しいのです。 int sum(int a, int b) { } /* ゴミを返す */ int sum(int a, int b) { return; } /* ゴミを返す */ int sum(int a, int b) { return a + b; } /* 正しい結果を返す */ う～む、これは知りませんでした。姑息なコーディングの手段として、使えそうだ…(^^; ちなみにC++言語では、文法の仕様が厳しくなっているので、エラーになります。 }}寄り道終了 call()関数を利用して、pceLCDTrans()を呼び出すには、次のようにします。 call(pcekn_pceLCDTrans); 最適化オプションや、その他のコンパイルオプションを付けたり外したりして試してみたところ、どの場合にも、正しく動くようです。今回のサンプルプログラムはこちら http://www.piece-me.org/archive/direct2-20020526.zip * Mon May 20 00:00:00 JST 2002 Naoyuki Sawa - ファイルから一文字づつ読み込む P/ECEには、ファイルからデータを読み込むAPI「pceFileReadSct()」があります。このAPIの欠点として、ファイルの４ＫＢ単位の位置からしか読み込み開始できないという点が挙げられます。例えば、「ファイルの先頭から8191(=8KB-1)バイト目のデータを1バイトだけ使いたい」場合、いったん、バッファに4096バイト目～8191バイト目のデータを読み込んで、バッファの中の4095バイト目を取り出す、なんてことをしなければいけません。 pceFileReadSct(&fa, buffer, 8191 / 4096, 4096); data = buffer[4095]; 時間的にも(1バイト使いたいだけなのに、4KBの転送を行っています)、空間的にも(1バイト使いたいだけなのに、4KBのバッファが必要です)、非常にムダです。そこで、pceFileReadSct()には、この欠点を帳消しにする、素晴らしい機能が備わっています。読み込むバッファのアドレスにNULLを指定すると、フラッシュメモリ上でのセクタアドレスを直接、得ることが出来るのです。後は、フラッシュメモリ上のデータに直接アクセスすればＯＫ。この機能を利用して、ファイルから一文字づつ読み込むサンプルプログラムを作ってみました。 http://www.piece-me.org/archive/read-20020519.zip フラッシュメモリ上のデータに直接アクセスできるこの機能、すごく気に入ってます。設計者の英断に拍手！今回のネタは、「"P/ECE" Official WebPage」の「開発者掲示板」より頂きました。 * Fri May 17 22:30:00 JST 2002 Naoyuki Sawa - 関数ポインタ型にキャストしてはいけない前回の実験で、InitFlashAcc()を直接アドレス指定して、呼び出しました。そのとき気付いたのですが、pcc33(P/ECE開発環境付属のＣコンパイラ)で、 APIアドレスを直接指定して呼び出す場合、微妙なコーディングの違いと最適化の有無によって、期待通りの結果にならないことがあるようです。結論から言いますと、「関数のアドレスを示す数値を、関数ポインタ型にキャストしてはいけない」みたいです。厳密なＣ言語の仕様としては、これは正しく動かなくて正解なのかも知れませんが、前述の通り、微妙なコーディングの違いや最適化オプションの有無によって、動いたり動かなかったりするので、ちょっとつまづきました。それでは、例を挙げます。 pceLCDTrans() APIのアドレスは、BIOS 1.18では、0x00c034aaとなっています。このアドレスを直接呼び出すＣプログラムは、直感的には次のようになるでしょう。 <例1.c> ((void (*)())0x00c034aa)(); ところがこれは、最適化の有無に関わらず、正しく動作しません。 pcc33に-bオプションを指定して、Ｃコンパイラが生成したアセンブラソースを見てみると、次のようになっています。 <例1.ps> xcall 0x00c034aa 一見、正しく見えますが、実は正しくないのです。 C33(P/ECEのCPU)では、直値を引数に取るcall命令は、相対アドレスcallです。つまりこれは、「この命令の次のアドレス＋0x00c034aa」へのcall命令なのです。コンパイラかアセンブラが、0x00c034aaは絶対アドレスだと認識していれば、相対アドレスへの変換が期待できるのですが、そうはなっていないようです。 C33で絶対アドレスcallを行うには、アドレス値をいったんレジスタに代入し、レジスタを介してcallする必要があります。そこで、次のように書いてみます。 <例2.c> void (*fn)() = (void (*)())0x00c034aa; fn(); すると、おおよそ期待通りに、次のようなアセンブラソースが生成され、 <例2.ps> xld.w [%sp+4],%r0 xld.w %r10,0x00c034aa xld.w [%sp],%r10 xld.w %r0,[%sp] call %r0 正しく動作します。どうやら、アドレスを直接指定してAPIを呼び出すには、関数ポインタ型の変数にアドレスを代入してから、呼び出せばいいようです。ところが！！ pcc33に最適化スイッチ-O2を付けると、これも正しく動かなくなります。 -O2を付けてコンパイルした場合のアセンブラソースは、こうなります。 <例2.ps 最適化> xcall 0x00c034aa ご覧の通り、例1と同じアセンブラソースが生成されています。コンパイラの最適化により、変数への代入が省略されてしまったからです。 ※そもそもＣ言語仕様に反することをやっているので強くは言えないのですが、 ※この最適化は問題だと思います。 ※前述の通り、C33では「call 直値」と「call レジスタ」のふるまいは、 ※全く異なっています。最適化によって、 ※ 「直値 -> 変数; 変数 -> レジスタ; call レジスタ」 ※という処理を、 ※ 「call 直値」 ※に置き換えることは絶対に出来ないはずです。しかし、実験結果を見る限り、 ※pcc33（が呼び出すgcc33）は、この置き換えを行ってしまうようです。結局、最適化の有無によらず正しく動作させるためには、インラインアセンブラで書くしかないようです。 <例3.c> asm("xld.w %r1, 0x00c034aa"); asm("call %r1"); 生成されたアセンブラソースは、当然、次のようになります。 <例3.asm> xld.w %r1, 0x00c034aa call %r1 最適化スイッチ-O2を付けても、もちろん、結果は変わりません。 <例3.asm 最適化> xld.w %r1, 0x00c034aa call %r1 今回の実験プログラムはこちら http://www.piece-me.org/archive/direct-20020517.zip * Thu May 16 12:00:00 JST 2002 Naoyuki Sawa - フラッシュメモリAPIをムリヤリ使う P/ECEうたわれるもの計画の一環で、フラッシュメモリの直接書き換えを試しました。なぜこんなことを試したかというと、大きな画像データをフラッシュメモリ上に置いたまま利用するために、実行時にファイルシステムのデフラグを行うためです。さて、フラッシュメモリを直接書き換えるためのAPIとして、 pceFlashErase()とpceFlashWrite()が用意されています。(ただし非公式です) pceFlashErase()とpceFlashWrite()は、piece.hに載っているところを見ると、ユーザーアプリケーションから使えるように見えますが、実は使えません。カーネルサービスベクタに登録されていないからです。 pceFlashErase()とpceFlashWrite()をカーネルサービスベクタに登録するための InitFlashAcc()は定義されている(fmacc.c)のですが、どこからも呼ばれていません。そのため、pceFlashErase()とpceFlashWrite()に対応するベクタエントリは、デフォルトのUnusedKsVector()を指したままになっています。 UnusedKsVector()は何もせずに-1を返す関数(pcekn.c)なので、ユーザーアプリケーションがpceFlashErase()やpceFlashWrite()を呼び出すと、何もせずに-1を返すだけなのです。 BootEntry()初期化関数(pcekn.c)から、各種サブシステムの初期化が呼ばれ、カーネルサービスベクタが設定されます。 InitFlashAcc()もここから呼ばれるべきだと思うのですが、呼び忘れでしょうか。それとも、フラッシュメモリの書き換えは危険なので、ユーザーアプリケーションから利用できないように、わざと呼んでいないのでしょうか。ベクタエントリは用意されているところを見ると、InitFlashAcc()の呼び忘れの可能性が高いように思うのですが…（わざとだったらごめんなさい） pceFlashErase()とpceFlashWrite()をユーザーアプリケーションから使うには、何とかしてInitFlashAcc()を呼び出し、カーネルサービスベクタを設定してやらなければいけません。今回は、非常に危険な方法ですが、アドレス決め打ちで呼び出すことにしました。 BIOSのバージョンが変わると、アドレスもずれるので、多分動かなくなると思います。実験プログラムはこちら http://www.piece-me.org/archive/flash-20020516.zip 実験用ファイルを作成し、その内容を、ファイルAPIではなくフラッシュメモリAPIを使って、直接書き換えています。(※前述のとおり、BIOS 1.18 専用です！) * Mon Feb 4 20:16:32 JST 2002 Naoyuki Sawa - カーネルいちゃもんコーナー出張版（ライブラリ編）久々に、シンプルライブラリでミニゲームを作ってみようと思いました。 PieceSystem Ver1.18で追加された、シンプルライブラリの新機能も使ってみたいですね。... C:\usr\PIECE\lib\simple.lib: Warning: Unresolved external symbol 'va_end'. C:\usr\PIECE\lib\simple.lib: Warning: Unresolved external symbol 'va_start'. ...それ以前の問題でした。リンクできなくなってます(;;) 再現方法は次の通りです。付属のsimpleプログラムで、prog.txtの二行目を、 printstr("SKI GAME"); から、 siprintf("SKI GAME"); に変更してmakeすると、上記のメッセージが出て、実行ファイルは生成されません。　僕たちのP/ECE開発環境では、va_startやva_endはマクロとして定義されているのですが、シンプルライブラリの作成環境では、va_startやva_endが関数になってたのかも知れません。 PieceSystem Ver1.18がリリースされて、もう一週間以上経っていますので、とっくに発覚していると思いますし、次回のリリースでは修正されると思いますが... シンプルライブラリはお手軽・高機能で、かなり気に入ってただけに、ちょっと痛いところです。 * Tue Jan 29 20:20:03 JST 2002 Naoyuki Sawa - おでマル高速版昨日の研究記録でちょっと予告(?)した通り、おでマルに高速版pceLCDDrawObjectを組み込んでみました。昨日の時点では、転送元ビットマップは2bitデータmask付き・反転なし、だけに対応していましたが、おでマル高速版に組み込んだものは、転送元ビットマップは2bitデータmask付き、または、maskなし。上下左右反転にも対応しました。コード展開しまくった結果、8KB近いサイズ増加になってしまいました。オリジナルのpceLCDDrawObjectが、あまり高速化されていなかった理由が、よく理解できました。全てのプログラムが高速描画を要求するわけでもないのに、あまり大きなルーチンにできないですよね。さて、おでマルベンチの結果発表です。同じセーブデータを使って、サウンドONの状態でおでかけし、おでかけ開始～帰還までの時間を計測しました。アイテム発見回数の違いも影響しますが、ある程度の目安にはなると思います。あ、pceAppSetProcPeriodとかの調整はしていないので、信じてください(^^; STATUS: POW=652 INT=886 DEX=682 2930J アクアプラスビルへおでかけ～帰還までおでマル(本物) -> ８分４５秒おでマル高速版 -> ５分５０秒数字で見るとあまり高速化されていませんが、サウンドOFFにかなり近い速度にはなったと思います。もっとも、おでマル高速版の意義はそれ自体にあるのではなく、「これぐらいあおっておけば、だれか(本家でも可)pceLCDDrawObjectを徹底的に高速化してくれるのでは？」という点にあったりします。よろしくお願いします～(^^; * Tue Jan 29 20:20:03 JST 2002 Naoyuki Sawa - カーネルいちゃもんコーナー出張版 BIOS1.18現在、pceLCDDrawObjectの2bitデータ(mask無し)描画には不具合があるようです。再現プログラムはこちら。(または、トップページのリンクから) http://www.piece-me.org/archive/drawerr-20020129.zip 再現方法： drawerr.pexを転送し、実行してください。64x16ピクセルの2bitデータ(mask無し)を左右反転で描画する、単純なプログラムです。パッドの上下左右でキャラクタを動かすことができます。左右に動かすと、時々キャラクタが崩れるのが確認できると思います。プログラムを終了するには、Aボタンを押してください。原因： pceLCDDrawObjectは、2bitデータ(mask無し)を描画するとき、特定の条件で高速ルーチンを使うように作られているようです。高速ルーチンが使われる条件は、・転送先X座標が4の倍数であること。・転送元X座標が4の倍数であること。・転送幅が4の倍数であること。これらの条件が全て満たされると、テーブルを利用して4ピクセルまとめて描画を行い、三倍程度の高速化が達成されています。しかしながら、左右反転時には4ピクセルを左右逆転したテーブルを利用すべきなのですが、現在の実装ではそうなっていません。左右反転しないときと同じテーブルを使ってしまっているため、4ピクセル移動するごとにキャラクタが崩れる結果となります。回避方法：この不具合が現在まで残っているということは、あまり2bitデータ(mask無し)は使われていない、ということでしょうか？僕もあまり使いません(^^; ・2bitデータ(mask無し)は使わない。2bitデータmask付きで代用する。ただし、少し速度低下します。・2bitデータ(mask無し)を描くときは、左右反転は使わない。 * Mon Jan 28 21:09:06 JST 2002 Naoyuki Sawa - 二倍速くなりました昨日に引き続き、pceLCDDrawObjectの高速化の話題です。昨日の研究記録では、既存の最適化済みルーチンを使わせて頂くのも手かな、と書きましたが、まずは練習のために、自分でも実装してみることにしました。高速版pceLCDDrawObjectを組み込んだソースはこちら http://www.piece-me.org/archive/tstspd-20020128-src.zip 高速版pceLCDDrawObjectの部分は、こんな感じです。 ----------------------------------------------------------------------------- #define KSNO_LCDDrawObject 100 /* pceLCDDrawObjectのカーネルサービス番号 */ static int (*old_LCDDrawObject)(DRAW_OBJECT); /* 本物のpceLCDDrawObjectを保存 */ static int new_LCDDrawObject(DRAW_OBJECT obj) { PIECE_VRAM dest; PIECE_BMP src; int n, x, y, step, dest_stride, src_stride; unsigned char *dest_buf, *src_mask, mask; unsigned short *src_buf, pixel; /* 単純転送でなければ、本物に任せます。 */ if(obj.param != DRW_NOMAL) return old_LCDDrawObject(obj); /* 転送元ビットマップ情報を取得。 * 2bitマスク付きビットマップでなければ、本物に任せます。 */ src = *obj.src; if(src.header.bpp != 2 || src.header.mask != 1) return old_LCDDrawObject(obj); /* 転送先VRAM情報を取得。 */ if(obj.dest != NULL) { dest = *obj.dest; } else { dest.w = DISP_X; dest.h = DISP_Y; dest.buf = pceLCDSetBuffer(INVALIDPTR); } /* 転送先クリッピング。 */ if(obj.dx < obj.clip.left) { n = obj.clip.left - obj.dx; /* 左にはみ出たピクセル数 */ obj.dx = obj.clip.left; obj.dw -= n; obj.sx += n; } if(obj.dx + obj.dw > obj.clip.right) { obj.dw = obj.clip.right - obj.dx; } if(obj.dw <= 0) return 0; /* 画面外 */ if(obj.dy < obj.clip.top) { n = obj.clip.top - obj.dy; /* 上にはみ出たピクセル数 */ obj.dy = obj.clip.top; obj.dh -= n; obj.sy += n; } if(obj.dy + obj.dh > obj.clip.bottom) { obj.dh = obj.clip.bottom - obj.dy; } if(obj.dh <= 0) return 0; /* 画面外 */ /* 転送元クリッピングは行いません。 * 元々指定された転送元矩形が転送元ビットマップ内に収まっていたならば、 * 転送先クリッピングによって転送元がはみ出すことはありえないからです。 * しかし本物は転送元クリッピングも行っているので、この点は非互換です。 */ /* 転送先ピクセルアドレスを求めます。 */ dest_buf = dest.buf + dest.w * obj.dy + obj.dx; dest_stride = dest.w /* ラインストライド */ - obj.dw; /* 一行で何回進むか */ /* 転送元ピクセルアドレスを求めます。 */ n = (src.header.w * obj.sy + obj.sx) / 8; src_buf = (unsigned short*)src.buf + n; src_mask = src.mask + n; src_stride = (src.header.w + 7) / 8 /* ラインストライド */ - ((obj.sx & 7) + obj.dw - 1) / 8; /* 一行で何回進むか */ /* ~~~ 8ステップ完了時に進むのではなく、9ステップ目の先頭で進むから */ y = obj.dh; /* 残りライン数 */ do { /* 8ピクセル単位のうち、何ピクセル目から開始するか？ */ step = obj.sx & 7; /* 開始点から始まるか途中から始まるかわからないので、 * 初回はたとえstep=0でも、ここで最初のデータを取得することにします。 * ※P/ECEビットマップのピクセル並びは、MSB側が左のピクセルなんですね。 * S1C33はリトルエンディアンなんだから、LSB側を左のピクセルにした方が扱いやすいと思うのですが。 * WindowsBMPはMSB側が左のピクセルなのかな？もしそうならば、BMPの仕様に合わせたのかも知れません。 */ pixel = *src_buf; /* ピクセル並びは MSB:45670123:LSB の順です */ mask = *src_mask; /* ピクセル並びは MSB:01234567:LSB の順です */ /* 何ピクセル目から開始するかによって、適切な位置へ飛び込みます。 */ x = obj.dw; /* 残りピクセル数 */ switch(step) { LOOP: /* 初回はここは飛び越します */ /* 8ピクセル単位の開始点で、次のデータを取得します。 */ pixel = *++src_buf; mask = *++src_mask; #define PIXEL(p, m) \ /* 不透明ピクセルなら、描きます。 */ \ if(mask >> (m) & 1) *dest_buf = pixel >> (p) * 2 & 3; \ dest_buf++; \ /* 1ライン転送完了したら、抜けます。 */ \ if(--x == 0) break; case 0: PIXEL(3, 7); case 1: PIXEL(2, 6); case 2: PIXEL(1, 5); case 3: PIXEL(0, 4); case 4: PIXEL(7, 3); case 5: PIXEL(6, 2); case 6: PIXEL(5, 1); default/*7*/: PIXEL(4, 0); goto LOOP; #undef PIXEL } /* 転送先・転送元ピクセルアドレスを次のラインへ進めます。 */ dest_buf += dest_stride; src_buf += src_stride; src_mask += src_stride; } while(--y != 0); return 1; } void hook_LCDDrawObject() { /* pceLCDDrawObjectをフックします。 */ old_LCDDrawObject = pceVectorSetKs(KSNO_LCDDrawObject, new_LCDDrawObject); } void unhook_LCDDrawObject() { /* pceLCDDrawObjectをフック解除します。 */ pceVectorSetKs(KSNO_LCDDrawObject, old_LCDDrawObject); } ----------------------------------------------------------------------------- さて、結果発表です。本物pceLCD(抜き有り) -> 21.207秒 ... 100% 高速pceLCD(抜き有り) -> 9.718秒 ... 218% ※これです！ pclSprite (抜き有り) -> 6.091秒 ... 348% まあまあです。だけど、スプライトライブラリには遠く及びません。しかも、スプライトライブラリのソースには「未高速化」とコメントされています。スプライトライブラリは、今後まだまだ速くなるということでしょうね。手強い！願わくば、その余力でちょっとだけpceLCDDrawObjectも高速化して欲しいところですが...(^^; 今回実装した高速版pceLCDDrawObjectは、次の条件が満たされた場合のみ高速ルーチンを利用し、一つでも満たされなかった場合は、本物のpceLCDDrawObjectに処理を任せるようにしました。高速ルーチンが利用される条件は、次の通りです。・pceLCDSetObjectに指定したparamが、DRW_NOMALであること。・転送元ビットマップが、「2bitデータmask付き」であること。この条件を満たす描画要求(高速ルーチンが利用されます)の回数よりも、条件を満たさない描画要求(本物に処理を任せます)の回数の方が圧倒的に多い場合は、高速版pceLCDDrawObjectから本物のpceLCDDrawObjectを呼び出す処理が増える分、元々の処理速度よりも遅くなってしまう可能性があります。また、本物のpceLCDDrawObjectに較べて、一点、処理を省いた部分があります。それは、転送元ビットマップに対する転送元矩形のクリッピング処理です。転送元矩形に、転送元ビットマップをはみ出