＃９MUSASI33がとろい訳。（２００６－０１／２６）
＃９MUSASI33がとろい訳。（２００６－０１／２６） ☆今日も一日ＭＵＳＡＳＩ３３を弄ってた。 （注：このＤＧＥＮは１．００です。最新のＤＧＥＮはもっとずっと進んでいます。 スキルがあり、開発をしたい方は開発者に直接コンタクトをとって下さい。 私は開発者とは全く関係のない第三者です。 あくまでこのページの話は実験用途（教育用）です。）
管理人二日、迷走してやっと理由が判った。 （過去の記事：ＭＵＳＡＳＩ２．２ぢじゃなくてＭＵＳＡＳＩ２．０Ａですね。 しかも一応０２０対応してるし、安定性は知らんが） 常識で考えれば良かった。 常識で考えれば、まずexec()を見る筈。 で、過去にも見た。 見たんだけれど、大体いっしょじゃん。と思い。構造を追いかけるばかりで、気がつかなかった。
ＭＵＳＡＳＩ２．０ＡとＭＵＳＡＳＩ３．３は、（基本的に）殆ど一緒。 違いはクロックの方法だけ。
参考：クロック消費マクロ（部分） #define USE_CYCLES(A) m68ki_remaining_cycles -= (A) /* ＭＵＳＡＳＩ３．３の 場合 */ #define USE_CLKS(A) m68k_clks_left -= (A) /* ＭＵＳＡＳＩ２．０Ａの場合 */
ＭＵＳＡＳＩ２．０Ａは、基本的にべた書きで、 消費クロックを計算している。 例：「各命令ルーチン（土壇場で）」 USE_CLKS(18); /* １８クロック消費 */
対するＭＵＳＡＳＩ３．３は、「命令ごとに用意されたクロックテーブル（自動作成）」を見ながら、 消費クロックを計算している。 例：「exec()共通ルーチンで（ｍ６８ｃｐｕ．ｃ）」 USE_CYCLES(m68ki_cycles[REG_IR]); 但し、ＤＢｃｃ命令など、辻褄の合わない所は、後で補正。（条件が成立／不成立でクロックが変わる） 例：「各命令ルーチン（土壇場で）」 USE_CYCLES(CYC_DBCC_F_NOEXP);/* クロック補正 */ 補正量はＣＰＵの種類により異なる。６８０００の場合は、 #define CYC_BCC_NOTAKE_B -2 #define CYC_BCC_NOTAKE_W 2 #define CYC_DBCC_F_NOEXP -2 #define CYC_DBCC_F_EXP 2 #define CYC_SCC_R_FALSE 2 #define CYC_MOVEM_W 2 #define CYC_MOVEM_L 3 #define CYC_SHIFT 1 #define CYC_RESET 132 で全部。
結論から言うと、ＭＵＳＡＳＩ２．０Ａの場合は実行時「exec()」 命令テーブルしか見ない。これは、この前も話したとおり、 サイズが（６４ｋｂ ｘ ４）で、２５６ｋｂ。 ＭＵＳＡＳＩ３．３の場合は、これに加えて、クロックテーブルも見る。 これは前記と同サイズ。で、２５６ｋｂ。訂正：charでした。６４ｋＢ。（同日、１８：５５）
つまり、ＰＳＰのＣＰＵのキャッシュを、クロックテーブルが圧迫して遅くなっている。 計算は速い。でも、キャッシュが圧迫されたら、遅くなるに決まってるだろ。って話。訂正：charのアクセスはとろいんでないかな？（同日、１８：５５） せめて、ＩＮＴ＝ＰＳＰの場合long＝３２ビット。でないと。（ＰＣ（ＤＯＳ／Ｖ）も事情は同じ）更に訂正：そう思ってintにしてみたけど、変わらず。（同日、１９：０５） とにかくＭＵＳＡＳＩ３．３を速くするためには、クロック関係に手を入れなければどおしようもない。 という事が判ったので、とりあえず保留という事にします。（またそのうち再開するかも）
で、ＭＵＳＡＳＩ２．０Ａにコアを戻して、例のＢＦ０３チェック。 この前（ＭＵＳＡＳＩ２．０Ａ／ＧＣＣ４．０．０）
| ＯＦＦ | ７９～８０ｆｐｓ |
| 補間付５５１２ｋＨｚ | ７２～７３ｆｐｓ |
| 補間付１１０２５ｋＨｚ | ７０ｆｐｓ |
| ２２０５０ｋＨｚ | ６５～６６ｆｐｓ |
| ４４１００ｋＨｚ | ６０～６１ｆｐｓ |
| ＯＦＦ | ７８ｆｐｓ |  －１～－２ |
| 補間付５５１２ｋＨｚ | ７１ｆｐｓ | －１～－２ |
| 補間付１１０２５ｋＨｚ | ６８ｆｐｓ | －２ |
| ２２０５０ｋＨｚ | ６４ｆｐｓ | －１～－２ |
| ４４１００ｋＨｚ | ５５～５７ｆｐｓ |  －６～－４ |