管理人版ＤＧＥＮ１００Ａ１９を弄ってる。(SEGADRIVE)+(picodrive)
現在ＷＲＩＴＥＭＥＭＯＲＹ関係はそのままで、ＲＥＡＤＲＥＭＯＲＹ関係を一通りは終わらせた所。
が、
これがＡ１８に比べて速いのか遅いのか、訳判らん。
速度は置いておいて、それ以前に問題点もある。ＢＹＴＥ系の命令をgenesisplusからサルベージした
時は問題なかったが、ＷＯＲＤ系の命令をサルベージしたら、ＭＷ４で音が出なくなった。
unsigned md::s68k_readword(unsigned a)//ＷＯＲＤ系はＢＹＴＥを二回流し込めばほぼＯＫなのだが、
//いろいろ細かい問題点があって、現実にはそれだけでは駄目だ。
//Ａ１８はなるべくＢＹＴＥに振っている。が、現実には殆どＷＯＲＤで来るので（この部分はＺ８０は関係ないから）
//ＷＯＲＤの処理をきちんと作った方がパフォーマンスアップが期待出来る。
//現に「管理人版ＭＤ０２２」のＺ８０でＷＯＲＤをＢＹＴＥ風になるべく共通化させた所。
//パフォーマンスダウンしたので、これが根拠になっている。（「管理人版ＭＤ０２２」の#ifdef Z80_MEMTYPE_NEWという辺りを有効にしてみる）
//が、「管理人版ＤＧＥＮ１００Ａ１９」の場合は、事情が異なるかもしれない。メモリルーチンを増やすより、
//減らしてキャッシュを有効活用した方がパフォーマンスアップするかも知れない。またＰＳＰはＢＹＴＥ(unsigned char)が
//ＰＣに比べて速い様なので、この辺も有効活用できる。
//色々複雑な要因が絡んで、（チェックも多いし）一筋縄ではいかない。なかなか難しい所である。
{
switch( a & (7<<21) ) // 現在aはアドレス(address)
{
case (0<<21): /*[0][1][2][3] ROM */
case (1<<21):
return *((unsigned short*)&rom[(a) ]);
case (7<<21): /*[e][f] RAM */
return *((unsigned short*)&ram[(a)&0xffff]);
case (5<<21): /*[a][b] Z80 & I/O */
if(a <= 0xA0FFFF) /* for Z80 */
{
// if(z80busack == 1)
// {
// return (m68k_read_bus_16(a));
// }
// else
{
unsigned char temp;
switch(a & 0x6000)
{
case 0x0000: /* RAM */
case 0x2000:
temp = z80ram[a & 0x1FFF];
return (temp << 8 | temp);
case 0x4000: /* YM2612 */
temp = myfm_read(a & 3);
return (temp << 8 | temp);
}
}
ここ（z80busack）が原因らしい。（コメントで殺してある部分が無い事）
Ｚ８０関連の調停をきちんと実装しなければ駄目だ。
＜続く＞
■#?? ちょっと余談ＰＳＰの得意なコード、苦手なコード。
管理人が体験した範囲で、ＰＣと比べてＰＳＰの得意なコード、苦手なコード。を大雑把にまとめとく、
（っていうかまとめページです。）
アルゴリズムで稼ぐのが理想的だが、実装でもこれだけ稼げるじぇ。って例。
アルゴリズムだけで稼げって説教する奴は、精神論だけでなんとかなると思ってる体育教師と同じだ。
現実には両方とも必要なんだよ。
１．ええと始めにシフト。これはトロイ。ＰＣ＞ＰＳＰだな。（この件はＰＣが速過ぎる）
２．次アドレス加算。これもトロイ。ＰＣ＞ＰＳＰという事。
ＰＣで
unsigned char *src;
lb[0] = table[(lb[0] << 8) |(*src++ | palette)];
lb[1] = table[(lb[1] << 8) |(*src++ | palette)];
lb[2] = table[(lb[2] << 8) |(*src++ | palette)];
lb[3] = table[(lb[3] << 8) |(*src++ | palette)];
lb[4] = table[(lb[4] << 8) |(*src++ | palette)];
lb[5] = table[(lb[5] << 8) |(*src++ | palette)];
lb[6] = table[(lb[6] << 8) |(*src++ | palette)];
lb[7] = table[(lb[7] << 8) |(*src | palette)];
この手のコードは、
unsigned char *src;
lb[0] = table[(lb[0] << 8) |(src[0] | palette)];
lb[1] = table[(lb[1] << 8) |(src[1] | palette)];
lb[2] = table[(lb[2] << 8) |(src[2] | palette)];
lb[3] = table[(lb[3] << 8) |(src[3] | palette)];
lb[4] = table[(lb[4] << 8) |(src[4] | palette)];
lb[5] = table[(lb[5] << 8) |(src[5] | palette)];
lb[6] = table[(lb[6] << 8) |(src[6] | palette)];
lb[7] = table[(lb[7] << 8) |(src[7] | palette)];
とするべきだ。
「配列＋小さな値」を利用すれば、アセンブラコードになった場合に、
ポスト／プリ、インクリメントに変換される事が期待できるからだ。
ＰＳＰのＧＣＣの最適化は、あくまで無駄なコードを取ることであって、
コード効率を上げてくれる訳ではない。
アドレスレジスタに変換されるよう記述してあれば、真面目にそのとおり変換してくれるし、最適化も効かない。
３．（２）と全く同じ話の裏返しだが、「配列＋小さな値」。これは速い。ＰＣ＜ＰＳＰという事。
管理人版ＤＧＥＮ１００の場合。６８０００の「インテル・モトローラ変換」を、
#if 000
//efine GET_WORD( src ) (((*((unsigned short*)src) << 8)&0xFF00) | ((*((unsigned short*)src) >> 8)&0x00FF))
//#define GET_WORD( src ) ((*((unsigned short*)src) << 8) | (*((unsigned short*)src) >> 8))
#else
/* ＰＳＰではこっちの方が軽いじぇ。 */
static inline int GET_WORD(unsigned char *src)
{ return (src[0] << 8) | src[1]; }
#endif
下のタイプにしたら、パフォーマンスがあがった経験がある。
４．char型、これは速い。ＰＣ＜ＰＳＰという事。
（３．）のサンプルをじっくり見れば判かる事だが、src[0]の0は、０を加算するコードになってはいないので、
安心して欲しい。（調べた訳じゃないよ。だって管理人ＰＳＰのアセンブラは一片も解らないし知らない）
Ｃ言語の都合上、そういう風にしか記述できない為だ。（これは特定のアセンブラコードに変換される事を期待した場合）
（↑いやこれは間違いだな「{ return ( *src << 8) | src[1]; }」でも良い筈。但し、判り難いが）
unsigned char *srcを用意しているが、くれぐれもアドレスレジスタに割り付ける事を期待してるのではない。
もしそんなコードになってしまったら、明らかにパフォーマンスが低下する筈である。
ここでは、アドレスレジスタを使用しないで、「ポスト／プリ、インクリメントに変換しろ」、と暗黙のうちに
言っているＣ言語のコードだ。
現実にそのようなコードに変換されたからこそ、パフォーマンスアップした。
■それから、ぜひ知っておいて欲しい技術として「align」がある。
これはＣＰＵがメモリをアクセスする時に、「得意な場所」。と「苦手な場所」。がある。
これは、ＰＣでもＰＳＰでもある。速いプログラムを組む場合の常識だ。
「得意な場所」をアクセスさせれば、速い。
「苦手な場所」をアクセスさせれば、遅い。
ただそれだけの「違い」である。動作はまったく一緒だ。
■ＰＳＰは腐るほどメモリが乗っている。多分３２ＭＢ（バイト）。（ＰＳ２が羨ましがる声が聞こえてきそう）
ＤＧＥＮ１００等は、古い形式のコアという事もあり、おもむろに６８０００用に１２ＭＢ（バイト）も配列で確保してしまう。
それ以外にもメモリはあちこち使用するから、実行時には結構メモリを圧迫してる筈である。
ＲＩＮさんがなにやら、「ＧＢのＲＯＭは最大８ＭＢあってうんぬん」とメモリ心配をしていたから、
管理人は、「そおかあＯＳが、ガブって取っちゃって、使える分は、少ないのかな？」と思っていた。（誤解してた）
どおりで、最近の訳判らん程メモリ喰いのＭＡＭＥが動いちゃう訳だよ。ＭＡＭＥ０９７っていえば、仮想メモリシステムが
とっくの昔に大幅拡張されてて、１２８ビットメモリとかプログラム／データー以外の領域とか（殆どのＣＰＵは関係ない）
何十メガバイトって、実行時にメモリを確保してやっと動くんだよ。もし、昔のＰＣ、例えばＷｉｎ９５の
頃の標準ＰＣ、メモリ３２ＭＢなら（多分ＰＳＰと同じ）最近のＭＡＭＥは絶対に動かない。
ＭＡＭＥが実行時にメモリを、３２ＭＢ以上、確保する事を要求してて、スワップじゃ対応出来ないからだ。
（プログラムが一気に確保する事を要求する）
■ＧＣＣ４００での「align」の具体的な書き方。
static unsigned char cart_rom[0x800000]; //0x400000[4MB](4*1024*1024)
を
static unsigned char cart_rom[0x800000] __attribute__((aligned(64))) ; //0x400000[4MB](4*1024*1024)
こうする。
この例では、８ＭＢ（バイト）おもむろに確保してますな。（コメントは違っちゃってる。がここは色々理由があってわざと間違えてある）
（ＤＧＥＮなんて１２ＭＢ（バイト）このやり方で確保する）
mallocは現状管理人の所ではうまくいかないから、すべて「malloc→配列」変換してる。
mallocなんだから、freeも殺すの忘れずに。
この例の「６４」というのは数字で、「６４バイト境界に、配置してねお願い。」という意味。
ハッキリいって「３２」でも違いはないと思う。が、「いいじゃん別に、メモリ余りまくってるんだし」、
「境界がたまたま近ければ、全く同じ結果になるんだし」、ね。
いくらＰＳＰ、charが速いとはいえ、alignが合ってなければ、片手落ちだよ。
例えば構造体のalign合わせも（こだわるんなら）必要だな。
まだ、管理人書いてないが、そのうち「md_sound」のＦＭ音源の構造体もちゃんとalignをあわせるつもり。
■genesis plus のコードについて。
これは、速くなる実装と関係が無い話なのだが、全然関係ない訳ではない。
Ｃ言語の注意して欲しい機能のひとつとして、インクリメント／デクリメントがある。
正式名称は良くワカンナイが、
i++;
って奴だ。これは、
++i;
とは（似てるが）意味が違う。Ｃ言語の入門書等で、無闇に++i;を使いたがるものがあるが、
それは悪書なので、焼いて良し。
これはきちんとした理由がある。
#inclide ＜stdio.h＞
int foo_before(void){
int i,a;
i=3;
a= i++; //←ここが違う（iを評価し、aに代入。評価後にiを加算）
return(a);
};
int foo_alter(void){
int i,a;
i=3;
a= ++i; //←ここが違う（iを評価前に加算。その後、aに代入。）
return(a);
};
void main(void){
printf("i++の結果は、%d \n",foo_before());
printf("++iの結果は、%d \n",foo_alter());
}
こんなプログラムがあったとしよう。（気分で書いたので間違ってるかも、でも意味はわかるでしょ）
この手は、「重箱の隅」と言われて嫌われちゃうんだが。えーと結果は、３、４、の筈。（まともなＣ言語ならね）
ＧＣＣの場合は、調べてみなくたって、３、４、の筈。それ以外ならＣ言語のバグだ。
（↑でも、この場合はやっぱ、４、４、かもな。整数加算では少し例が悪いかも知れない。
ポインタ加算でないと説明出来ないかも。a= (i++);の場合は必ず４になる筈だからな）
++iというのは、判った様に、特殊な用法だ。これは、「特殊な用法が場合によって必要」だから付いている機能であり、
普段から特殊な用法を使用して良い訳ではない。普段から++iと書くのはオオカミ少年でバグの元。
じゃあ普段が++iで特殊な用法がi++に統一しておけば、何も問題がないではないかと、思うだろう。
だがこれが問題がある。問題があるから、普段がi++なんである。
ちょっとジョークだが、こんな話もある。
a= i+++j;
さあ、これはどおいう意味だ。なんてね。
（終わった後のiとjの数値は、どっちが増えるか判る？現実には優先順位があり、結果は仕様上（式の評価の方向）きちんと1つに確定する）
それはともかく、普段が++iだとポインタ演算関連が非常にやり難い。そんなコードはバグの元。しかもalignとの
関連もある。せっかく０から、配列を確保してあるのに、だれが１から転送したいんだ。超ふるいプログラム
「ＦＯＲＴＲＡＮ」の移植じゃあるまいに。コード書いてみれば解かるよ。絶対的に++iが使いにくい事がね。
上の奴コピーすれば、（０ではなく）１からの転送で、
lb[0] = table[(lb[0] << 8) |(*++src | palette)];
とか書くんだぜ。Ｃ言語が、「あんさん、そいつは訳わかりまへんがな」とか言ってＷＡＲＮＩＮＧ出すから、
lb[0] = table[(lb[0] << 8) |(*(++src) | palette)];
とか書き換なきゃなんないんだぜ。こういうのが好きなのは、大学教授とかその手の方々であって、
一般的なプログラマーは（知ってれば内心は）嫌がるに決まってる。手間ばかり増えて、バグばかり、増える。
genesis plusは++i育ちなので、殆どのケースでは問題ないものの。プログラマーはこういう事は常識である為、
ちと見るのに（神経が）疲れるコードだな。っていう話。（神経が疲れるのは良くないんだぞ、バグの元だ）
ううう、厳密に説明するのは、管理人の神経が疲れるからもうこの話はヤメ！（でも、ひと通り話したでしょ？）
