昔の最近の出来事(2001.02)

2001/02/28

日付け越え。

なにげにgslのコンパイルを試みてみました(Cygwinネイティブ)。 cvsから最新を拾ってみたのですが、configureが見あたらず謎だった のですが、autogen.shを実行すればよさげだったので実行。ところが、 libtoolsが無いような事をいってずっこけたので、libtool-1.3.5を 拾ってきてコンパイル＆インストール。再び実行すると、今度はなにやら 文法がよろしくないといいながらconfigureを生成するものの、その configureはエラーでずっこけます。げふ。
binutilsをcvsアップデートしてみたのですが、PDP-11なんかのアップ デートが行われているという事実に驚いてしまいました。エミュレー ション関連でしょうか？

とかやっている間に、二回ほどHDDの回転が止まる様な音がするし(汗; スキャンディスクを実行するたびに、ファイル救済が行われますよ。

少し早めに帰宅。つっても日付け越えなので、ここ数日よりも早いだけ ですが。

先日のsrawiの件、勝手に読みかえてそれっぽく動いていましたが、 ご指摘をいただき(Thanks Auge.さん)、考え違いをしていたので修正。 修正をミスってずっこけていましたが、しょーもないチョンボをか ましていただけで、そこを直すと動くようになりました。チョンボ箇所 をつきとめるのに、レジスタダンプ関数の仕様を力一杯変更するなど、 ppcsimのソースは思いっきり変わったりしたのは秘密。

日付け越え。30分オーバーが平均になってきているのがよろしく無いです。

先日のsrawi(およびsraw)を「PPCプログラミング環境マニュアル」で 動作を確認しました。負数の時のフラグがシフトアウトすると、XER[CA] がセットされるという事の様です。除数が2のべき乗の式の場合は、 srawi+addzeの対で命令列が生成される様です。これは、非除数が-1の様な 場合、hexで0xffffffffとなる訳ですが、これを2で割ると結果は0になります。 このとき、srawiの結果は0xffffffffなのですが、XER[CA]=1となっている 為、addzeを実行する事で0になるという仕掛けの様です。
この様な命令列は、今までにも出てきてそうな感じがしますが、次の様な 簡単な例の場合、

int calc(int a)
{
     return( a/2 ) ;
}

calc:
        srwi 0,3,31  /* rlwinm rA,rS,32-n,n,31 のエイリアス*/
        add 0,0,3
        srawi 3,0,1
        blr
.Lfe2:
        .size    calc,.Lfe2-calc
        .ident  "GCC: (GNU) 2.95.2 19991024 (release)"

calc:
        srawi 3,3,1
        addze 3,3
        blr
.Lfe2:
        .size   calc,.Lfe2-calc
        .ident  "GCC: (GNU) 3.1 20010220 (experimental)"

起きて、休出前にデバッグ。遂に現場を掴みましたよ！という所で出社。
の前に、HDDをゲットしてみました。 暇を見てはスキャンチェックを実行しているのですが、毎回なんらかの ファイルがサルベージされているので、遂にというかやっとというか。 40GBのベアドライブ。でも付ける暇とか無し(＜それじゃ意味も無し)。

土日と日付け越えは辛いんですけど。


で、デバッグ。ちゅうか、確認。

      png_stride *= (opts.OutputQuality + 7) / 8;
   59838:	3f e0 00 0d 	lis	r31,13
   5983c:	3f a0 00 0e 	lis	r29,14
   59840:	3b bd 21 20 	addi	r29,r29,8480
   59844:	81 3d 00 0c 	lwz	r9,12(r29)
   59848:	39 29 00 07 	addi	r9,r9,7
   5984c:	7d 29 1e 70 	srawi	r9,r9,3
   59850:	7d 29 01 94 	addze	r9,r9
   59854:	80 1f 66 50 	lwz	r0,26192(r31)
   59858:	7d 29 01 d6 	mullw	r9,r9,r0
   5985c:	91 3f 66 50 	stw	r9,26192(r31)

休出。2時間オーバー。ぱた......

なにげにおかしなPNGデータを拡大して眺めていたら、1ピクセル飛びになって いる事に気づきました。ということは、PNGへ渡すバッファへの変換に問題が あるって事？今まで見ていた所のずっと手前なんですけど(大汗;;

日付け越え。1時間オーバーで死にそうです。(X_X)

先日-g付きでbssセクションをクリアしたら動いたハズだったのですが、 いきなり再現しなくなってしまいました(汗; なにか手順を間違えていた のかしら？
gccをアップデートしてみたのですが状況変わらず。げふ。
binutilsをアップデートしてみたり。特に変化無し。

日付け越え。つーかいつもより30分もオーバーしていてへこり。

通過している関数を調べてみた所、若干通り方が違う模様。うむ、これを キーにして絞り込みをしていきますか。
それよりもHDDが不安なので、週末にHDDをゲットしたい所。

日付け越え。

ちょっとデバッグを始めた所、HDDからいや〜んな音が。つーか、「カツっ」 とか音を立てて、一瞬止まっているんですけど(汗;　機嫌の悪い日は朝食を 食べない。そんな感じ(全然判りません)。調査進まず。スキャンディスクを しかけて、GIGAWING2をやって寝ました。「ななちゃん！」。はぁ。

日付け越え。つーか、だんだん会社に居る時間が既に日付け越えるように なってきたのですが(汗;

そんな訳で今日は何もできづ。

日付け越え。すげー眠いです。

原因調査を行なっている最中、またしてもディスクのいやーんな音が。 とかやっていると固まってしまったり。へこり。また不良セクタが増殖 した模様。今度は、いままでとかなり離れたセクタなのですが、円心上 では隣なのでしょうか。ともかくガンが転移している様な感じ。 余命幾ばくもないのでは。

遂に調子が悪くなって一回休み(x_x)

なんだか正しいのとそうでないのとで通っている関数が違うっぽい予感。 でも調子悪くていまいち判断できず。寝る。

復帰して雑用色々。エアコンをつけているにも関わらずあまりにも寒い ので、ふすまの隙間を目張りする事にしてみました。ずっと前に住んでいた ボロい寮は、ドアの下に微妙に隙間が開いていたのですが、隙間を塞ぐと全然 保温性が違ったという事がありました。大した事が無い様に思う様な隙間 も長い時間で見ると、随分と差が出る様です。 で、目張りアイテム(「戸当たりテープ」という商品名でした)をゲットして きて隙間を塞いでみました。現在体感温度測定中。今の所は良好な気分。

あぁ、同じ日付が二回出てきてますよ。

起きたら午後2:00でびっくり(^^; でもって休出。
日付け越え。

それとなく通っている所を目で追っかけてみましたが、特に得られるもの 無し。なにげにbssセクションを0クリアしてみた所、なんとうまくいくでは ないですか！！げふーーん。
で、デバッグの為libpngとzlibを -O0 -g でコンパイルしていたので、 -O2で再コンパイルして同じ様にbssセクションを0クリアしてみた所、やっぱ りダメな模様。ふ、深い........
因みにずっと前(2.95.2の頃)からpovrayのヘルプ表示がぶっ飛んだメモリ 領域をアクセスして例外でこけていたのですが、bssセクションを0クリア して実行する事でこの点は解決した模様。

日付越え。

ブレークポイントを設定してpng_write_row()の入り口から出口までの レジスタトレースダンプを取ったら、33MBのファイルになってしまいました よ。この間の命令数は約76000。ゲフ。
アタリは全くつかづ。

日付越え。

シミュ機能追加。ブレークポイントを複数設定できる様に改良。現在のppcsimは プロセスの概念が存在している為、プロセス毎に設定できる様にしてみました。 プロセスID毎に事前に設定できるので、子プロセスを生成するところまで含めて ブレークしたい場合でもOKです。ただ、設定したポイントリストの数ぶん 総当たりで比較しているので、実行速度は落ちます。本当はプログラム例外などを ひっかける様にすれば、ポイントリストの数に依存する様な事はなくなるのです が、メモリダンプをする場合や一時的に命令を書き換える場合の事などを考える と考慮すべき事が多くて、そちらのバグに悩まされそうなので、適当な所と いう事で。
確かX68kのgdbなどはブレークポイントを一時的にトラップ命令を置いて引っか けて、再実行時は命令を元に戻す様な事をしていると聞いた事があります。 ループで戻ってきた時にはもう一度引っかけないとダメなので、単純に元に 戻すという訳ではなく、ブレークポイントの命令を１命令だけ実行して、 次のアドレスから復帰するという事になるかと思われます。こうして考えてみると、 デバッガというのは開発が大変かも。デバッガ自身のデバッグはどうやって行う の？とか。やっぱりコンピュータの世界は再帰がかった事柄が多いようです。

日付越え。

デバッグ。取りあえず、povrayのpng_pov.c中のWrite_Png_Line()辺りから調査。 png_write_row(png_ptr, row_ptr)まではOKそう。floor()の値をCygwinネイティブ での結果と比べるなどしてみましたがOKそう。いかんせん、ブレークポイントを 一つしか設定できないのは面倒でいかんです。
って、今日はこんだけ(^^;

日付越え。眠いっす。

libpngとzlibを-O0 -gで再コンパイルしてみた所、やっぱりダメっぽい 感じ。コンパイラオプションに依存しないとなるとやはりシミュバグの 疑いが濃厚です。

なにげに CAPCOM の DC版GIGAWING2の公式ホームページ を見てみました。うちのメモリカードに入っているハイスコアと 二桁以上違うんですけどどういう事？ そんな感じ。上手い人のリプレイデータとかダウンロードできないのか しら？つっても、ドリパス３は封も切らずに引っ越しのどさくさに紛れて どこにしまったか判らなくなっちゃったし、そもそもまだ使えるのかどうか も不明なのでアレですが。あと、前のGIGAWINGの時は開発秘話みたいな のが上がっていたのですが、今回は無い模様。ちと残念。

どうやら「芹香さん」でBMP表示が可能になった模様。

遂に我が家にもウイルスメールと思わしきものが届きましたよ！(^o^) (＜喜ぶな) 多分、バレンタイン系列だと思われます。タイトルも差し出し 人も出なくて、PBOGGLPB.EXEとかいう実行 ファイルが添付されているだけという、どう見ても怪しい感じのメール だったのでちょっとドキドキでした(ぉぃ むしろ添付ファイル名を見るためにクリックしたメニューをうっかり 押し間違えて実行してしまいやしないか、そちらの方が心配でしたよ。

出社。終わらねーー。ぴんち。

ちょっこりコマンドを追加してみてplot_pixel()から調べてみました。 所が、驚愕の事実が発覚。この時点ではピクセルデータは全く同じでした。 はっ、 zlibとlibpngを再コンパイルした記憶がないや.....(滝汗;;;; 速攻でzlibとlibpngをコンパイルし直し、再リンク＆実行........ 結果変わらず。がっかり。 でも、ピクセルは同じだったのだからレイトレースパートは正しいハズ。 ということで、+FPオプションを付けてPPM形式で出力。適当にJPEGに 変換して見たところ、 結果はOKそうですよp(ToT)/ つまり、libpngもしくはzlibのコンパイル結果がどうにかなっていると いう結論に達しました。一気に不審な点が絞られたのは良いのですが、 zlibとlibpngですか.........setjmp関係かしら........ここも結構 難しいんだよなぁ.........
まぁ、newlib-1.9.xの不具合も見つかった事だし、その点はよしとした ものでしょうか。

ちょっこり出社.....のつもりがちょっこりでは済まなかったり(T_T)

デバッグのやり方を少し考えて、解決を試みました。

今までのsim動作のネイティブcc1やpovrayと違い、例外でずっこけて いるのではなく、データ化けである点が、今回のデバッグでの難しい所 だったりします。例外でこければ例外の起こっている箇所が悪い箇所付近 なので、その関数の入り口のデータをチェックする事から始めれば、 ポインタのオーバーランや以前のpovrayで発覚したリンカの不具合など で、知らぬ間に値が変わるという様な場合を除けば、非常に簡単に まずい所を直す事ができると思われます。まぁ、プログラム自体も 間違っている可能性があると更に難しくなる訳ですが、そこの所は 救いでしょうか(^^;

まず、再現パターンの絞り込み。取りあえず、+H,+Wで画像のサイズを調節 した所、+W2,+H1で結果が変わったので、これで攻めてみる事にしました。
続いて相違が発生している箇所の特定。一番てっとり早いと思われる関数の 戻り値を比較するという方法を試してみました。 PPCでの関数の戻りはGPR3もしくはFPR1を使用し、LRを使うblrを 使用して呼び出し元に返るという仕掛けになっています。シミュだとblrを 引っかけてレジスタダンプを取る様な事は非常に簡単にできますので、試して みました。結果、大量に通過する事となる訳ですが、ここで 一つの問題が。まず、void関数の戻り値がことごとく違う点。当然と言えば 当然なのですが、これは多分見てもしかたありません。void関数をCソース から適当な方法で抜き出し、それについては結果をチェックしない様に しました。しかし、また次の問題発覚。戻り値にポインタを返す場合があり ますが、これがコンパイラによる変数割付けアドレスの違いがもろに 見えてしまっているため、ポインタの値は違うけど、指す内容は同じという 場合が容易にチェックできません。げふ。取りあえずチェックできた、 sqrt(27回呼び出し),pow(2回),sin(501回),cos(499回)などはOKそうでした。
あと、POV-Rayは、画像サイズが2*1ピクセル程度になってしまうと、入力 ファイルのパースの方が実際のレイトレースパートの実行ステップ数より も大きくなってしまいます(^^; 入力ファイルのパースでミスっていれば それは意味があると思われるのですが、直感的に、そこは大丈夫な予感が するので、取りあえずは結果からから順にたぐってゆくのが筋でしょう。

結局、plot_pixel()という関数から順に後ろにトレースをして結果を比較 してゆくという、本来の方法にたどり着いてしまった感じ。ここで、 ppcsimの方にデバッグの為の機能をいくつか追加しなくては面倒臭くて かなわない予感(前はそうやってデバッグしてましたが(^^;)。 あと、現在我が家のHDD内にのみ存在するppcsimでは、特定の方法で出力した ELFバイナリを直接読み込んでコマンドラインっぽく実行できますが、この 部分は色々思惑があって、ブレークポイントを設定できる様になっていま せん。この辺、後で付けた感じの部分というのもありますが、gccとライ ブラリはほぼ問題無いという事に加えて、普通にprintf()デバッグが可能 になっているという事と合わさって、命令コードレベルでの追っかけは 取りあえず考えていなかったというのが敗因だったかも知れません(^^;
先のメモリ内容の比較も簡単な方法で行える様にしたい所ですが、 うーむ。

疲れたので、GIGAWING2など(更に疲れが増しそうですが)。スコアアタックの STAGE 4は結構面白いかも。あと、リフレクトレーザーよりもリフレクト フォースの方が対ボス時にデカ勲章ばらまきを発生させやすい予感。

大家さんが家賃の集金にやってくるので少し早めに起床。

昨日のCygwinでコンパイラが動かなくなった件は、「Snapshot」 からcygwin1.dllをダウンロードして差し替えた所OKになった模様。 ラッキーでした(^^;
bzip2は大丈夫かどうかを見てみました。大丈夫な模様。となると、 やっぱり、整数系よりも浮動小数点系への疑いが強くなって来た予感。

スキャンディスクを実行するとまた突っかかっている模様。徐々に 腫瘍が広がっている様な予感。進行が止まるまでこまめにチェックしてれば 良いのかしら？待っているのもなんなので、掃除やら洗濯やらした後、 ちょっこり出社。

ふと思いつき、数学関数の結果をCygwinで実行するものと、ppcsimで 実行したものとを比較する事にしてみました。結果、sin()やcos()は全く同じ で、pow()に若干誤差があるものの、これで変わるか？というくらいのもの でした。因みに、gcc2.95.2+newlib-1.8.xでそのテストをコンパイルしたもの の実行結果と2.97+newlib-1.9.0の結果を比較すると、全く同じ。つまり、 ppcsimで実行する分には、コンパイラのバージョンとライブラリのバージョン に依存せず同じ結果なのですから、povrayで起こった様な相違を引き起こすの には失敗したという事になります。へこ。
あと、別件でprintf()の %f フォーマットの出力がnewlib-1.9.0 ではバグっているようで、sin(0)=0 って感じで出てきました。Cygwinネイティブ やnewlib-1.8.xは sin(0)=0.000000 と出るので、cvsアップデートで探ってみた 所、vfprintf.cが修正されていました。こんなのそうそういじるところある のかなぁと、1.8.xと比べてみると無茶苦茶変わってますよ(^^;(因みに、 1.9.0とバグfix版との差分は1行だけ) まぁ、変わっているものはしかたない として、差し替えると0.00000表記になりましたが、povrayのバグとは全く関係 無し(^^;
あぁ、簡単な奴で再現できれば良かったのですが、「目の前で起こっている ならそれを調べればいいじゃんの法則」(＜長っ)により、いよいよpovrayを トレースするしかないのか？

GIGAWING2で久々にスコア更新。最低でも3面まで1クレジットで行ける 必要がある事が判った。買った時に出たスコアはそれくらいのものだった ので、その時は相当運がよかったと思われます(^^;

日付け越え。

調査続き。いよいよ困ってきました。もし、共通で使用されている命令で 今までたまたま例外動作を行う事の無い様な値が入っていた場合の挙動が 違うとなるとちとやっかい。というのは、全ての命令の例外値入力テスト を行わなくてはならないからです。うーむ。取りあえず、ブランチ命令系 でbeq+とか'+'や'-'の付いているブランチ命令を見たことが無かったので、 チェック。ちゅうか、特に例外も出なかったので、今ので合っていると 思っていたのですが、やっぱ気になっただけ(^^;。で調べてみると、'+'や '-'はBOのbit4で、分岐予測に使うビットで、通常プログラムの挙動には 影響しないと思われるものでした。ppcsim上では力一杯無視しているbit なので、その場合は'+'や'-'の付かない場合と同じになりますので、多分 大丈夫.......がふ。
次にfcmpuをチェック。比較オペランドの内容がNaNである場合の挙動が 正しかったかどうかチェック.......なんとなくOKな予感がしま すが......げふ。

先日リリースされたCygwin-1.1.8をインストールしてみました。tcshが 使える様になったので、早速使ってみたのですが、cygdriveを認識して いなかったり、シンボリックリンクの先をautolistで追っかけられなかっ たりとすぐに直ると思われる小さな不具合がありますが、概ねOKそう。 シンボリックリンクをautolistで追っかけられないのは不便なので、 この辺が直るまではbashを使う事になりそうな予感。
とかやっていると、クロスコンパイラがうまく動かなくなっている模様(汗; また、CRLF問題だと思われるのですが、なぜこの部分を毎回壊すのか謎。 いじらなきゃ良い様に思うのですが........

日付け越え。また雪が積もるのかとも思ったのですが、大丈夫だった模様。

使われた命令比較を行ってみた所、いくつかpovrayで使っていてdjpegでは 使われていない浮動小数点系命令があったのですが、チェックしてみるも 特に間違いはなさそう。一瞬load/store命令を間違っている様に思ったけど やっぱり大丈夫。うーむ。
しかたないのでGIGAWING2をやって寝る(ぉぃ 今にして思うに、何故今の ハイスコアが出せたのか謎(汗;

日付け越え。帰りは雪ですよ。寒くて死ぬかと思いましたよ。最近、 雪づいていていかんですな(＜なに様？)

昨日のその後。djpeg -dct floatを試してみた所、特に画像が変になる事 はありませんでした。うーむ。しかたないので、取りあえずトレースの ダンプを取って、djpegで使われる浮動小数点系命令はOKに違いないという 事にしてしまう為のネタを作る事にしました。
実行中に暇なのでWebぐるをしていると、Cygwin-1.1.8がリリースされていた ので、早速ダウンロードしてみる事にしました。遂に、tcshが正式に 提供される様になったようです。こいつぁラッキー。でも、なぜかダウン ロード失敗しまくり。何度かやってみるもやっぱり途中で切られてしまう 模様。とかやっていると、サイト自体に繋がらなくなったり。根性無いです。 最近はftpでディレクトリを見るにバイナリ自体は入っているのに、 インストーラではダウンロードできなかったりと、謎が多いです。

とかやっていると、アクティブデスクトップが落ちてしまいましたよ！
おそるおそる再起動を試みると、スキャンディスクが走り、また詳細 チェックが始まってしまいました。今度は一発目のクラスタで突っかかって しまっています。なんとなく不良セクタの領域が徐々に広がっている様な 感じがしてなりません。今回のは壊れようが酷く、何度もファイルを復旧 するか聞いてきます。面倒なので、「復旧しない」を選ぶと、スキャン ディスクが終了してしまいました。復旧しないのは問われたファイルだけ のつもりだったのですが。で、幸いにして立ち上がったので、Winの スキャンディスクを仕掛けて就寝。起きると終わっていて、いくつかの ファイルを修復した旨が出てました。不良セクタまで潰してくれたの かは謎。

週末に、ディスクとついでにメモリを買いに行く事にしようかしら.....

日付け越え。

DoCoMoからの手紙。開けてみると、買った携帯電話にバグがあるので、無償 交換するという事。ただの電話として使う分には何の影響も無いバグなのですが、 どうしようかしら。なにせ電話帳類の転送はしてくれるらしいのですが、 ダウンロードしたデータや設定までは戻せない臭い旨が書かれていたので、 そちらの方が個人的には面倒臭くてかないません。
本当に浮動小数点系命令に不具合があるかどうかを見る為に、djpegをもう一度 調査する事にしてみました。現在トレース中。でも、djpegはテストとしては 結構弱かったりするので、djpegがOKだから整数系がOKとは言えない所がなんとも。 あ、djpeg -dct float を試してみればよいかも........

日付け越え。

ひとしきりGIGAWING2で遊んでみました。先日、なにげに「ハイスコア 更新です」とメッセージが出たものの、その後全く それに近いスコア の出る気配なし。まぐれだった模様。スコアアタックで遊んでみました が、スコアアタック自体は前作DC版と同じ感じなものの、前回不満だっ た １ゲームが終了すると、タイトルまで戻ってしまって、連続して アタックするのに非常に煩わしいという所まで 前作DC版と同じだった のは残念かも。

取りあえず実行命令比較。2.95.2の出力コードでも使われていると思っ ていた命令が、実際には実行されていない事が判明して意外に思いました。 addze,bctrl,cntlzw,extsh.,lfdux,lfsu,lfsux,lhzux,lwzux,mulli,stfdux など。調べていると、lf?uxやらstf?uxの A オペランドの解釈がlf?uと 間違っていたり。でも、実際にはA=0を指定した命令列は無い様なので、 今回のものには影響は無いハズ。うーむ。

そんな訳で、すっかり空が白んでますよ(汗; 徹夜でプログラミングは 健康によくないです。因みに、朝再放送しているセーラームーンはRに なってました。

ほどなくして起きて、なにげに今話題になっているウイルスのチェック などしてみました。ライブアップデートで取りあえず最新版のパターン ファイルとやらにしてみてチェック。ウイルスはいなかった様です。 とは言え、ウイルスチェックに引っかからない様に見せるウイルス に感染しているのでは？！などと疑い始めると何を信用して良いの やら(笑

GIGAWING2と雑誌を査収して、ちょっこり出社。プログラムをちょこっと 修正して目的のデータを作れた模様。

早速、箱に入ったままのDCを取り出して試してみました。ちょっとこれ 凄すぎない？まんまアーケード 版ですよ。いや、一発目に 「リフレクト フォーーーーッス！！」 って来たときは思わず、ズッこけてしまいましたが。弾が避けられない のはGIGAWINGだからとして、やっぱ、背景やらボスキャラやら、が 非常に美しいですよ。ボンバーは前回同様賛否ありそうないちいち背景を 消すタイプの奴なのですが、光源エフェクト系バリバリで、個人的 には「美しいので許す」そんな感じ。特にウイングボンバー(リミ機の方) は必見(ロミ機のは色がちょっと.....)。とにかく、 前回とは比較にならないくらい絵がよくなっているのに、同じDCで 動いているというのがすげーっす。MARS MATRIXがGIGAWINGの延長線に 乗っているくらいにしかなかった事を考えると。もーっ。あ、因みに 前回謎だったリフレクトでレーザーが出る話は、最初にリフレクトフォース とリフレクトレーザーが選択できると判明した事で理解できました。
ちょっと、これって、やればサイヴァリアも余裕でいける(しかもグラ フィックも良くできる)んでないの？

死んだ様に眠って15:00起床(激汗;;; で、休日出勤(T_T)

宿題でプログラムを作る事に。日本語コードを扱うので、 rubyでできるかどうかを試す事にしました。所が、rubyの日本語 サポートは正規表現部分くらいしかなく、多バイトコードを 意識せずに文字数で扱う事は簡単ではない事が判明。この点は まぁ、しかたないと諦めたとして、問題は文字列を縮める方法が いまいち見あたらないという、もっと低レベルな部分に突っかかった所。 一番簡単そうなのが、

  str[a,n]="str" ;

  str{"dict"}[0,word.length]="" ;

日付け越え。

取りあえず、バックアップを取ることにしました(^^;。どうせ 「書き込み専用媒体」化する事間違いなしなのですが、精神的安心 を得るために一応。
バックアップを取るディレクトリを選択。大きいのは、ダウンロード ディレクトリと開発関連ディレクトリの二つ。前者は800MB越え、 後者は2.5GB越え.......って、これじゃぁ640MBのMOに全然入り ませんよ！
取りあえず、Cygwin関連は入れ直せば良いので、インストール後の 環境も含めて取らない事に。glibcやlinuxなど見るだけに展開した ディレクトリも取らず。画像も取らず。で、選んだファイルを tar+gzipして、どうにか500MBに収まりました。前回(8ヶ月前) 取った時は、直ぐ終わるだろうと思って、圧縮も何もしないで、 フォルダをそのままドラッグ＆ドロップしてえらく時間がかかった のですが、今回はそれよりは早く終わった予感がします。むしろ、 前のを消す方がよっぽど時間がかかった気がします(^^;

で、ほったらかして起きたら終了。結局、２日間何もできずですよ。

日付け越え。あっという間に２月ですよ。

コンパイラバグと疑いつつも、以前 sqrt() で、-O2のみで出現する命令に シミュレータバグを盛り込んで動かなかったという前科がありますので、 2.95.2と2.97とでそれぞれ実行トレースを取って、新規に使っている 命令をチェックする事にしてみました。
両方のトレースと命令サマリを作成し終わった所で、Meadowを立ち上げ ようとした所、何度起動してもメッセージを出してMeadowが立ち上がら なくなってしまいました。しかたないので強制電源切断をし、例の スキャンディスクが起動された所、以前に立ち上がったセクタ毎の調査 が開始されました。がーん、これ始まるとしばらく終わらないんですけど。 と見ていると、２番目のセクタで突っかかってしまっています。 これはディスクの異常という奴では...... しばらくリトライ(と思われる 動作)をしたところ、ハード的に異常があり、ファイルに影響がある とのメッセージが出ました。ドキドキしながら読み進めていった所、 どうやらスワップファイルだけが影響を受けていそうだったので、 取りあえず修復を試みると、不良セクタのマークを付けて、続きの セクタの調査が開始されました。ちょっと見ていたけど眠くて死亡。
朝起きるとWinが立ち上がっていたので、取りあえずはOKの模様。

SCANDISKですが、根絶丁寧にディスクの異常の様を告げていたのに 少し感心しました。修復できない様な場合にどの様なメッセージになる のかは不明ですが、これくらいのものが標準で付いているのならば、 結構安心の様にも思えます。ただ、20GBを1パーティションで使用して いる我が家のPCでは、１セクタの不良で数MBのデータが飛ぶ可能性 もありますので、記録メディアの高密度化に対応するという意味で バックアップは重要な気がしてきた様な気分です(^^;
あと、結構スワップが激しい状態でも平気で使っていられる体質なの で、メモリを増やせばスワップアクセスによるディスク破壊は防げる 様な気もします(^^; 今回の場合、本当にスワップアクセスでセクタが 壊れたのかは不明ですが、その様な事例は存在しないが、可能性として ありえるようでしたら、貴重なサンプルを提供してみた感じがして ニヤり(ぉぃぉぃ;;;