ＧＣＣ３４４実験。までｗ－ぷ
キメラ実験。までわ－ｐ
OPTI実験。までわあぷ
コースケ氏？。までわｗｗぷ
Z05始動。（Ｚ８０死闘編）
■ＳＥＧＡＤＲＩＶＥＡ３２。如何でした？で、Ｚ８０づいてる今日この頃なんですが、暑くてアイスが欠かせません。
ぺろぺろ...そりゃ、ともかく。
ＳＥＧＡＤＲＩＶＥＡ３１／３２に実験的に混入されてる。Ｚ０５が始動したす。原因はｚＢａｓｅ。
つまりＰＣ（＝＝プログラムカウンタ）、の使い方にオフセットが入ってない為。
ともかく、ＢＦ０３でパフォーマンスチェック。
ううう、ｚ０３とほぼ同じかはええ。で、「ぷよぷよ２」...何の問題もない。
「m22z03EBOOT.PBP」６５３ｋＢ（ＭＡＭＥベースのＺ８０）
「m22z05EBOOT.PBP」６２５ｋＢ（ＣＺ８０ベースのＺ８０）
でサイズも小さい。
あの苦労は一体...
（２００６－０７／１５、２３：１０）
■ＮＥＯＣＤＺのページでさあ。ＣＺよりＭＡＭＥＺの方が早いでちゅって書いてあったから、Ｚ０５には
全く全然期待してなかったんですが...正しく使えば速いじゃないか。
「正しく使う」→あのＺ８０はＩ／Ｆ外して、ＰＣをポインタにしましょう。つまり、
#define zRealPC (zPC - zBase)
static unsigned char *zBase;//z80ram base
static unsigned char *zPC;//z80pc
#define SET_PC(A) zPC = (A) + zBase;
こーゆーふーにしよ。ちなみに現状
#undef CZ80_USE_JUMPTABLE
でっす。（だから小さい）
（２００６－０７／１５、２３：３５）
■
「m33z03EBOOT.PBP」６３５ｋＢ（ＭＡＭＥベースのＺ８０）
「m33z05EBOOT.PBP」６０９ｋＢ（ＣＺ８０ベースのＺ８０）
って、ちいせえ。ついに５００ｋＢ台になる気がスル。
大抵のＲＯＭより本体が小さい。圧縮してないのに...
（２００６－０７／１５、２３：４２）
■さてと、もしこのＺ８０カイゾーしたら何処までイケルんでしょうかね。（遅くなるかもしんない）
ほいメス。カンシ。（そんなもんはさすがに使わん）しゅゆちゅ。しゅゆちゅ。きょーは遅いからＯＰはあすにしよー。
（２００６－０７／１６、００：００）
■Ｚ０５ちとテストしてみたら、「ソニック３」で音楽あやしー気がする。つまりげんじょー再現度は、やっぱＭＡＭＥＺ。
速度はまあＭＡＭＥＺと殆ど一緒だがＣＺも結構オモシロイな。
再現度：Ｚ０３＞Ｚ０５＞Ｚ０２＞Ｚ０１
速度：Ｚ０５＞Ｚ０３＞Ｚ０１＞Ｚ０２
サイズ：Ｚ０５＜Ｚ０２＜Ｚ０１＜Ｚ０３
てな感じ。現状。
（２００６－０７／１６、０６：４２）
いちおー別館に（さしあたり動く奴を）「A32_Z05TEST.zip」で上げといたです。
（２００６－０７／１６、０８：１２）
■■■ＧＣＣ３４４実験。
今日生まれて初めてＧＣＣ３４４を入れてみた...って遅いよ。何ヶ月放置しとんねん。まあまあ。
んで、ＧＣＣ３４４でコンパイル。何故か「font3333.c」がちーともコンパイル出来ない。
ＧＣＣ３４４は（ワーク増やさない限り）マクロに弱いんだな。と思った。
「font3333.c」はマクロかましてあるが、中身は単なるフォントデーター。仮にＯＢＪに「GCC4.0.0」って付いてたって、
何の問題もないやろって思い。picodriveA14のディレクトリから「font3333.o」をコピー。で、ＯＫ。
そのあとＣＰＰでキャストのワーニングが出たんで直す。（２ヵ所、まったく同じ奴）
if( (unsigned int)(t[0]&0x80) == (priority<<7) ) // 0x8000
こんなん。さしあたり(unsigned int)にキャストして切り抜ける。（上みたいに）
（余談だが、ここは本当は(unsigned char)で足りてる。ＣＨＡＲにしときゃヨカッタ。が、差し当たりコンパイルが目的だし）
で、ＥＢＯＯＴ．ＰＢＰになったんでＰＳＰでＢＦ０３チェックしてみた。
結果： OFF 44 22 11 55
Z32m33z05 77 54+ 64 69 71 637kb /GCC344
A32m33z05 80 58+ 67 72 74+ 609kb /GCC402
Z32m22z05 81 57+ 67+ 73 75 683kb /GCC344
A32m22z05 84 62 71+ 76 79 625kb /GCC402
ＧＣＣ３４４の方が重いとは思わなかった。ふーん。サイズもＧＣＣ３４４のほーが、でかいしな。
ちうか、運だな。まーでも「運」だから「これ以上ソースに手を入れるのめんどくせえ」って時に、
「もしかして！」ちって試してみるのもアリかと。ＧＣＣ３４４のほーが速くなる場合もある（らしい）しな。
それからＧＣＣ３４４の方がfpsが安定しない。＋２ぐらい動く。
ＧＣＣ４００／ＧＣＣ４０２の場合は＋１ぐらいしか動かん。
結局ＧＣＣ４０２がいいな。ｆｐｓが同じ値ぐらいなら、安定的の方がゲームはやりやすいからな。
まあこれも「運」かもしんないケド。そーゆー傾向はありそう。...な気がする。
それともう一つ。速度が
ＧＣＣ４０２＞ＧＣＣ３４４＞ＧＣＣ４００
って可能性はある。まあ「運」だと思うケド。
結局。ヨクワカンナイ。ＧＣＣ３４４で速くなる方法は（ワタシが使ったことないから）全く解からんし。
基本的にこのページの速くなる方法ってのはＧＣＣ４００の場合です。タブン。（ってゆーかそれしか知らん）
（２００６／０７－１７、００：３５）
以下妄想。
いちよー。他の機械（ＰＣ）にcygwinとsubversionいれて、toolschain.sh経由で環境を構築する気は（時間が取れれば）ある。
ちゅーか、今の（環境の）状態は世間一般の常識にすれば「異常」だからな。でも、やってないからまだ妄想。
この機械（貧弱ＮＯＴＥ－ＰＣ＠０．２３３ＧＨｚ！ＰＳＰより遅い開発マシン。しかし何の不便も無い）には
ちと入れたくない事情があってな。
（でも、次の実験ＰＣも小数点以下ＧＨｚの予定。ＮＯＴＥ用の無線ＬＡＮカードをそのまま使う予定の為）
（２００６／０７－１７、００：５５）
■■■キメラ実験
GCC402版（本当はもどき）unziplib.aが４６ｋｂだったのに、
GCC344版unziplib.aが４５ｋｂだったので、これを強引にリンクしたら小さくなるのかどおか実験してみたつ。
対象はsegadriveA32m33z05（６０９ｋｂ）
で、やってみたら。出来るのね。そんで予想（ふつーそんなん変わらんと思うでしょ？）と
裏腹に小さくなる。６０７ｋｂになった。んで、（EBOOT.PBP）バイナリ覗くと、
---------|-0--1--2--3--4--5--6--7--8--9--A--B--C--D--E--F-|---0123456789ABCDEF
0000970b0|00 00 f4 03 03 b0 00 00 00 00 00 00 00 00 00 00 | .....ｰ..........
0000970c0|00 00 00 00 00 00 10 d5 9d 08 00 47 43 43 3a 20 | .......ﾕ...GCC:
0000970d0|28 47 4e 55 29 20 34 2e 30 2e 30 00 00 47 43 43 | (GNU) 4.0.0..GCC
0000970e0|3a 20 28 47 4e 55 29 20 34 2e 30 2e 30 00 00 47 | : (GNU) 4.0.0..G
0000970f0|43 43 3a 20 28 47 4e 55 29 20 34 2e 30 2e 30 00 | CC: (GNU) 4.0.0.
000097100|00 47 43 43 3a 20 28 47 4e 55 29 20 34 2e 30 2e | .GCC: (GNU) 4.0.
000097110|30 00 00 47 43 43 3a 20 28 47 4e 55 29 20 34 2e | 0..GCC: (GNU) 4.
000097120|30 2e 30 00 00 47 43 43 3a 20 28 47 4e 55 29 20 | 0.0..GCC: (GNU)
000097130|34 2e 30 2e 30 00 00 47 43 43 3a 20 28 47 4e 55 | 4.0.0..GCC: (GNU
000097140|29 20 34 2e 30 2e 30 00 00 47 43 43 3a 20 28 47 | ) 4.0.0..GCC: (G
000097150|4e 55 29 20 34 2e 30 2e 30 00 00 47 43 43 3a 20 | NU) 4.0.0..GCC:
000097160|28 47 4e 55 29 20 34 2e 30 2e 30 00 00 47 43 43 | (GNU) 4.0.0..GCC
000097170|3a 20 28 47 4e 55 29 20 34 2e 30 2e 30 00 00 47 | : (GNU) 4.0.0..G
000097180|43 43 3a 20 28 47 4e 55 29 20 34 2e 30 2e 30 00 | CC: (GNU) 4.0.0.
000097190|00 47 43 43 3a 20 28 47 4e 55 29 20 34 2e 30 2e | .GCC: (GNU) 4.0.
0000971a0|30 00 00 47 43 43 3a 20 28 47 4e 55 29 20 34 2e | 0..GCC: (GNU) 4.
0000971b0|30 2e 30 00 00 47 43 43 3a 20 28 47 4e 55 29 20 | 0.0..GCC: (GNU)
0000971c0|34 2e 30 2e 30 00 00 47 43 43 3a 20 28 47 4e 55 | 4.0.0..GCC: (GNU
0000971d0|29 20 33 2e 34 2e 34 00 00 47 43 43 3a 20 28 47 | ) 3.4.4..GCC: (G
0000971e0|4e 55 29 20 33 2e 34 2e 34 00 00 47 43 43 3a 20 | NU) 3.4.4..GCC:
0000971f0|28 47 4e 55 29 20 33 2e 34 2e 34 00 00 47 43 43 | (GNU) 3.4.4..GCC
000097200|3a 20 28 47 4e 55 29 20 33 2e 34 2e 34 00 00 47 | : (GNU) 3.4.4..G
000097210|43 43 3a 20 28 47 4e 55 29 20 33 2e 34 2e 34 00 | CC: (GNU) 3.4.4.
000097220|00 47 43 43 3a 20 28 47 4e 55 29 20 33 2e 34 2e | .GCC: (GNU) 3.4.
000097230|34 00 00 47 43 43 3a 20 28 47 4e 55 29 20 33 2e | 4..GCC: (GNU) 3.
000097240|34 2e 34 00 00 00 1c c8 96 08 00 00 00 00 00 00 | 4.4....ﾈ........
000097250|00 00 00 00 00 00 00 00 00 00 00 00 00 00 1d 00 | ................
こーんな感じで強引にリンクされてる。
■そんで、そのキメラちゃんで、ＢＦ０３取ってみた。
結果： OFF 44 22 11 55
Z32m33z05 77 54+ 64 69 71 637kb /GCC344
Z32m22z05 81 57+ 67+ 73 75 683kb /GCC344
A32m33z05 80 58+ 67 72 74+ 609kb /GCC402
A32m33z05 80+ 59+ 68+ 73 75+ 607kb /GCC402+uz344
A32m22z05 84 62 71+ 76 79 625kb /GCC402
ててて、（サイズが小さくなって）速くなるのね。一応。ちゅー事で、unziplib.aは分離した方がいいし、
最適化ＯＰＴも－Ｏ３（速度最適化）とかは止めて－Ｏ１（サイズ最適化）とかに変えたほーがいいんだな。
...参考になるなあ。でも、「運」かもなあ？（謎）
例えばさあ、「unziplib.a」に勿論「速度」は要らないんだケド。でも現状は、「解凍速度重視」の為、
「ＣＲＣ３２テーブル」とか入ってる。「サイズ重視」なら、んなもんとっぱらっちゃったほーがいいし。
「*.a」止めて「NesterJ」や「ＭＡＭＥ」みたいに内蔵型にしちゃったほーがいいって事だね。
■■■OPTI実験。
先程の「キメラ」実験で「要点」が解かったんで、んじゃ今度は最適化ＯＰＴを変えてみる実験。
今度はＧＣＣ４０２（本当は４００？＋４０２ＬＩＢ？）のみを使う。
★segadrive本体は－Ｏ３．（速度最適化）
★unziblib.aは－Ｏ１．（サイズ最適化）
にする。おそらくキメラ実験と同じよーな効果が得られるだろー。えっとMakefile
まず
CC_OPT = -Werror -Wall -fomit-frame-pointer -fno-exceptions -mgp32 -mlong32 -msingle-float -mabi=eabi -c
で最適化指定を外す。
んで、
# UnzipLib 関係は－Ｏ１（サイズ最適化）にしてみた。
$(OBJ)/UnzipLib/%.o : src/UnzipLib/%.c
$(CC) -O1 $(CC_OPT) $(DEFINES) $< -o $@
# んで、その他は－Ｏ３（速度最適化）ね。
$(OBJ)/%.o : src/%.c
$(CC) -O3 $(CC_OPT) $(DEFINES) $< -o $@
こーゆーふーに、Makeは書くんだお。そーすると自動で最適化を振り分けてくれる。（だからソースファイルの
位置には意味があるんだお）
んで、
# EBOOT.PBPの作り方
$(BINARY): $(OBJS) unziplib.a
$(LD) $(SOBJS) $(LIBS) $(LINK_OPT) -o $@
$(STRIP) $(BINARY)
$(OUTPATCH) $(BINARY) $(BINARY_P) "USERPROG"
$(ELF2PBP) $(BINARY_P) $(TITLE) $(ICON0)
$(CP) EBOOT.PBP m$(MV)z$(ZV)EBOOT.PBP
$(RM) $(TEMP_FILE)
# unziplib.aの作り方
unziplib.a: $(ZOBJS)
$(AR) rcs unziplib.a $(ZOBJS)
こーゆーふーに分けた。（きおつけないと古いＶＥＲのunziplib.aリンクしちゃうけど、最近中身弄らんし、
万一弄ったら、「make unziplib.a」で更新しときゃ問題はない。（それかmake clean）
とにかく御託より結果。んで、ＢＦ０３。
結果： OFF 44 22 11 55
Z32m33z05 77 54+ 64 69 71 637kb /GCC344
Z32m22z05 81 57+ 67+ 73 75 683kb /GCC344
A32m33z05 80 58+ 67 72 74+ 609kb /GCC402
A32m33z05 80+ 59+ 68+ 73 75+ 607kb /GCC402+uz344
A32m33z05 81 59+ 68+ 73 75+ 606kb /GCC402_o3+uz402_o1
A32m22z05 84 62 71+ 76 79 625kb /GCC402
なーる程。で、同じ事「A32m22z05」でやってにる。
A32m22z05 84 62 71+ 76+ 79 625kb /GCC402_o3+uz402_o1
これでも「運」だと思うかも知れない。んだけど一般的に、こーゆー傾向があるんじゃあないのかな？
つまりエミュのコアとかメモリ周りとか速くないと困るとこは－Ｏ３で、
ＳＴＡＴＥセーブとかメニューとかＺＩＰ展開とか、そんなに速くなくて構わんとこは－Ｏ１で、
んで、そーゆーふーにしなかった場合とやった場合。悪くなる事はないんじゃあないかなー。
ちゅう仮説。おしまい。（だぶんＤＧＥＮ１００ＳＲＣの３４４のがはえーってのはＺＩＰＬＩＢのせいなんではないかと妄想）
■■■で、コースケ氏？強引に３４４でコンパイルしてみたんで、出来れば試して欲しいんだが...
別館に「A32Z05GCC344.zip」
（２００６／０７－１７、０２：２０）
