#10ＭＵＳＡＳＩ２．０Ａ→ＭＵＳＡＳＩ３．３化(2006-01/27)
■（注：このＤＧＥＮは１．００です。最新のＤＧＥＮはもっとず-----っと遥か彼方に進んでいます。
（現在本家の最新版は１．３０）
スキルがあり、開発をしたい方は開発者に直接コンタクトをとって下さい。
私は開発者とは全く関係のない第三者です。
あくまでこのページの話は実験用途（教育用）です。）
□謎：昨日の状態から、６８０２０と６８０１０関係の命令を、
削除し、（絶対に実行されないがリンクされている）
サイズを小さくしただけの状態で、（もちろん命令テーブルは変わるが）
「ＢＦ０３チェック」をしてみたら、昨日の状態より５ｆｐｓ近く下がった。
その後最適化が進み同程度まで盛り返し、
また現在は３ｆｐｓ位下がっている。どうして、そおなるのか。さっぱり判らない。
■ＭＵＳＡＳＩ２．０ＡとＭＵＳＡＳＩ３．３の基本的な構造の違いが
クロック周りだけという事は、判った。
ＭＵＳＡＳＩ２．０Ａ 「土壇場クロック加算式」 （実行速度が速いが、メンテナンスしにくい）
ＭＵＳＡＳＩ３．３ 「クロックテーブル参照式」（実行速度が遅いが、メンテナンスしやすい）
「ＣＰＵ６８Ｋ」はＭＵＳＡＳＩ２．０Ａ同じ、「土壇場クロック加算式」である。
ＭＵＳＡＳＩ２．０ＡとＭＵＳＡＳＩ３．３は原理は殆ど同じものながら、変数名や外部仕様、内部仕様は、
大きく異なる。これをＭＵＳＡＳＩ３．３にちかずけてみる事にする。
なぜＭＵＳＡＳＩ３．３をＭＵＳＡＳＩ２．０Ａにちかずけて見ないのかというと、
そんなことしたら、管理者の如き単細胞では、「絶対にエンバグする」。
ちまちま何百個の単純作業を手で行うより、
「エディターの置換機能」と「コンパイラのエラー発見機構」に頼った方が良い。
というよりそれら（と同程度の機能）がなければ、管理者には（そんな単純作業は）絶対にできない。
（専用プログラムを組めば話は別）
これはクロックの値を万が一書き間違えた場合に、本質的にチェックする機構がないためである。
説明用：
DBcc(){
if(条件){
ADD_CLK(xxx);
}
else
{
ADD_CLK(zzz);
}
return;
}
ぐらい単純なら、まず間違えないが、実際はもっと複雑で何箇所にか分けて加減算をしている部分もある。
それに、「Ｃ６８Ｋ」というのは、構造から判断して、
恐らく「ＭＵＳＡＳＩ２．０Ａ」のカスタマイズ版ではないか、と管理者は思う。
もし不安定というのならば、カスタマイズする段階で（クロック周りを）エンバグしている可能性がある。
この辺も、実際がどおなっているのか、チェックしてみる必要がある。
そういう訳で、ＭＵＳＡＳＩ２．０ＡをＭＵＳＡＳＩ３．３に、近づけてみる事にする。
■ＭＵＳＡＳＩ２．０ＡのＡＢＣＤ命令変更。
昔のふるーーーい、メガドラエミュで、（たとえばＤＯＳの頃の初期のＤＧＥＮ（１９９８年））
ゲームは遊べるんだけど、スコアがバグって、ＦＦＦＦＣ２８６点とか（確かシャドーダンサーとか）
変な点数にならなかった？
あれは、いろいろあるけど、多分この辺のバグ。（このバグとは直接関係がないかもしれないが）
ＡＢＣＤ命令なんて普通の６８Ｋプログラマーは、スコア表示ぐらいにしか使わんからね。（ハッカーは別）
「m68kopac.c」（名称の意味：６８の命令、ＡＣ系が入ってるファイル）
の始めのほうの５つ。例えばこんな感じ（現時点）
ＭＵＳＡＳＩ２．０Ａ改
void m68k_op_abcd_rr(void) /*作業中で完全に名称一致してない。*/
{
uint* r_dst = &DX;
uint src = DY;
uint dst = *r_dst;
uint res = LOW_NIBBLE(src) + LOW_NIBBLE(dst) + (FLAG_X != 0);
FLAG_V = ~res; /* Undefined V behavior */
if(res > 9)
res += 6;
res += HIGH_NIBBLE(src) + HIGH_NIBBLE(dst);
if ((FLAG_X = FLAG_C = res > 0x99) != 0) /* ←ここの８ビットシフトは保留 */
res -= 0xa0;
FLAG_V &= res; /* Undefined V behavior part II */
FLAG_N = NFLAG_8(res); /* Undefined N behavior */
res = MASK_OUT_ABOVE_8(res);
//if (res != 0) FLAG_Z = 1;
FLAG_Z |= res;
*r_dst = MASK_OUT_BELOW_8(*r_dst) | res;
USE_CLKS(6);
}
ＭＵＳＡＳＩ３．３
void m68k_op_abcd_8_rr(void)
{
uint* r_dst = &DX;
uint src = DY;
uint dst = *r_dst;
uint res = LOW_NIBBLE(src) + LOW_NIBBLE(dst) + XFLAG_AS_1();
FLAG_V = ~res; /* Undefined V behavior */
if(res > 9)
res += 6;
res += HIGH_NIBBLE(src) + HIGH_NIBBLE(dst);
FLAG_X = FLAG_C = (res > 0x99) << 8;
if(FLAG_C)
res -= 0xa0;
FLAG_V &= res; /* Undefined V behavior part II */
FLAG_N = NFLAG_8(res); /* Undefined N behavior */
res = MASK_OUT_ABOVE_8(res);
FLAG_Z |= res;
*r_dst = MASK_OUT_BELOW_8(*r_dst) | res;
}
（注：途中の「NFLAG_8()」は実は何もしないが、ソースをＭＵＳＡＳＩ３．３と比較するのが
便利なようにＭＵＳＡＳＩ３．３に合わせてある。）
ＶフラグとＮフラグのきちんとした処理を追加した。
ここは要するに、ＵＮＤＯＣＵＭＥＮＴＳ６８Ｋ関係の資料だ。
ＭＵＳＡＳＩ２．０Ａはこれが反映されてないが、
ＭＵＳＡＳＩ３．３は反映されている。という事。
途中の８ビットシフトはよく判らなかったので保留。
あとで、調べる必要がある。
■それはそうと昨日「ＭＡＭＥの総本家」に遊びにいったら、
ＭＡＭＥ１．０２→ＭＡＭＥ１．０３にＶｅｒＵＰしてたので、ソース落としてきました。
（このサイトができた頃（２００５－１２／２９）は１．０２だった。確か。）
で、このソースが、１１ＭＢ（圧縮）なんだけど、展開すると６３ＭＢ（圧縮）になるんだよね。
さらに展開すると、何百ＭＢになるだろうから、今は出来ないけど
（今空き１６３ＭＢ、この中からＷｉｎのキャッシュも捻出）
圧縮ファイルから、ソース取り出す事はできる。
で、ＭＵＳＡＳＩを引っ張ってこようって話。
で、ＭＡＭＥのＭＵＳＡＳＩを引っ張ってきた。
ライセンスにＭＵＳＡＳＩ３．３って書いてある。けど、中身みたら、６８０４０とか対応してるし、
僕が５年前にみたＭＵＳＡＳＩ３．３とは別物。
つまりＭＵＳＡＳＩ３．３とは書いてあるものの、Ｖｅｒがぜんぜん違うらしい。
これはＭＵＳＡＳＩ３．３自体を作り直さないと、駄目かもしれない。
（m68kmake.cを動かして、ソースファイルを自動作成させるんだっけ、確か。）
つまり、ＭＵＳＡＳＩ３．３というのは、１つのＶｅｒを指しているのではなく、
ＶｅｒがＭＡＭＥの進化に合わせて無限にある。という事。
どうりで、ＭＵＳＡＳＩ３．３＝２００１年ってのは、いかにも古すぎると思ったんだ。
これは、（マニアでないと）かなり判らないよなあ。
（管理人はすっかり騙されました）
ということはＭＵＳＡＳＩ２．０Ａも複数Ｖｅｒがある可能性がある。
２０００年頃のＭＡＭＥのソースを探してきて、最新版をひっぱってくる必要が
あるな。（手に入るかどうかは別として）
オフィシャルのサイトより多分そっちの方が、手に入る可能性は高い。
これは、ＺＩＰＬＩＢオフィシャルのサイトみたいなもんだ。
古いソースを入手するのには、コツがある。
（例外はあるが）基本的にわたしはインターネット始めたばかり（去年の１２月の末）で、
古いソースというのは何も持っていない。
（もう一ヶ月、経つのか。早いな、そろそろインターネット初心者とはいえないかも、多分？）
もう一度、最新のＭＡＭＥから取ってきたＭＵＳＡＳＩ３．３を使ってＰＳＰにリンクしてみよう。
（クロック関連のバグ取れてるかも知れないし）
その為には、ＣＤ焼かなくちゃ。
（このＰＣにはＤＯＳ／Ｖ用の開発環境がない。cygwinのも意図的に消した。残り容量のせい）
→ふう、なんとか焼いた。わけ判らんＣＤがまた一枚増えてしまった。空き８６３ＭＢになった
けど、どうせ一時の事だ。（２００６－１／２８、９：３４）
