昔の最近の出来事(2000.06)

2000/6/30

シミュレータ。
シミュレータ内でのexecvp()エミュレーション内での特殊加工処理をやめて みました。system()はコマンド文字列をそのまま渡せば良いだけなので非常に 簡単なのですが、execvp()は引数をトークン分離してポインタリストを渡す 必要があるので、文字列操作の苦手な私には非常に面倒です(^^;
取りあえず完成。ニセsh上でdjpegを起動。OKそう(^^)v。

Cygwinのダウンロードサイトに、いくつかツール類の最新版がアップロード されていたので、ダウンロード。インストールは明日にしよう........

再びシミュレータ(^^;
ニセshプログラムを作ってみました。取りあえずニセsh上でdjpegを起動。 OKそう(^^)v。これでニセsh上でgccを実行する様な事ができるかしら？
一瞬、脳内シミュレート。ニセshでの子プロセス実行をsystem()を使用して 実現したのですが、system()内では、execvp()でshを起動して、その引数に system()の引数をそのまま渡しています。この理論で、ニセsh上でhogeと いうコマンドを実行すると、 sh hoge -> sh 'sh hoge' -> sh 'sh 'sh hoge'' ->..... とニセshを無限にfork()し続けてしまう事になります。って、 ダメじゃん(^^;。今はシミュレータ 上で動作するshが無いので、system()上で起動されるexec()の引数を、シミュ レータ内で加工して ロードを行っているので、たまたま動作しているという 訳です。
判った事。SVR4的プロセス生成系では、シェルプログラムは、自分自身を 実行時シェルとする場合に於いて、system()を使って子プロセス起動をしては ならない。

HSPで DirectDrawを使用する為のプラグイン (＞The realm of AM) を試してみました。 い、いいかもぉ〜。 いや、Directなんちゃらを自前のプログラムで使った事無いので......(^^;

朝、寒くて起きました。まずいかなぁと思っていましたが、案の定、ぶり返し(T_T)
思い出した様に、HSPを少し 触って寝た。

バグ取り。free()した後のポインタをNULLを入れずに再度メモリ割り当て関数で 使用して死にました。

鼻の調子が良くないです。でも、休出してました(T_T)

ふぅ、どうにか子プロセス実行できる様になりました。newlibのsystem()に合わせる 形で取りあえず実装したので、今のままだと、system()以外はまともに動きません(^^; 少々整理する必要がありそうです。それが終われば、gcc(コマンド)のネイティブ コンパイルに挑戦といった所でしょうか。うーん、gccに手を入れずにいけるかなぁ？ 難しそう......

少しひらめきました。
SVR4的な新規プロセス生成では、fork()+exece()を使用する訳ですが、 これをシングルタスクで実行する事を考えてみました。
以前、system()の中身を調べてみましたが、もう一度よくみてみました。

01  if ((pid = _fork_r (ptr)) == 0)
02    {
03      _execve ("/bin/sh", argv, environ);
04    }
05  else if (pid == -1) return -1;
06  else
07    {
08      int rc = _wait_r (ptr, &status);
09        :
10    }

間違い箇所発見。ヒープサイズの初期値を思いっきり間違えてました(^^; 修正して実行......一応OKそう(^-^)v
うーん、どうしよう。とりあえずsystem()をシステムコールにして しまおうかしら.....でも、それだとgccなどに思いっきり手を入れないと ダメなのでいまいちだし.....
仕方ないので、ELFフォーマットのドキュメントを眺めてみました。英語 なので読めません(T-T)。ヘッダ構造体の部分を眺める為に、ファイルの 16進ダンプ表示プログラム(Human68kのDUMP.X相当品)を作ってみました。 なんとなくフィールドの意味が判った様な気がしました。

プロセス管理の続き。signalの事を考え始めると、泣きそうになって きました。取りあえず休憩して、ppcsimにプログラムローダを実装 してみる事にしました。
かなり適当ですが、一応完成。exec djpeg --help とかやればいきなり 実行できるという予定。........メモリが足りないという旨の djpegの エラーメッセージが(^^;; どこか間違っているらしい。

μITRON4.0仕様を読んでみました。予備知識無しで読んだので、よく判り ませんでした(ぉい; 一つだけ判ったのは、「ITRON仕様のスケジューリング 規則では、優先順位の高いタスクが実行できる状態にある限り、他のタスクは 全く実行されない」のだそうです。この点、組み込み用途向けっぽさを 感じました。
組み込み用途向けで、小さいという事の様ですが、フルスペックで実装 した場合、結構大きくなるような気がしなくもないのですが、実際の所 どうなのでしょうね？(フルスペックでHuman68kより小さい様な事が どっかに書かれていた様に思ったのですが.....)

プロセス管理の方法を考え始めてみました。なんだかゲームのキャラデータ管理を 考えているテイスト溢れていて、ちょっとはまってきた(のめり込みの意) かも(笑; この辺、ゲームを作れる人なら(理論も実装も)それほど難しく無い話かも知れま せん。私はゲームなんぞ作れませんので、難しい話ですが(^^;



着色を試してみました。つーか、色つきのペンで線を引いただけという説が(^^;.... 「塗った」という感じでは無いですな。
タブレットドライバの最新版が出ていたので試してみました。こちらの方 はOKそう。また、タブレットの右端までスタイラスを動かしても、画面の端まで カーソルが届かなかったので、「X方向検出範囲」を調節してみました。 11000くらいで、画面とタブレットが対応するという感じでした。因みに、 我が家のタブレットはArtPadの初期の奴(初代？ちんまいの)です。

すっかり彩にはまっていんぐ。
着色の方も試してみたい所ですが、マスクマニアの私にはどうしたら良いもの か(^^;



リンクするよりも表示してしまった方が文を読みながらダウンロードできるので 良いという事が判りましたよ(^^;

めずらしくお子ちゃまですな。無意識に胸を大きくする習慣が付いていたらしい という事実に自分で驚きましたよ。お子ちゃまなので胸は大きくありませんがっ。
ぐぅ、今日は眠いので もう寝ます。

バナーを作ってみました。手で描くのは面倒だったので、POV-Rayを使ってみた のですが、ガラス質を使いまくったせいで余計に時間がかかった気が(^^;..... ま、へっぽこっぷりを発揮できて良かったかなっ！(＜ひらき直るなよ)

彩 for Winがリリースされました。 それはもう早速ダウンロードしましたとも！ 説明書にしたがってタブレットドライバを実行。カーソル動かないけどこれでいいの かしら(?.?)。そして彩本体を起動。やっぱりカーソル動かず.......
取りあえずマウスで操作.......はっ 速いっ！ 500pixのブラシでも全然ストレス無いし！(^^; あぁ〜〜んっ！タブレットが 使えないのが も ど か し い 〜 〜。 取りあえず、それだけ報告して少しいじってみました。
X68kと同程度の機能を有しているかと思っていたのですが、描き味評価と言うこと で、レイヤー/マスクは無し、ファイルIOも無し、スクラッチパッドも無しという 所なので、ツールとしてはまだ使えないレベルです。 色塗りのレベルは機能的にはX68kのブラシと同等(精度はもっと高そう)なので、 もう少し色々できた方が、総合的な評価を行えるという点では良かったかも知れま せん。 いかんせん、タブレットが使えていないので、線画くらいは描いた所で評価しろって 言われるかも(^^;。しかし、GIMP for Winよりは全然ましです.....って、ものさし になってないですね(^^;。まぁ、ツールとしてはこれから詰めていくと いった所だと思いますので、これからの進化に注目でしょう。機能的にX68k 並の所までできればOKですが、爆速CPUを使う事でX68kにはできなかった機能の 実現という部分にも注目してみたいですね。


いくつかデバッグ情報をやりとりした後、タブレットが使える様になりまし た(^o^)。さすがっ！ ご苦労さまでした(＞ＫＯＪＩさん)。ええ、早速使っ てみましたとも！

ぽんち絵(sai_test0.png 105399Byte)

もう、タブレットへの入力が、ダイレクトに画面に伝わるので、手が少し震えて いる私には、むずかしいことと言ったら(笑)。X68kだと、筆圧の感度が遅れて 伝わる感じがあったので、筆圧コントロールが非常にむずかしかったのですが、 そこん所が俄然良くなっています。
いかんせん、鉛筆描きと一発描きは苦手なので、ぽんち絵はなんの参考にもなら ない様な気がします(^^;。ここまでくると、脊髄と小脳と右脳で善し悪しを判断 する以外に方法が無いと思いますので、グラフィッカーは一度使ってみるしか ないでしょう。

治ったみたい。

マルチプロセス化の事を考えていくと、なんとなくミニOS的な所まで考えなく てはならない予感(^^;。う〜ん、どうしたものか。

なにげにリアルタイムOSについてちょっと調べてみました。実は、リアルタイム の定義が判っていなかったりするのですが、説明を聞いてもどうも納得できない というか、物理の法則に反している様な気がするというか、そんな感じでした。
リアルタイムOSの特徴として、応答が厳密であるなどが挙げられる様なので すが、これがいまいち理解できませんでした。というのは、複数のプロセスが 全速力で１つのCPU上で動作しようとする場合、正確に応答する事など原理的に できる訳無いハズだからです。 例として、「正確に時間を刻む事ができるので、時計の様なアプリが簡単に 作れる」という様な説明が挙げられる場合があったのですが、この理論でいくと、 ２時間かかる3DCGレンダリングは、きっかり２時間で終わる事になりますが、 それが複数あった場合でも同時に２時間で終わるの？ という疑問がありま した。
で、色々見てみると、リアルタイムOSを使用する場合は色々と条件があるらし く、その一つに「高速性は要求されない」所で使用するというのがあるみたい です(^^; これなら、確かに物理の法則に反していないので、納得できるもの があります。しかし、一般的なワープロやCGツールの様に高速性を常に要求 されるアプリケーションを動作させるOSとしては、使うべきではなさそう という事が判りました。
この辺、ITRONの場合はリアルタイムOSで組み込み用途という事で理解可能と なるのですが、BTRONの方はリアルタイムOSなのかどうかがいまいち不明。 もし、リアルタイムOSでないのならば、単なるプリエンプティブでリエント ラントなOSという事になる様です。因みに、以前「ワールドビジネス サテライト(テレビ東京で23:00からやっている工業関連ニュースを扱って いる番組)」で特集が組まれていましたが、その時もITRONとBTRONがひと まとめにTRONとして扱っていて、細かな定義がよく判らなかった様に思い ました。

悪化してるし(T-T)。寝よ。

なんだか風邪気味。寝よ。

シミュレータのマルチプロセス改造を始めてみました。取りあえずグローバルな 資源を使用しない様に変更した所で一息。直しているうちにも色々疑問が沸いて きたので、よく考える必要がありそう。
CygwinのlatestをチェックしてみたらCygwin DLL 1.1.2 リリースされてました。 ２バイト改行コードを食ってくれなかったのはバグだったらしい(T-T)。 あと、先日のin6_addrの間違いも修正されているみたい。現在ダウンロード中。

ダウンロード終了。Cygwin-1.1.2.tar.gzだけ入れてみて、２バイト改行コードな ソースを食わせてみるも、makeがこけました(^^;。makeもチェックしてみた所、 新しくなっていたので、これもダウンロード＆インストール。バッチリでした(^^)。 これでWindows付属のテキストエディタでも安心でしょう。

マルチプロセスのシミュレーションをどうするか考える。ppcsimの実行コアを使用して、 レジスタやメモリなどのハード資源をプロセス毎に用意する様な構成で考える。こうすると、 マルチタスクもどきの実現が可能。逆に、マシンレベルでの実行という感じではなくなって しまうかな？あと、今までと同じ様な方法でトレースを取ったりする事はできない予感。 それよりも、実行ファイルローダを持たなくてはならないのですが、どうしたものか。 OSの仕事だし、まぁいいや と今の今まで避けていたELFフォーマットを理解せよとの事 なのか？やだなぁ.....最悪、決めうちローダでOKとしてしまうかも。

gdb-5.0をダウンロードしつつ、gdb-4.18の日本語訳を眺める。リモートデバッグのしくみが なんとなく判った。組み込み用途の小規模なシステムのOSのリモートデバッグなども考慮に入って いる様なので、意外と簡単に使えそうな、そうでもなさそうな、そんな感じ(どっちや)。
makeしてみる。コンパイルエラー(^^;。Cygwin 1.x の$root/usr/i686-pc-cygwin/include/cygwin/in.h で「in_addr6など知らん」と怒られる。in6_addrの間違いらしい。Cygwin B20 ではin_addr6 だった名前を一部換え忘れてただけみたい。暇な時にlatestをチェックしておこう。 前回、gdb-4.18をコンパイルした時にreadlineで怒られたけど、今回は大丈夫だった模様。
target remote COM1 とか実行してみると、Ignoring packet error, continuing... と怒られた。 何も繋がっていないのであたりまえですが(^^;

さぼってた日記をまとめ書き(汗;

お勉強。メモリコントローラのしくみがなんとなく判った。でも、リトルエンディアンモードの 時の文字列の格納の仕方がなにか間違っていなくもない予感。

打ち合わせ。

酔っぱらって帰って即死(^^;

何も無し

プロセス生成についてお勉強。SVR4ではプロセス生成はfork() システムコールでしか行わない。このとき、生成されるプロセスは fork()を実行したプロセスのコピーになる。 exec()は子プロセスを起こすものではなく、現在動作している プログラムを置き換える、つまり自分自身をつぶして、別の プログラムの実行させるというイメージらしい。
system()の中は次の様になってました。

  if ((pid = _fork_r (ptr)) == 0)
    {
      _execve ("/bin/sh", argv, environ);
      exit (100);
    }
  else if (pid == -1)
    return -1;
  else
    {
      int rc = _wait_r (ptr, &status);
      if (rc == -1)
        return -1;
      status = (status >> 8) & 0xff;
      return status;
    }

   /* ねずみ算式に増殖する */
   while(-1) fork() ;

ちょっとだけ掴んだ感じ。いや、気のせいか。やっぱ時間はかかるもの らしい(^^;
六角大王スーパー２は色々モデリングアシストする様な機能がついて いるらしい。安いし、面白そうなので買っても良いかなぁ。

なにげに六角大王(フリーソフト版)をダウンロードしてみました。 思うに我が家のWinマシンで3DCGソフト使って遊ぶのは初めての様な 予感(笑)
昔のGW誌を参考に使ってみるも、以前のShadeのそれと同じく モデリング過程(1)と(2)の間に、えらく長い時間が省略されている 様な予感がしたり(^^;。慣れればいけそうな感じがしなく もないですが............やっぱ3Dは むずいです(^^;

relax関連の部分をld-info?から探してみるも、あまり関係無さそうな 予感。よくわからじ。

ppcsim-0.05とそれに関連してppclib2の変更追加分を置いてみました。 ご参考まで。

relaxの事はとりあえず置いといて、POV-Rayの方を試してみました(^^; コンパイル環境などが変わっているのでフルコンパイル。で、実行して みました。...........あれ？動いたよ？..... 怪しい！(笑) 出てきた画像ファイルを見てみると画面が赤っぽい色で塗りつぶされてました。 ちょっとへこりな感じがしつつ、一応、Windows用POV-Rayで同じシーンファイル を食わせてみると、こちらも同じく塗りつぶされてます。つまり正しいって事？ オブジェクト(球)の全景が入る様にシーンファイルを修正して、再度ppcsimで 実行........... イイ感じじゃないですか！



インクルードファイル群のオープンも確認すべくPOV-Rayサンプルのシーン ファイルを食わせてみました。なんかOKかも(^^)
一番簡単そうなので

こんな感じ。
povray -i povray31/scenes/incdemo/colors.pov +W240 +H180 +A -o test1.png で、実行命令数は1435568227命令。時間は436秒といった所。

少し重そうなので

こんな感じ。
povray -i povray31/scenes/advanced/mist.pov +W240 +H180 +A -o test2.png で、実行命令数は(0x7fffffff*5+284816480)命令。時間は3438秒といった所。 X68k+ppcsimでやると、数ヶ月..いや、数年コースでしょうか？(笑)。

とりあえず、ppcsimの浮動小数点演算系命令は、コンパイラの吐いたものに限り OKそう、newlibのlibmも取りあえず大丈夫そう と、言って良いのかな？

cppの時に.bssセクションを0クリアしておかないと動かなかった事を 思い出しました。で、.bssセクションを0クリアするコマンドを追加 して実行............おっ、 おおっ！ お お おっ？！ 動いたんでない？！ 出力 ファイルができており、中にそれっぽい命令列がはいってました。 クロスコンパイラの結果と比較した所、全く同じファイルができて ました。動きましたよ(^o^)

ふぅ、長い道のりでした。POV-Rayが動かなかったのも、もしかすると 動くかも知れません(問題の一つとして、Cygwinのgccでネイティブ コンパイルしたUNIX用POV-Rayが動かないという話があるのですが)。
それより前に、GNU-ldでのrelaxという操作は何者なのかを調べる必要が ありますな。 なんせ、手を入れたldが吐く実行ファイルはobjdumpで逆アセンブル できませんから、これでは動かなかった時にリストを出力する事ができ ませんので(^^;;。

あと、gcc(コマンド)は、現在のppcsimでは子プロセスを生成＆実行する 事ができませんので、とりあえず保留。子プロセスの生成関係は ライブラリの方も確認する必要がありますので、どうにかしてでも シミュレータ上でデバッグしておいた方が良いのでしょうけど..... うーん。

GNU-ld のソースコードリーディングの続き。 色々と網をかけながら動きを観察。自分自身を関数呼び出ししてたり、 アカデミックというかマニアックというか。このタイプのプログラムの 構造だと、デバッガでブレークポイントを設定すると、いきなりガシガシ 止まりまくるので、用事のある時に止まっているのかどうかが判りにくい ですね(^^;。ただ、初期値を与えて呼び出すと自力でデータの終わりまで 処理が進むので、動きとしては面白いのですが。
で、lang_statement_union_type.nameにセクション名が入っているという 事が判ったので、.sbssに引っかけてデータを観察してみました。で、なにげ にマップリストを見てみると、

 .sbss          0x00365fb0       0x20 toplev.o
                                0x154 (size before relaxing)
                0x00365fd0                g_switch_value
                0x00365fd4                flag_exceptions
                0x00365fd8                flag_rerun_loop_opt

     if (i->_cooked_size != 0)
       dot += i->_cooked_size;
     else
       dot += i->_raw_size;