まだまだねばるPIC用GCC、別アドレス空間の話

結局10月は1回しかBLOG書かなかったけど、実はGCCはずっと触
り続けてます。

RTL生成よりも前の段階である誘導変数最適化のあたり
(ivopts)はなんとなくぼんやり分かった気がするけど、ここは
いい加減。レジスタ割り当てのあたり、(ira)はそれなりに読
んでます。

PIC18Fの12ビットレジスタポインタに対してどのようにすれば
よいのか妥協案を立てて、現在それっぽいコードが出るように
なってきました。ただ、フレームポインタが必要となるケース
の場合、PIC18Fだと、メモリをさすことができるポインタが3
本しかない(fsr0, fsr1, fsr2) スタックと、フレームで2本消
費されると、残っている1本(fsr0)では、コピー元とコピー先
を同時にさすことができないので、コンパイルが破綻すること
は防げてません。

それ以外は結構うまくいっているみたいです。

ところで、久しぶりにGCCのソースをsub versionで更新したら、
9月27日にblogにも書いたIBMの人が始めた、別アドレス空間の
サポートが本流のソースに入ったみたいです。

PICだとROMとRAMとFLASHなどへのポインタを作ることができま
す。これらは型が違うから、異なったサイズのポインタにもす
ることができ、たとえば、プログラムメモリ用には20ビット、
RAM用には12ビットとかもできるはずなんだけど、、

ドキュメント上次のように書かれてます。

As an extension, the GNU C compiler supports named address spaces as
defined in the N1275 draft of ISO/IEC DTR 18037. Support for named
address spaces in GCC will evolve as the draft technical report changes.
Calling conventions for any target might also change. At present, only
the SPU target supports other address spaces. On the SPU target, for
example, variables may be declared as belonging to another address space
by qualifying the type with the ea address space identifier:

SPUはIBMのCELLのプロセッサですよね。

組み込み向けのプロセッサの場合、プログラムのメモリ空間と
データのメモリ空間が完全に異なっていて、アクセスするため
の命令がまったく違うからここで言うNamed address spaceの
機能がないと、異なる空間にたいするアクセス命令が生成でき
ないんですよね。

ここで注意しなければならないことは、

rom char data_dayo[10] = {1,2,3,4,5,6,7,8,9,10};

上のような感じのデータを作る場合、

char *ptr = data_dayo;

上のような記述は型エラーになります。
そうしないと、*ptrと書いたときに、RAM上のデータアクセスの命令が
出てしまって糸どおりにならないからです。

じゃ、キャストして代入すればすれば良いのか?例えば

char *ptr = (char *)data_dayo;

→無理です。理由亜すぐ分かると思いますが、キャストは
*ptrとしてアクセスする差異に生成される命令に
何の影響も及ぼさないからです。やっぱりRAM上のメモリを
アクセスしてしまう。

正しく動かすためには、

rom char *ptr = (char *)data_dayo;

と書かないとダメです。

AVR-GCCでは。GCCがnamed address spaceをサポートしていな
かったため、諦めて割り切って、FLASHメモリ空間をアクセス
するときに、特別なオナジナイを付けてます。

今すぐAVRでNamed Address Spaceをサポートすると世界で2番
目の実装になりますよ。誰かがんばって。

PICは、大変だけどAVRならやれば1週間ぐらいで出来ると見て
るんだけど？

僕も、PIC用のGCCを手がけてなければやっても良いんだけど、
AVRの方に走ったら、二度とPICに戻ってこない気がして、、、、