昔の最近の出来事(2000.05)

2000/5/31

GNU-ld のソースコードを読むことにしました。
gdbで止めたりしながらデータを観察。データがアレイ状に管理されている事が 判りました。って今日はこれだけ(^^;

Cygwin特有の問題かもと思い、X68k版のldでも試してみましたが全く同じ。 ぐふぅ。.sbss の部分だけ怪しく重なっている様に見えるけど何かあるの かなぁ。何か心当たりのある情報をお持ちの方がいらっしゃいましたら 教えてやって下さいませ。

 .sbss          0x003a6918        0x8 rs6000.o
                                 0x44 (size before relaxing)
                0x003a6920                rs6000_pic_labelno
                0x003a6924                rs6000_debug_name
                0x003a6928                rs6000_debug_stack
                0x003a692c                toc_initialized
                0x003a6930                rs6000_cpu
                0x003a6934                rs6000_sysv_varargs_p
                0x003a6938                rs6000_compare_op0
                0x003a693c                rs6000_compare_fp_p
                0x003a6940                rs6000_trunc_used
                0x003a6944                rs6000_current_abi
                0x003a6948                rs6000_debug_arg
                0x003a694c                rs6000_fpmem_offset
                0x003a6950                rs6000_compare_op1
                0x003a6954                rs6000_fpmem_size
                0x003a6958                rs6000_pic_func_labelno
 .sbss          0x003a6920        0x8 getpwd.o
 .sbss          0x003a6928        0x4 resource.o
 .sbss          0x003a692c       0x18 c-parse.o
                                 0x28 (size before relaxing)
                0x003a6944                yynerrs              ←ここら
                0x003a6948                yydebug              ←へん
                0x003a694c                yylval               ←全滅
                0x003a6950                yychar               ←臭い

POV-Rayの時の様に上書きしている様まで追求していませんが、ldのマップ を見てみると、やっぱり重なっていました。へこり。ldのオプション変えたり 色々してみたけどやっぱりだめ。うーむ。

cc1をmakeしてみました。いくつか足りない関数を適当に足してリンク成功(^^)v
またもやお約束として cc1 --help を実行してみました。OKそう(^^)。 クロスcppで .iファイル(プリプロセッサが出力したファイル)を作って、 それを渡してみる。動きません！(＜もういいです)。
ぶっとんだアドレスをアクセスしている模様。リンカの出力したリンクマップ ファイルを眺めてみたのですが、微妙に重なっている部分がありそうな気も するけどなさそうな気も.......。ぶっ飛んでるアドレスをサーチ。なんか時間 かかるなぁ。逆アセンブルしたリストのサイズを見てみると、35MBも出力されてて ちょっとげんなりな感じ(^^; ふぅ。
ぼちぼちと調べる事にしますか.......PovRayで変数領域が重なっていた問題が 出てこなければ良いけどなぁ.....

PowerX-VMの新版がリリースされた模様。お願いしていたブレークポイントの設定や メモリダンプなどが実装されていました。これ、いいですよ！(^o^) 逆アセンブルリスト表示が正しくなれば(正しそうな気がするのですが)、 デバッガそのものって感じでかなり良いかも。

abort()を足してリンク.....できた。らっきー
お約束として cpp --help を実行してみました。動かず。dataセクションの指定がまずかった らしい(^^; リンクしなおして再び実行。動いた(^-^)v でも、cppって実はdjpegより小さい くらいなので、これくらいは動いて当然だったりして(^^;
続いて cpp test.c を実行。動きません！ってお約束ですね。 メモリアクセスがぶっ飛んでいるので、トレース。hashtab[]の中身がメタメタ なのが原因。でも、static宣言されているのに、bssセクションに入るの(?.?) bssセクションを０クリアしたら動いた。でもこれでいいのかしら？不安を残しつつ、 先に進める。
Unknown System Call.。うむ、確かにppcsimには stat()システムコールの実体を、 まだ足していないので当然です。ppcsimを修正。make.......できません！！ どうやら、Cygwin1.1.1では2バイト改行コードを食わなくなってしまった模様。 がーん。makeが変なのもこれのせいらしい。しかた無いので、ackをダウンロード して、make。 ack -euA *.c *.h Makefile で EUC+0x0a改行 に一気に置き換え。 取りあえずmakeできた。うーむ、今はMeadowなのでEUCでも編集できますが、 Windowsの標準エディタは使えなくなるのでは？どうしてくれよう......まぁ、 とりあえず再実行。動いた(^^)v。でも、#includeが入っていないテストなので入れてみる。 挙動不審。 調査。stat()が-1を返している模様。ppcsimのバグざます。続いてヘッダファイルの オープンに失敗している模様。インクルードパスが足されていない為、常にカレント ディレクトリから探している模様。..........トレースしてゆくとfile_list構造体に 入っているインクルードパスが壊れています。更に追跡してゆくと、file_list構造体の メンバーとして、struct statとchar *fname が並んでいる所で、stat()を実行すると fnameが壊れています(^^;
sizeof(struct stat)を見てみると、Cygwinのstatとnewlibのstatではサイズが違って いました(^^; そら上書きされるわな。更に追跡していくと、 sys/types.hの中のino_tのサイズが違うというのが原因だった様です。取りあえず、 unsigned longになるようにnewlibの方を書き換え。当然、libcも再コンパイルが 必要です。
ほどなくして再コンパイル終了。再度実行。動いた(^^)v
一応、クロスのcppと出力結果を比較したら全く同じになったので、取りあえず ネイティブ動作できたという事にしてしまおう(^^;
ただ、stat()エミュレーションはCygwinのstat()の返すデータ構造をそのまま 使っているので、ネイティブでstat構造体を参照すると、エンディアンが逆なの で多分死にます。が、このままほっておいてみよう(＜大丈夫か？)
そういや、abort()はnewlibの方に入っているのに、無い事になっているのは、 どうやら、abort.cがifdefで丸ごと無くなっている模様。これはこれで調べてみる 必要があるけど、とりあえずいいや。
さて、次はcc1ですか........

お仕事から帰るなり 爆睡。

猛烈に眠い一日を過ごしました。

Cygwin1.1.1用に、使っている実行ファイルをmakeしなおし中。
クロスgccができたけど動かず......そんなっ！ はうぅ 厳しいなぁ.....

意図していないパスからアセンブラを探している事が判明。取りあえず、 PowerX-VMのデモプログラムもmakeできた(bcut.exeもコンパイルし直し＆ 1GBもメモリを取ろうとしていたのを修正(大汗;; どうして今まで動いて いたのか謎)ので、元に戻せた予感。 ふぅ
再びcppをコンパイル.......abort()が無いですって
足りない関数を足しながらコンパイルする事になるのかな？ 先は長いなぁ........

日本語訳ドキュメントを読んでみました。でもなんだかいまいちよく 判らなかったりして(大汗;;;; libgcc1.aはクロスコンパイラ自身では 正しくコンパイルできないので......ってなんで？ オープン・コード ？って何？？......空ライブラリでいいや(ぉぃ;
make stage1を実行すると自分自身をコンパイルするとの事なので、 これでネイティブコンパイラが作れるのかなぁ？と実行した後、よく 説明を読んでみると、stage2コンパイラは作るなと書かれていますよ .......って、がーん！ ターゲットマシンのヘッダなどが無いから powerpc-*-*/includeに入れたのだと思ったのに、ターゲットマシンの 環境が判らないとは、これ如何に？ターゲットマシンのネイティブ コンパイラって全自動では作れないしかけになってるのかしら？ なんだかよくわからなくなってきましたよ。
どうにかcppだけでもと思い、--host=を変えてmake。stage1コンパイラ を使って、取りあえずリンクまで持ち込み、_statが無いという所で つまづく。 取りあえず、syscallを足せば良いだろうと思い、ppclib2を変更して コンパイルしようとした所、何故かppclib2がコンパイルできない！(激汗;;; gccがparseエラーを吐きまくりです(T-T) そういやCygwinが1.1.1になった 影響があちらこちらで出ているので、そのせいなのかも....ぐぅ、 もう寝るっすぅ........あぁ、朝5:00って明るい........

ネイティブコンパイラの構築を試みてみました。でもなんだかうまく ゆかず。というか英語が全然読めていません(^^; 日本語訳ドキュメント を読むことにします。

特に何もなし。

「Windowsエラーメッセージ実装ガイド」という本を買ってみました。 サンプルプログラムはWindows向けなのですが、その他の部分は一般的 なアプリケーションプログラムなどにも言える部分が沢山ありました。 「お気に入りのエラーメッセージ」と題した本文の所々にちりばめられた 変なエラーメッセージ集みたいなのが笑えました。言語の違い (日本語/英語)によらず、文法的におかしなものや意味不明なものは 沢山ある様です。ある意味、エラーメッセージの作文は、本体の プログラムより神経を使う必要があるのかも知れません(^^; この本の 中に、Press Any Key. を読んで「Any」キーってどれ？と聞かれたと いう実話 が載っていましたが、ここまでいくと、ユーザの方も かなり とほり事風味を醸し出している様に思えなくもありません(^^; 日本語だと 「どれかキーを押して下さい」を読んで「どれか」キーってどれ？ という事になるのですが........うーん...
他CマガジンでMNGの話とか読んだり。だらだらと過ごしてみました。

2Dデモを置いてみました。
libconのマニュアル書き。
Cygwin1.1.1をインストールしてみました。ネットワークインストールしてみた のですが、やっぱり３時間ばかりかかってみたり、setup.exeを実行した ディレクトリにある.tar.gzファイルが全て展開されてみたり、B20の方が使え なくなってみたりと、結構ひどい目に遭いましたがなんとか入れられた模様。 ただ、makeがうまく動かない(文法が間違っている旨を告げられる)のは何故 なのか不明。自前でコンパイルしたGNU-makeはOKそうだったので取りあえず なんとかなりそうですが......

ひといきついたので、PowerX-VMを使って遊んでみる事にしました。今の所、 PowerX-VMではメモリのダンプなどが出来ない為、おかしな事になってるとしても、 VRAMに表示する以外の方法では、おかしくなっている様を観察するする事ができ ません。なもんですから、テキスト表示を行う為のライブラリを作ってみる事 にしました。単にprintf()に相当するものを実現しているだけなのですが(^^;
フォントをどうしようかと思ったのですが、先日Windowsでウインドをキャプチャ する方法を教えてもらったので、早速乱用(笑。ASCIIコードぽっく文字をならべて、 キャプチャし、GIMP for Winを使ってASCII-PPMに変換して、それをawkを使って Cの配列ソースに変換してみました。べたべたですね(苦笑

バグがなかなか取れなかったのですが、とりあえず動いたのでHPに置いてみました(^^; でも、printf()の様に値を見るには自前で文字列変換をしないとダメな所が ダサダサ。つーか、それだと当初の目的と違っている様な(大汗;;;;; その後だらだらと2Dのグラフィックデモを作ってみたり。前回のワイヤーフレーム デモと同様、かなり適当なのに、思いのほか速かったりして驚きです。
PowerXの実機であれば、CPUシミュレーションの負荷が無くなるのと、VRAMアクセス はもっと高速であること、OSの負荷も小さくなるであろう事を考えると、 結構色々な事ができそうな予感。 CPUが遅くてもグラフィックアクセラレータが速ければOKというアプローチが一つ ありますが、CPUが尋常でないまでに速ければ、それに最適なVRAM(CPUが遅いのに フルカラー＆高解像度は×だし、CPUが速いのに16色しか出ないというのも×)が 付いていれば特殊なグラフィックハードウェアは不要かも というアプローチも、 また一つの解としてアリなのでしょうか。私、以前は後者は無いと思っていました。 というのは、Pentiumが速いといっても無茶苦茶に速い訳では無いだろうと思って いたからです(^^;;。でも、無茶苦茶に速い様なので、それに対抗するPowerPCも 無茶苦茶に速いという事で、後者はアリというのはあながち間違いでもない というのが、最近の考えになっています。 もちろん、両方満たしていれば 言うこと無しなのですが(笑

CRの件はどうやらppcsimのバグだった模様(^^; 実害はほとんど無いと思われるの ですが、実機だとこれって結構トレース大変かも。まぁ、CPUにはハードバグは無い と信じて良いなら気にする所では無いですが(^^;

一通りテストは通ったという事で、テストプログラムやテストプログラムの構築に 使用したライブラリなどを、まとめて公開。
バイナリアーカイブを直接URLで指定した場合、一部のブラウザでうまくダウン ロードできない事があったらしいので、解決方法をご教授いただいて修正して みました(＞Thanks Auge.さん)。でも、これってみんな知ってて気にしている事 なのかしら？

blrlバグを修正してもらい再実行。ををっ！展開されました(^^)。でも、こんなに 画像って荒かったかしら(?_?)？ IEで同じデータを表示してみると なんか違う(^^;; う〜〜〜ん、どうしよう...........

はっ！いつの間にか眠ってしまってましたよ(大汗;;;; 取りあえず報告。一応、実行バイナリを公開しておいてみる。取りあえずppcsimと 比べて追っかけを試みるました。まだPowerX-VMではブレークポイントを設定できな いので、どうしようかと思ったのですが、ppcsimを使って.zを生成する際に、 止めたい所に不当命令(例えば0x00000000とか)を埋め込んで強制的に止めてしまう という方法を使ってみました。でも結局、よくわからづ(^^;。強制的に止める方法 だと、ループの中では使えないのでちょっと困ってみたり。で、しばらくいじってて、 ある関数の出口でCRの結果が違う事を発見(GPRは全ておなじ)。これかなぁと思って 一応報告しようと、Webに繋いでみたら、原因が判って修正版が上がっていました (大笑
mullwとnegのバグだったらしい。mulhwの類似バグだった模様。OKっすね。ただ、 CRが違う点については気持ち悪いので更に追跡。再現プログラムを書くことが できたので、確認報告。って、もう空が白んでますが.......(-.-;;;;;;;;

お仕事(本物)開始前にぐるり。ををっ！！どうやら動いたらしい(^o^)

帰って早速最新版をダウンロードし、家でも実行。ををっ！本当に動いとる(笑
ちょっこり手を入れてアニメーションさせてみる。まわっとるまわっとる(^^) (＜うれしがりです)。かなり適当(教科書通りともいう)に書いたプログラム なのに、結構な速度で動いてますよ(^^; すげー。

JPEGロードプログラムをPowerX-VM用に整理してmakeして実行。blrlが不当命令 でエラー(^^; 一応報告。
プロ遊にPowerX-VMのページを追加してみたり、取りあえず動くサンプル置いてみたり。 ポリゴンの偉い人とかプログラムの偉い人が、興味持って遊んでくれると いいなぁ とか思ってみたり。

mflr実装版が出てきたので早速ダウンロードしてワイヤーフレーム描画プログラム を実行。エラーは出ないけど、何も描画されづ(T-T) -O2をやめて-gでデバッグを 試みました。所が、もっと手前で不当命令エラー(^^; ppcsimでも実行してみた所、 数十ステップ後だったので、gdでレジスタダンプを出しながら実行した結果と VMのステップ実行とを 目diff で比べてみました。どうやら、stwu でのストアが 正しくないらしいが、結果がおかしなまま実行して、変なアドレスに飛んだらしい。 とりあえず報告。でも、-O2のそれとは違う原因かも知れないので、 -O2の方も調べてみる。関数の入り口で止めて関数の入り口でのレジスタの状態 を比べてみた所、ある関数を出た所で微妙に違う所を発見。着目した関数の入り口 は同じレジスタの状態だったので、そこまでは合っているという事にしてトレース。 mulhwの演算結果が間違ってます(^^; 取りあえず報告。
トゥナイト２を観ながらウトウト。一応どうなったかを見てからと思って ネット接続。もう直ってました(^^; ちょっとだけ実行してダメだったら寝よう と思いつつ実行しました。まだダメでした(T-T).............結局 調べて るし(^^;.............. srawi命令の結果が正しくない模様。報告して撃沈(^^;
ほとんどチャットデバッグな感じでした(^^; でも、けっこう燃えたかも(笑 で、燃え尽きた(＜オチはつけんでよろしい)

起きて繋ぐと修正版がアップロードされてました(^^; 朝5:x0だし(^^;; ご苦労様 でした。
早速実行してみた所、不当命令エラー(^^; ステップ実行してみると、mflr命令 でエラーする模様。Cの関数コールでは必須の命令なので、無いと困まったりします。 ちう訳で報告。ぐぅ。一気に報告できれば良いのですがなかなか。
実はここまでで、30命令も実行されていなかったりするのですが、ここが通ると 一気に数十万命令くらい実行されそうな予感。そろそろブレークポイントの 設定ができた方が便利かな〜？とか思ってみたり。と書いてみるテスト(^^;

いまいち脳の活動が活発にならず。 ダメ休日の過ごし方に突入しているちっく(^^;

やっぱり、ダメなままでした......

昼頃起きてWebぐる。ふおぉっ！ PowerX-VMが公開されているじゃないですかっ！ あわわ..まだワイヤーフレーム描画のプログラムできてない のにっ。つーかそれはあまり関係ないか？ えーと、えーと、どうしよう.... いや何を？！ ってな興奮ぶりでしたよ(^^; 一気に眼が覚めました(笑

ダウンロード。サンプル実行。おおぅっグラフィックがちゃんと使えてますよっ！ しかも全面塗りつぶしているのに速いし(^^;
アセンブラを実行。取りあえずCygwinでは使えそう。試しにgccで出力した コードを食わせてみた所、エラーが沢山でました(^^; レジスタ指定に関するもの が一つ、他は'.'始まりのアセンブラ制御構文。前者は対処していただける様に ＫＯＪＩさんにお願いする。後者は...後でよく見てみるとしよう(^^;

ワイヤーフレーム描画プログラム書きの続き。 つまらない事でハマったり。 修行が足りません。メモリ上のそれを拾ってそれっぽく描画されている事を確認 し終わったのが、夜もいい時間でしたよ(^^;

早速VMで実行してみようと思ったのですが、PXアセンブラではgccの出力コード が今の所通らないので、PXVMの実行ファイル形式に変換する方法を開拓しようと、 サンプルデータをバイナリダンプで眺めてみました。どうやらファイルの先頭から 命令列が並んでいるだけの様なのでラッキー
これならば、ppcsimで実行している方式がそのまま使えそうなので、早速試して みようとしてみました。っが、レジスタの設定やメモリ環境といった事がよく 判らなくて再び質問(^^; その間、実行開始は0x00000000からという感じだった ので、レジスタの設定やPCの制御を行うルーチンを書いてみました。
この辺、リンクする事を考えると非常に面倒なので、ppcsimを使って 0x0000 に スタートアップを置いて、プログラムの本体は0x10000〜 に置いて、saveコマンド でメモリイメージを生成するという方法で実行イメージを作成しました。こうする 事で、ppcsimとほぼ同じ実行条件になるので、結果がちがったりする場合でも 比べて調べられるという魂胆。もちろんVRAMはppcsimにはありませんので、その辺 うまく切り分けられるように、プログラムの書き方を工夫する必要はありますが、 VRAMは単なるメモリイメージなので、工夫というほど大げさなものではないで しょう。
＃コマンド制御方式のメモリマップドIOアクセスだと死ぬかも知れませんが

で、いきなり実行してみたら「バスエラー」だそうです(^^; ステップ実行で ペコペコ進めてみると(便利です)、どうやらスタックの保存で0xfffffffc辺りを アクセスしている模様。この辺を設定する制御プログラムだったハズなのに！(^^; もう一回実行していくと、シフト命令が期待と異なる動作をしている様子(^^; 取りあえず報告。
直るまでには時間がかかるだろうという事で、本体プログラムの方を見直したり。 因みにメインメモリは512kBという事の様ですが、それに気づかず16MBのメモリ イメージを食わせたのは大丈夫だったのかしら？(^^;

今日の所は(日づけ変わってますが)ここで撃沈。すっかり朝だし(^^;

宴会から帰ったら即、爆睡(^^;

sbrk()を呼ばない様にmalloc()/free()スタブを書き換え。大丈夫らしい。
PowerX-VMに向けてワイヤーフレーム描画デモ書き開始。

猛烈に眠かった。いつのまにか朝になってました(大汗;;;;

libjpgを使用してテストプログラム書き。動いた(^^)v
でも、sbrk()システムコールが呼ばれている模様。外した方が良いな......

オンメモリ動作ができるようにファイルストリーム系関数のスタブ書き.....

明け方までCG描いていたので眠いです。いいとも増刊号を観ながら うだうだ。 つーか、かろうじて目が開いているだけ。今日で連休は終わりなのに、かなり ダメダメです。

見つけてくれました。(フリ回収)

明日からお仕事。復帰に時間がかかりそう(^^;..........

昼まで寝て起きて(またかい)、うだうだ だらだら。特に何もなし。

そのまんま夜。で、CGを描いてみました(＜脈絡無し)。
今(5/7)見てみると色々寝ぼけている跡が見えます(^^; まぁ、 グラフィッカーズ・ハイ だったって事で......ダメ？

昼まで寝て起きて、JCAD氏と「アイアン・ジャイアント」を観に行きました。 WB(ワーナーブロス)のアニメ映画なのですが、トゥーンシェーダーの使い方が 秀逸で、独特の絵になっていました。これの前にもアニメ映画を発表していた と思うのですが(タイトル失念)、ディズニーのそれとは、また違った方向の 雰囲気を持っているので、今後も面白いものが出てくるかも知れません。

その後、だらだらと呑んで、帰って寝た。

さて、誰が最初に見つけるでしょうか？(フリ)

フェスタ68に行ってまいりました。人ゴミ嫌いなので昼過ぎに到着したのですが、 J氏に「早いじゃないですか」とか言われてみたり(汗; ご無沙汰中の方々に挨拶 しながら ぐるりと回ってみましたが、すっかりモノが無くなってて和みモードに 突入中だったりして、私的にはいつものフェスタの様子でした(＜なんのレポート にもなっていません)。J氏は、昔言っていたオリジナルのパロディムービー (＜意味不明な言葉ですが意味明瞭なのです)をつくってたり、K氏は 某にょの オープニングを某おねで、某シンクロムービーのパロディよろしく(＜全然意味が 通じません)つくってたり、TD氏は半田付けしてたりKG氏はしっぽ付けてたり、 S氏は膨らんでいたりで、それぞれ元気そうでなによりでした。 でも、私がHP始めている事は誰も知らなかったのが意外でした。いや、 良いですが(^^;
まさちく工房さん所で、村上さんとまさちくさんの奥さんが座っていたのでご挨拶。 SH4の評価基板を試作されていたので、色々説明を聞きました。実際に動いている ものを見ることはできなかったのですが、イイ所まではできている様な感じでした。 性能評価についてはこれからという所の様でした。ある程度プログラムが動作して 性能評価が行えるのであれば、SH4がどういった馬の骨かもはっきりするので、 PC用途として性能的に使えるのか使えないのかが判るという所が個人的に興味深々 です。新会社設立に向けて幕の裏で色々準備に忙しいという事でした。
まさちくさんとしんさんとその他沢山の方々が打ち合わせをしてました(^^; 終わった頃にご挨拶。せりかさん関連のお話だった模様。色々決まって盛り上がって いた所でした。まさちくさんの嬉しそうな様子はエンジニア独特のオーラを放って いましたよ(^^; その後しんさんと、しんさんのお友達と少しお話。ちょっと すると まさちくさん御一行は打ち合わせ(^^;という事で撤収。 お疲れさまでした。

といった所で全体撤収準備。その時J氏にKQさんがいらっしゃるという話を聞いて、 見つけて(もらって)ご挨拶。初回からフェスタのスタッフだったらしいです。 ご苦労様でした。

帰って、マニュアル書いて、置いて、落描きして寝た。

おもいっきり夕方まで寝こけてました(大汗;;
povray調査の続き。地味にトレースしてみた結果、すっ飛んだ所を指している変数 は、どこかで書きつぶされているという事を突き止めました。で、書きつぶして いる箇所を突き止めたのですが、ldのリンクマップを見てみた所、

 .sbss          0x00126ac0        0xc ./parse.o
                                 0x12 (size before relaxing)
                0x00126acc                Ok_To_Declare     ←ここ
                0x00126ace                Not_In_Default
                0x00126ad0                LValue_Ok
 .sbss          0x00126acc        0x4 ./parstxtr.o
                0x00126acc                Default_Texture   ←ここ
 .sbss          0x00126ad0        0x4 ./pattern.o

ライブラリ調査の続き。なにげによーーーっく考えてみると、va_マクロを自前で 用意するという行為自体が変に思えてきました。可変長引数をどうやって渡すか を知っているのはコンパイラだけなのですから、コンパイラにva_マクロの元が無い とおかしいと思い、探してみるとgcc/gincludeの下にありましたよ。どうりで、 glibcの中にも見つからない訳ですよ。つーか、 マニュアルちゃんと読めよって感じですね。 結局、printf()の挙動がおかしかったのも、-O0でないとうまくいかないのも、 全てva_マクロがダメダメだったという理由でした。 gcc/ginclude/のstdarg.hとva-ppc.hをコピーして、コンパイルでOKでした。 djpegがうまく動作していたのは偶然だったという事ですな(^^;
これでpovrayもOKなハズ.........ダメ。__ieee754_sqrt()の無限ループ。うっかり -O2付きでコンパイルしてしまってたらしい。先にこっちを調べてみる事にしました。 ループしている部分で-O2と-O0とで命令列を見比べてみると、見たことの無い ニーモニックがっ(汗; つーか、対応漏れですよ。という事で、ppcsimの バグでした。調査終了。コンパイラのバグじゃなくて良かった
次こそはpovrayも......やっぱダメ。地味にトレース。ある関数の引数がプログラム 領域を指していて怪しさプンプン。ぐぅ。もう少し調べてみるか........ いや、寝よう(ぉぃ;

知り合い宅で食事のお世話になりました。ついでにPS2を見せてもらったり色々。 DOA2イイっす！ DCで出てないのはやっぱり失敗だったのじゃ......と思ったり。
ライブラリいじりの続き。strlen()を逆トレースしてみると、va_マクロの動作が怪しい 事が判明。objdumpで逆アセンブルしてみると、va_マクロに対するコードが生成されて いません。x68klibcベースのstdarg.hを持ってきてコンパイルしてみたけれど、何故か どうやってもコードが出てこない。-Eでプリプロセッサ通過後のコードを見てみても、 マクロ展開されているので大丈夫そう。色々みてまわった所、最適化オプションを付ける事 でマクロに対する命令列が無くなってしまう事が判明。う〜ん、なんで？
とりあえず -O0 -gでライブラリをコンパイルしてdjpegをリンクしてみたところ、 va_マクロに対する命令列が生成された模様。で、実行........バッチリです(^^)v -hの方も大丈夫そう。つー訳でやっとdjpegが動作しましたよ。ふぅ。
調子に乗ってpovrayをコンパイルしてみました。関数が色々足りないので、少し手を 入れて実行..........ダメだっ！ すっ飛んだアドレスを参照している。ぐぅ。
気を取り直して、printf()で%f表示が変だったのを先に見てみる事にする。取りあえず、 va_マクロが正しく動作していなかった事も含めて、再度テストプログラムをコンパイル＆ 実行....やっぱだめ。 なにげに%sを試してみた所、povrayと同じと思われる現象で すっとんだアドレスを参照している模様。むぅ、これを解決できれば、povrayの方も少し は進みそうな予感。