昔の最近の出来事(2002.09)

2002/09/30

日付け越え。

WriteProcessMemory()についてWebを探索したところ、共有メモリへの 書き込みを行うためのAPIらしい。狙ったプロセスの書き込み開始位置 と元のバッファポインタとコピーするバイト数まで判ってて実行する ものなので、失敗することがあるのかどうかイマイチ不明。 APIの戻り値が0でない以外の情報はデバッグコードを埋め込まないと 知ることができないっぽいけど、戻り値だけでエラー要因が判るのか どうか不明。引数の最後に実際にコピーを行ったバイト数を格納する 領域へのポインタを指定するのですが、ずっこけた時のメッセージの done 0 の0がコピーしたバイト数という事のようです。 という事は1バイトもコピーされていない模様。
例えばheapを増やしながらのメモリ書き込みが可能だと いう仕様で、それを期待したコードならば、失敗の原因として単に メモリ不足によりプロセスサイズを変更できなかったというのは 考えられるかも。ただ、エラー時のメッセージだけでは何バイト の領域をコピーしようとしたのかが不明なので、とんでもないサイズ だったのかは判らず。とんでもないサイズだとすれば、何故そのサイズ になったのかを調べる必要があるのかも知れません。 とんでもないサイズが意図したものだとすると......我が家の PCじゃダメって事じゃん。
因みに、Cygwin付属のpsコマンドではプロセスサイズを知ることは できないっぽい予感。親プロセスのサイズがえらい事になってたら なんとなくそれが原因と言えるかと思ったのですが.......

Cygwinのコンパイルはうまくゆかず。newlibのconfigureがうまく 通らない。なんで?

2002/09/29

昼頃起きて寝て、起きたら夕方(汗;ランク王国が終る前に力尽きて寝たのに。

パソコン屋に行ってメモリを購入。192MBから256MBになったけど、我が家のPCは これが搭載限界(笑。でもfork問題は解決しませんでした。ショック。 いいけど(<いいのか?)。
HDDを眺めていると、どんどん安くなっているのに驚き。80GBで14000円 くらい。昔、1GBが30000円で買えてすっごい安くなったなぁと思った のが信じられません(^^;

エロゲー売り場で商品のエロゲーソフトを使って物の片付け方を教える 男親とその子供。

しかたなくCygwinのスナップショットのソースをダウンロード。 ソースを眺めてみることにしました。
gcc-3.2を ./configure --target=powerpc-linux --prefix=/usr/local/ppctools --enable-languages=c,c++ --disable-threads でconfigureし、makeを実行すると、以下のようなメッセージ (libstdc++のconfigure中でのメッセージ)が出力されます。

checking for fwide...     117 [main] sh 1777445 fork_copy: user/cygwin data pass 2 failed, 0x9F0000..0xC0C000, done 0, windows pid 4293328487, Win32 error 8
./configure: fork: Resource temporarily unavailable
 421275 [main] sh 1777445 fork_copy: user/cygwin data pass 2 failed, 0x9F0000..0xC0C000, done 0, windows pid 4293214591, Win32 error 8
./configure: fork: Resource temporarily unavailable
make: *** [configure-target-libstdc++-v3] Error 1

メッセージからfork_copyをgrepで引っ掛けて、 cygwin-snapshot-20020923-1/winsup/cygwin/fork.ccが関係あり そうなので見てみました。 因みにこの後、他のWinアプリケーションを起動しようとすると、 メモリが不足していますなどのメッセージを出して起動できない 場合があり、Windows自体を再起動する必要がありました。

fork.cc:98行目のWriteProcessMemory()の実行に失敗した様子。 で、WriteProcessMemory()はWinAPIらしいのですが、手元のAPIリファレンス はGUIのAPIしか載っていなくて詳細は不明。それはともかくとして、 fork.ccのソース中105行目に

    98            int res = WriteProcessMemory (pi.hProcess, here, here, todo, &done);
    99            debug_printf ("child handle %p, low %p, high %p, res %d", pi.hProcess,
   100                          low, high, res);
   101            if (!res || todo != done)
   102              {
   103                if (!res)
   104                  __seterrno ();
   105                /* If this happens then there is a bug in our fork
   106                   implementation somewhere. */
   107                system_printf ("%s pass %d failed, %p..%p, done %d, windows pid %u, %E",
   108                              what, pass, low, high, done, pi.dwProcessId);
   109                goto err;
   110              }

などと書かれてたり(汗;どうしてくれよう。 とどのつまりWriteProcessMemory()が失敗する事は本来あり得ない という事らしい。でも実際に失敗しているようなのですが(^^;
以前の記録( 2002/07/26, 2002/07/27, 2002/07/28, 2002/07/29, 2002/07/30) を眺めてみると、binutilsなどのconfigureが軒並みfork()問題で ずっこけてたので、その時にもCygwinソースを拾ったのですが結局 詳しくは見ないで、この頃更新されたbashを使うと何気に大丈夫に なったので良しとしたらしい。

configureで起こる話なら他からも報告されているのではなかろうかと 思い、Cygwinホームから MailingListのアーカイブページを辿って、 fork_copyで検索をしたところ、同じようにgcc-3.2のconfigureや 他のツールでのconfigureで同様のfork_copy()でのずっこけ 報告が上がっている模様。でもそのリプライは特に無し。 原因だとかはまだ詳しく追求されていないのかしら?

2002/09/28

昼頃起きて休出。

風邪気味で死亡。

2002/09/27

日付け越え前に帰着。

少しディスクの整理。
gcc-2.95.2ではどうかと--enable-lannguages=c,c++でconfigureして makeを実行。libioのmakeで

/cygdrive/c/tane/develop/linux-kernel/gcc-2.95.2/gcc/xgcc -B/cygdrive/c/tane/develop/linux-kernel/gcc-2.95.2/gcc/ -B/usr/local/ppctools/powerpc-linux/bin/ -c -g -O2 -I. -I. -D_IO_MTSAFE_IO iogetline.c
In file included from libio.h:166,
                 from iolibio.h:1,
                 from libioP.h:47,
                 from iogetline.c:26:
/usr/local/ppctools/lib/gcc-lib/powerpc-linux/2.95.2/../../../../powerpc-linux/include/bits/stdio-lock.h:29: #error libio needs recursive mutexes for _IO_MTSAFE_IO
make[1]: *** [iogetline.o] Error 1

となってエラー。うーむ。

2002/09/26

少し早めに帰着。

povray3.5をppcクロスコンパイルしてみる事に。所が、以下の コンパイルエラーでコンパイルできず。

src> make
powerpc-linux-g++ -DPREFIX=\"/usr/local/ppctools\" -DPOV_LIB_DIR=\"/usr/local/ppctools/share/povray-3.5\" -DCOMPILER_VER=\".Linux.powerpc-linux-gcc\" -DSYSCONFDIR=\"/usr/local/ppctools/etc\" -DUSE_IO_RESTRICTIONS=\"\"     `if [ "Xpowerpc-linux-gcc" = "Xgcc" ]; then echo "-Wno-multichar"; fi ` -O3 -c atmosph.cpp
In file included from frame.h:56,
                 from atmosph.cpp:31:
config.h:43: algorithm: No such file or directory
atmosph.cpp:50: algorithm: No such file or directory
make: *** [atmosph.o] Error 1

どうやらC++コンパイル環境がなっとらんというだけらしい。 で、configureするときにenable-languagesをcだけに していたので、c,c++に変更してconfigureし直し。そしてmake。 でも、gccアーカイブ内に含まれるC++ライブラリのconfigureに 失敗。configureスクリプト内でforkできず。ガックリ。 メモリを足す以外の方法は無いのか......

ミネルバ。人質救出ミッションでは完全に敵を抑えてから 人質を連れまわる。そんな感じで4章目突入。

2002/09/25

少し早めに帰着。

ppcsimいじり。先日、open()のフラグは同じと書きましたが、 全然違っていました(汗; stat()には何も秘密はありませんでした(^^; glibcでいう所のopen(int fd, int FLAGS, mode_t MODE )のMODEだけを見て ましたよ。で、フラグのすげ替えを追加。newlibとglibc では微妙にフラグがずれている為、glibcでの全フラグを 判定してnewlib(Cygwinネイティブ)に変換する必要がありました。 取りあえず終了。で、povrayでの出力画像も正しく書き込まれた 模様。djpegでも出力ファイルが既に存在している場合に、 それよりもファイルサイズが小さくなる結果がそうならなくて謎な感じを 醸し出していましたが、それも出力open()のフラグがへぼって いたからという事でした。あと、povrayの実行時間結果表示が スゴイ時間になっていたのでこれも調査。結果、time()は time_t time( time_t *RESULT ) というプロトタイプなのですが、 glibcでは*RESULTの方を使用しているようで、これはCygwinネイティブ で実行したままの結果が格納されていたため、正しくはエンディアンを ひっくり返す必要がありました。newlibでは戻り値の方を使用している 為か、こちらはOKでした。うーむ。
Linuxバイナリ実行オプションを付けたり色々。実行時間的 にはnewlibのそれと殆ど変わらず。povrayではライブラリでの 実行が占める割合が小さいと思われるので、コンパイラが 同じだと、ほぼ同じシミュレート時間になるのでしょう。

ミネルバ。人質救出ミッションで人質の一人を引き連れて 敵の群れの中、応戦していたら救出した人質がいきなり 目の前に動いて来て弾が当たって死亡。うぉい!じっとしとれぃ!!

2002/09/24

日付け越え前に帰着。

ppcsimいじり。ioctl()は実装の仕方が思いつかず、試しにスタブ に実装してみました。取りあえず先には進み、povrayのレンダリング は実行されている模様。しかし、ファイルへの書き込みがうまく 行えていないみたい。書き込み時はファイルのopen/closeを 繰り返し、appendモードで追加書きしているのですが、 llseek()の戻り値が0になっているのが原因っぽい。でも何故 0になるのか不明。newlib版のpovrayでもtrussを仕掛けて 眺めてみましたが、特にopen()のフラグが違うという事も 無さそう。newlib版ではfstat()を実行していて、glibc版 ではfstat64()(実際にはnewlib版のfstat()と同様Cygwinネイティブ のfstat()を実行している)を実行しているのですが、これに 何か秘密があるのかしら?

2002/09/23

午後起床。特に何をするでもなく。TVなどを観たり。

ちょこーり本屋にお出かけ。何気に探していたけど見つから なかったラクガキ王国の攻略本を発見。パラパラと眺めてみた けど、ゲーム中に入っているラクガキキャラのパラメータが ひたすら載っていたり。こんなの役に立つのかなぁと思いつつ、 描き方の攻略のところを眺めていると、回転オブジェクトと その回転方向の制御について書かれていました。どうやら 始点から最初に向かった ベクトルの外積に回転するらしい事が判りました。そんな感じで 買わずにそっとその場に戻す(^^;。

そろそろ涼しくなってきたので、表紙絵を変えてみたり。

2002/09/22

午前中に起床。今日はKOJIさん達と飲みの予定でしたが KOJIさんが風邪を召してしまったようなので取りやめ。残念。

ミネルバ。イライラしながらも思いのほかはまってみたり(^^; たかがアイドルゲームかと思いきや、名前だけ出しとけばOK みたいな感じではなく割ときっちり作ってある様に感じました。 折角なのでシステムなどを説明してみると、大雑把には コンピューターサバゲーって感じ(大雑把過ぎです)。
アリシア(藤原紀香がモデルのCGキャラ)率いる 3人×3チームのその他の人で構成される超法規対アンドロイド 制圧部隊A.A.A.(Anti Android Attackers)が様々なミッション を遂行するっていうミラクルドッキン大冒険です(ぉい。
基本は見付けた敵(ロボ)を撃ち壊せば良いのですが、双眼鏡 で覗いて敵をマークすることで、その他の人が一斉に位置を知る 事ができるため、その他の人が自動的にマークした敵に攻撃を 加えて敵を撃ち壊す事もできます。 その他の人も「捜敵(コンピュータによる敵の自動マーキング)」 と「攻撃」の二つの状態を持っていて、これはプレーヤ自身が 命令という形で指示します。その他の人はチーム毎に 行動を切りかえられるので、例えば最初はチーム総がかりで 敵を探させて、順次敵が見つかってきたところで一斉に攻撃 指示で攻撃するもよし、1チームを捜敵専門にして2チームを 攻撃専門にするもよし、うまくいけば見てるだけでOKという 事になるかも知れません(実際には味方の動きがチョンボすぎて うまくいきませんが)。
勿論マークをしなくても敵への攻撃はできますが、その他の人には 敵の位置が判らない為、敵一匹くらいならすぐ叩いちゃえ などとマークを怠ると、いつのまにか敵に囲まれて 四方から射線(赤いレーザーの標準)が向いているという ピンチ状態に陥ります(でもマーク無しなので援護されない)。 こうなったら猛ダッシュで逃げまくるなり、味方に寄って盾にするなり (ひでぇ)の作戦(なのか?)でピンチを回避します。 このような鬼ごっこ的な要素が面白いと思いました。
やった事はありませんがメタルギアソリッドもこんな感じ なのでないかと想像します。ただ、あちらの場合は一発の弾 が色々な意味で重い感じがするので、敵に見つかる事はすなわち 死を意味するという点で、サバゲーよりも「かくれんぼ」の要素が 強いと想像する(だから潜入ゲームと銘打たれている?)のですが どうでしょうか。 メタルギアは個人的にはゲーム性の好き嫌いよりも、リアリティを 追求した分、接近戦では敵の背後に周ってナイフで喉をひとかき といった感じの、表現が血生臭い点にイマイチ食指が動かず、 やらず嫌いの理由だったりします(^^;。それに比べれば ミネルバの方は、倒した敵が一定時間で消えるとか、結構撃たれている のに元気に動けるだとか、現実だと不自然に見える映像表現部分も ありますが、その点はゲームだからと割りきれる程度に、 軽めに楽しめる様に作られていると思います。
そんな感じで、敵を倒す為に乱射してたら人質もろとも殺っち まったり、仲間に攻撃指示してたら人質に弾が当たりまくりで 救出する頃にはぐったり気味だったり、色々ありましたが 人質救出ミッションクリア。現在、やっとこさ三章目に突入。

2002/09/21

昼頃起床。休出。

飯を食べながら「モンスターズ・インク(DVD)」を鑑賞。 なんでこんなに柔らかい動きを付けられるのか不思議。

ついでに買ってきた「プロジェクトミネルバ」ぷれーい。 パッケージの「戦闘に、リアリズムを。」というあおりとは 関係無く、手榴弾使いたい放題だったり、リロードはある ものの撃ち放題のマシンガンだったり、こんなに まっ平らな所じゃ撃たれまくりだろうなステージがあったり だったり、9人も仲間の部隊(プレーヤ指示により動く ノンプレーヤキャラ)を引き連れているのに、敵への攻撃を 任せておくといつまで経っても敵をしとめられないしと、 色々言いたい事はありますが、藤原紀香のCGが良く似ている という点だけでアイドルゲームとしては合格でしょう(ぉい。 地形が立体になってくる人質救出ミッション辺りから 面白くなってくる(と個人的に思う)のですが、如何せん 仲間の部隊の動きがチョンボ過ぎてイライラしている最中 です(^^; 突入は二手に分かれて一気に叩くだろうっ! つーか、突入前に敵の数と人質の位置を把握しとけっ!! くわっ!!!(ぉい;;

アヴリル・ラヴィーン。何度聞いても覚えられないのは 歳のせいですか?

2002/09/20

会社飲み会後、日付け越え帰着。

眠くて死亡。

2002/09/19

日付け越え前に帰着。

llseek()は、2GBを越えたアクセスは行わないという制限を付けて 実際にはlseek()を実行するようにインプリメント。戻り値は 64bitに符号拡張して返すというしかけ。取りあえずllseek()は通過 したのですが、まだ実装されていないioctl()を実行して停止。 さて、どうしたものか。

2002/09/18

日付け越え。

llseek()の実装の前に64bit変数の引数の渡し方を調べてみたり。 以下のようなCコードでは、

10000338 <add>:

long long add(long long a, long long b)
{
    return(a+b) ;
10000338:       7c 84 30 14     addc    r4,r4,r6
1000033c:       7c 63 29 14     adde    r3,r3,r5
}
10000340:       4e 80 00 20     blr

という命令列になり、 引数は、r3とr4,r5とr6.....というようにペアで使用して、 戻り値はr3とr4をペアにして64bit引数として渡しているらしい。 でも、llseek(int,off64_t,int)という型に対して、

100ab5ac:Syscall_NO=140
  pc=100ab5ac : Unknown SystemCall Number(140).
d r
PC    : 100ab5ac  MSR   : 00000000  SPRG0 : 00000000  DEC   : 00000000
CR    : 20000828  SRR0  : 00000000  SPRG1 : 00000000  TBU   : 00000000
XER   : 00000000  SRR1  : 00000000  SPRG2 : 00000000  TBL   : 00000000
LR    : 100ab578  HID0  : 00000000  SPRG3 : 00000000  FPSCR : 00000000
CTR   : 1009faf0  HID1  : 00000000  SDR1  : 00000000
GPR   : 
00-07 : 0000008c 007fec70 00000000 00000005 ffffffff ffffe0d4 007fec78 00000001
08-15 : ffffffff 00205198 00001f2c ffffffff ffffe0d4 1011c6b0 00000000 00000000
16-23 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 10110000
24-31 : 00000000 10110000 10117f70 ffffffff ffffe0d4 20000828 00000001 00205198

という感じになっているようなのですが、r3は第一引数の intとして、第二引数の64bit引数はr5-r6のペアよりも、r4-r5ペアの 方が確からしいように思うのは気のせい?どういうルールで 64bit引数の境界がきまるのかイマイチ不明。

2002/09/17

日付け越え前に帰着。

dcbz命令を適当にインプリメント。memset()の実行をトレース してみると、32byte飛びにメモリアドレスを触っているよう だったので、32byteがキャッシュブロックの単位と推測。 指定されたEAを32byte境界に丸めて、そのブロックを0クリア するような動作にした所、djpegの変換チョンボが直りました。 ふぅ。
デバッグのため引数をメモリ上に直接セットしていましたが、 変更が面倒なので、現在のexecコマンドで自動セットする 機構を流用してexecコマンドで実行できるようにしてみたり。 スタックの先頭とargポインタが重なっているのがまずくて いきなりlibc_startからずっこけてみたり。スタック開始 位置をずらしてOKに。
そんな訳でpovrayをコンパイルしてみることに。コンパイルは 一発で成功。でもUnknownInstruction(汗; mtfsfi命令が無いと いう事で追加。次はUnknownSyscall No140 でllseek()が無い。 うーむ、こりゃちょっこりした修正ではダメかも。

2002/09/16

朝ふつーに起きたり。でもぐうたら過ごしたり。今日は寒くて 動けない(<動物かよ)。

djpegの件を調査する為、ppcsimのレジスタダンプに少し手を 入れたり。あと、小さいデータについては500x8pixのデータで 再現した模様。dct変換で変換結果を出力する部分に網を かけて、newlib版と比較してみた所、変換結果の手前の 係数バッファの方が期待値と違うことが判明。でも力尽きて そこまでで死亡。

斑鳩。やっぱNORMALだと全然ダメ。でも、ただ待っているだけ の個所があったりで最初の方は結構退屈なEASYよりは なんとなく面白い気がしてきた。

djpegの続き。なんとなく原因判明。どうやらmemset()で 領域クリアを行っているのですが、その際にdcbz(キャッシュ ブロッククリア命令)を使って、ハードウェア機能で 一気にクリアしているようです。所が、ppcsimではnopにインプリメント していたためメモリクリアされず、結果、妙な値を参照して ヘンテコになっている模様。うーむ、しまった。
キャッシュブロックの定義がイマイチよく判らなくてnop インプリメントにしていたのですが、実はLinuxカーネルを 動作させる時もこれだとマズかったのかも.......

2002/09/15

夕方頃起床(滝汗;;。

djpegの件。コンパイラのオプティマイズレベルを下げても状況 変わらず。ますますシステムコールエミュレーションかglibcの コンパイルに問題がありそうな予感。
小さいデータでの再現にも成功せず。ピンポイントなのか?

斑鳩。フリープレイになった模様。今までEasyでやってましたが NORMALをプレイ。無理っす(笑。もう既に4面とかどうやって避ければ よいのか判らないのですが。特にボス。あの電磁ヒモみたいのが、 白黒変わって出ている時点で避けられる気がしません。なんか このゲーム、4面が妙に難しく作られている様に思うのは気のせい でしょうか。

そういや「バッチリ」って単語がありますが、これって日本語 なのかしら?とふと思ったり。
gooの辞書で検索したところ、

■[ばっちり]の大辞林第二版からの検索結果   

ばっちり  
 
(名)家具などの開き戸を框(かまち)枠に固定する金具。キャッチャー。ぱっち。
(副)「見事に」「十分に」「うまく」などの意で俗にいう語。「―きまった」「この本があれば試験なんて―だ」「旅行の費用も―稼いだ」  

という事で(副)の方という事は判りますが、語源は不明。

2002/09/14

昼頃起床。休出。日付け越え前に帰着。

djpegの結果が違う件の調査。8x8pixとかサイズの小さなデータ での再現を試みました。結果、再現せずでNG。うーむ。

ppcsimのソースをちょこーりいじったり色々。

2002/09/13

日付け越え。

眠くて死亡。

2002/09/12

日付け越え前に帰着。

斑鳩。ラスボス一つ前の奴は吸収したらすぐに力の解放をかまして 裏返せば良いのですが、やっぱうまくゆかず。力の解放をRトリガ に割り当てるのは失敗かも。クレジットがいつのまにか増えていて なんとかクリア。ギャラリー2オープン。でも4面ボスは倒せない まま。Easyでも1コインクリアは無理じゃ(^^;

2002/09/11

日付け越え前に帰着。

斑鳩。ラスボスと思ってた奴はラスボス一つ前だった模様(^^; ゲーセンでクリアしているのを見た時はラスボスよりも一つ手前 の奴の方が印象に残っていたかららしい。クリアできず。
お試しモード1コインクリアに挑戦。なんとか成功してギャラリー モードオープン。

2002/09/10

日付け越え。
帰り道、車道に向かって足を伸ばして路肩に座る女子一人。 そんなところに座ってると車にひかれるぞと思った。

2002/09/09

ぐったり気味で病人状態。

2002/09/08

昼頃起床。夕方頃ちょこーり出社。

先日のdjpegで結果が違う件を調査。取りあえずLinuxネイティブバイナリ 生成環境をgcc-3.2にして、glibcも再コンパイルしてみました。gcc-3.2 はgcc-2.95.2と同じconfigureオプションでconfigure実行すると、 threadサポートがされていないという 旨のエラーメッセージが出てmakeに失敗。--disable-threadsを付けて configureを実行するとmakeはエラーなく終了しました。glibcは gccのバージョンチェックで引っかかってconfigureでエラー。 gcc-3.2だとバージョンが新し過ぎるようで、configureスクリプト のバージョンマッチ部分に少し手を入れてconfigureし直すとOKでした。 gcc-2.95.2では.exeが付いていましたが、3.2では.exeは付かない為、 ネイティブ実行ファイルのリネームは不要で、make installも エラーなく終了しました。
で、djpegをmakeし直して実行......結果変わらず(T_T)。 newlibを使用するコンパイル環境とgccのバージョンが同じなので、 コンパイル結果は同じハズと、*.oファイルをディレクトリ単位で diffってみた所、main()入り口のスタックのサイズなどに多少の 違いがあるものの、DCTなどのコアは全く同じコンパイル結果となっています。 という事は、Cライブラリもしくは実行ファイルのロード方法に問題が ありそうな予感.......

斑鳩。Easyの5面モード。総プレイ時間が1H増える毎に1クレジット 追加される模様。現在6クレジットで、ラスボスまでは辿りつく ものの、最後の白黒をリズミカルに切りかえる所がうまく行かず に死亡。因みにDC版には練習モードがあり、面クリアするとその面の練習 ができるようになるのですが、ボスをやり過ごしてしまうと、 面クリアとみなされないようで、4面の練習をしたいのですが、 ボスを毎回やり過ごしてしまうため練習が全然できません。 4ボスで残機を吸い取られるのに、これじゃぁいつまで経っても うまくならないですよ(笑。そういや取り扱い説明書にストーリー が書かれていたので読んでみたのですが、何だかよく判らない ストーリーでした。

2002/09/07

昼頃起床。最近起きると首が痛くて回らない事が多い。なんか いやんな感じ。

ふにゃふにゃとLinux用実行バイナリを動作させる為に システムコールを追加。PSIMでエラーするmmap()を実行するまでに getuid()とかbrk()とか結構実行されていたりして。戻り値の 期待値が判らなかったので、PSIM上でブレークポイントを 設定しながら期待値をハードコーディングしてみたり。で、 問題のmmap()はsbrk()を流用して騙してみることにしたのですが、 mmap()実行の後に、何故かすぐにmunmap()とか実行されてて本当に 大丈夫か?という感じ。 引数無しのcjpegを実行した所、fstat64()を実行した所で停止。
しかたないので、argc,argvをメモリにセットするなどごちゃごちゃ やって、cjpeg --help を実行した所なんとかヘルプメッセージを 実行する事はできました(^^;v。うーん、cjpegごときでここまで てこずるとは。まだまだ修行が足りません。

DC版「斑鳩」。一応チェックしてみました。えぇ。 元がNAOMIベースなので、全く同じに移植できるハズではありますが 、非常に移植度は高いと思います。横長モニタだと 75%表示となりますが、元がポリゴンベースで作られている為、 ほぼ問題無く縮小されているといった感じです。この辺は、 サイヴァリアや式神の城(これはちょっと別かも)などでは実績の ある所なので、まぁOKかなといった所。むずかしさもそのまま。 何故か3クレジットしか入っていない為、コンティニューは 3回までです(^^; 従って、私の場合は練習必須(T_T)。 非常に良くできていると思いますので、思い入れのある人は 買いかも知れません。敢えて言わせてもらうなら 「何故今頃DCで、なのですか!」 (サク

Auge.さんところより マルチリンガル化について。なるほど(^^; でも個人的には、これって それほど悪い方法ではないかもと思います。というのは、結局の所、 マルチリンガル化=自動翻訳化 と考えたとすると、メッセージ出力に 翻訳機能を付けたと考えれば良いかも知れません。もし プログラムによる究極の自動翻訳が実現したならば、多分、メッセージ 出力部分を置きかえるだけでOKかも(笑。まぁ、文字コードの違いですら、 混乱している今の時点では遠い未来の話かも知れませんが。

本屋のエロマンガコーナーの一角で、よりエロそうなマンガを 漁るギャル風女子二人。

なんとか騙してdjpeg本体を動かしてみました。途中、ヘンなオプション を指定して、bashもろとも無反応になったり色々。で、どうにか動いた のですが、何か違う(汗;。絵が崩れていますよ.......うーん、 昔このような模様を見た覚えが......なんか乗算系の間違いのような 気分。そういや去年、乗算にバグが見つかって 修正したのを思い出しましたが 何かミスってる?

2002/09/06

日付け越え前に帰着。

先日makeしたPPC-Linux用実行バイナリをppcsimで実行してみました。 未サポート命令の実行でずっこけたり(^^; という訳で mffsx,mtfsfx,mtfsb1x,mtfsb0xを追加。で、SyscallNo.49を実行 してUnknownSyscall。geteuid()ですか。命令アドレスの後ろに、 No.47=getgid()とかNo.50=getegid()とかを実行するコードが 入っているので、この辺をどうにかしないとダメかも。因みに ここまでで、たった110命令しか実行していませんよ(^^;

宇多田ヒカル電撃結婚。

2002/09/05

日付け越え前に帰着。

gcc再ビルドが終っていたので、通算三度目のcjpegのmake。 リンクOK(^^)v。.exeが付くのが気に入りませんが、まぁよしと したところでしょう。ライブラリの全てにシンボルが入っている ようなので、実行ファイルサイズが1.6MBもあるのにちょっと驚き ましたが(^^;
早速、PSIMで実行した所、以下のような感じ。

jpeg-6b% ../gdb.exe --quiet cjpeg.exe 
(gdb) target sim -e linux
Connected to the simulator.
(gdb) load
(gdb) run
Starting program: /cygdrive/c/tane/develop/ppctest/gdb_test/jpeg-6b/cjpeg.exe 
do_call() unimplemented call mmap

(gdb) where
#0  0x1001b57c in mmap ()
#1  0x10016a64 in new_heap (size=32768) at malloc.c:2027
#2  0x10016c6c in arena_get2 (a_tsd=0xfff, size=2097152) at malloc.c:2157
#3  0x10016eb8 in __libc_malloc (bytes=0) at malloc.c:2725
#4  0x1001670c in malloc_hook_ini (sz=8, caller=0x200000) at malloc.c:1766
#5  0x10016dc0 in __libc_malloc (bytes=0) at malloc.c:2701
#6  0x1002306c in _dl_important_hwcaps (platform=0x0, platform_len=2097152, 
    sz=0x1007ea68, max_capstrlen=0x62) at dl-support.c:189
#7  0x1001c228 in _dl_init_paths (llp=0xdffffc58 "/usr/local/cygjava/lib")
    at dl-load.c:579
#8  0x10022f2c in non_dynamic_init () at dl-support.c:143
#9  0x10023ffc in __libc_init (argc=1, argv=0xdffffa00, envp=0xdffffa08)
    at set-init.c:23
#10 0x10023f44 in init (argc=1, argv=0xdffffa00, envp=0xdffffa08)
    at ../sysdeps/unix/sysv/linux/init-first.c:92
#11 0x10023f78 in __libc_init_first (argc=0, argv=0x200000, envp=0x0)
    at ../sysdeps/unix/sysv/linux/init-first.c:119
#12 0x10011688 in __libc_start_main (argc=1, ubp_av=0xdffffa00, 
    ubp_ev=0xdffffa08, auxvec=0xdffffa98, rtld_fini=0, stinfo=0x1005d490, 
    stack_on_entry=0xfff) at ../sysdeps/powerpc/elf/libc-start.c:100

むぅ、mmap()か........

よく見てみると、heapの割り当てにmmap()を使用している様子。 てっきりファイルやIOのメモリマッピングだけに使用するものかと 思いきや、確かにmmap()を使用すればスワップ機構も自動的に 包含する形になりそうなので、一石二鳥の使い方という気が します。そんな感じでPSIMでのアプリケーションレベルのクロス開発 は今の所、うーむ な感じ。NetBSDのシステムコールエミュレーション ならばmmap()が実行できたりするのかなぁ.......

2002/09/04

日付け越え前に帰着。

gccの再ビルドを仕掛けていたのが終了していたので、これで 再構築完了のハズ。という訳でリンクに失敗していたcjpegをmake した所、リンクでそのままハング(汗; 強制電源切断→scandisk。 なんだかなぁ。
リンクパスを確認した所、古いダイナミックリンクライブラリを しつこく参照しているようだったので、ライブラリをさっぱり 消し去って、再度glibcをmake installを実行しなおしたところ、 何故か全コンパイルが始まったり(汗; gccを再ビルドしたせいなのか?

glibcのmake installを終えた後、gccの再ビルドを仕掛けて寝る。

2002/09/03

日付け越え前に帰着。

先日の続き。結局gccを2.95.2まで戻したけどNG。elf/dl-machine.oの makeに失敗していて、実体である所のsysdep/powerpc/dl-machine.cで DO_VERSIONINGがdefineされていなくてエラーって感じ。でも、 プリプロセッサでDO_VERSIONINGをチェックしている以外では、 ソース中で参照されていないようだったので、チェック自体をコメント アウトして先に進めました。前もやったかなぁ?
その後、make allはエラー無く終了。あれぇ?もっと色々引っかかってた ような気がしたのですが.......で、make installしたらNG。でも 今回は少し様子が違っていて、iconvなどLinux powerpcネイティブで動作 するバイナリの生成はできているようです。何がまずいかと言うと、 powerpcネイティブなバイナリファイルに.exeが付いている事(^^; iconv/iconv_prog.exeをiconv.newとしてinstallして、その後 iconvにmvしなおしているようですが、iconv.new.exeとiconv.exe になっている為、エラーで停止しているようです。なので、 一番元になるiconv_prog.exeをiconv_progにリネームしてから make installすると先に進みました。他、 locale/localedef,locale/locale,catgets/gencat, debug/pcprofiledump,login/pt_chown,sunrpc/rpcgen, elf/sln,login/utmpdump,sunrpc/rpcinfo, elf/sprof,nss/getent,timezone/zdump, io/pwd,posix/getconf,timezone/zic もそう。うーむ、いちいち.exeが付くのが謎と言えば謎なのですが.....
他、infoのinstallでもずっこけたため、mkinfoでエラーが出ないように 適当に直してどうにかインストール完了。gccの再ビルドをしかけて 寝る。

2002/09/02

日付け越え。

glibcの再コンパイル。今回は--disable-sharedと--disable-profileを 付けたので、コンパイル時間は1/3になるハズ。と思ったら、前は 起こらなかったような気のするエラーが出てNG。前回makeしたディレクトリ をmake cleanしてconfigureしなおしただけなのに。むー、なんで?

2002/09/01

昼頃起床。あぁ、もう9月ですか.......

ExcelとPowerPointのファイルを家のパソコンで 読み書きできるといいなぁという事があり、久々に秋葉原に向かい、 Microsoft Officeがどのようなものなのかを見てみました。 17,000円くらい........っていうのはアップグレードの方で、 フルセットのPersonalで 約50,000円、 Professionalで 約60,000円 ......一時間ほどどうするか考えるのに散策した後、 やっぱいいや。って事で解決(<になってるのか?)。 つーか、50,000円ならば他に買いたいものがあるので、 そこまで必要なものではないという判断(^^;。でも、 Office系ソフトがプリインストール済みのノートパソコンなんかは 思いのほか、お徳なのだなぁと思いました。
因みに、開発系のソフトウェアはやっぱり高くて、100,000円 オーダーのものが沢山。ちょっとプログラムの勉強がしたいと いうのには高過ぎる予感。フリーソフトで色々できるというのは ある意味幸せ。感謝しながら使わなくてはいけないなと思いました。

KOJIさんとお話。今日現在ではコンテンツは無いですがドメインは通った 模様。


TOP PREV