結局やってる zxLinux (3)

2000/07/20 (最終更新:2005/08/28 15:27)

◎ とりあえずライブラリパッチ

前回、アプリケーションからファイルに書き込めない問題は newlib に原因があることを突き止めました。 ライブラリ仕様が異なっているにもかかわらず、 zx_syscall.c がシステムコールを裸のまま乗っ取ってしまっているからです。

これを解消するには zx_syscall.c (libzxl.a) の仕様も変更しなければなりません。 libzxl.a は newlib(libc.a) を使わないライブラリからも使われているので、 互換性を損なわないように修正する必要があります。

とりあえず以下のようにパッチをあててみることにしました。

・考慮しなければいけないこと

・実際に行った修正

libzxl.a
zx_syscall.c の open() を _zx_open() に名称変更。 syscall_wrap.c を追加して、その中で open() 定義し、_zx_open() を呼び出す形にする。
libxtalq.a
libc.a といっしょにリンクするための、専用 libzxl.a として新規作成。 zx_syscall.c を含むが sysacll_wrap.c を含まない。
libc.a
sys/sh/syscall.c で新たに open() を追加定義し、 O_CREAT 等の機能ビットを変更するパッチを当ててから _zx_open() を呼び出す形にする。 libc.a といっしょにリンクするときは libzxl.a ではなく libxtalq.a を使用する。

◎ 動いた

かなり強引なところもありますが、 上のようなライブラリの修正で、 newlib (libc.a) の fopen( , "w" ) がまともに動くようになりました。

さらに、 パッチ当ての後、あらためてコンパイルした ack はきちんと書き込みもできることを確認。 ようやくここまでたどり着くことができました。

これを公開したら、ひょっとして zxLinux 初のユーザーサイドアプリケーションの座を獲得することができるのでしょうか？？ (でも、zxLinux のコンソールが漢字表示できないので、 全然意味無いツールだったりします。)

それにしても、このようなバグとかパッチの情報は 本当にどこにも無いものなのでしょうか。 かなり基礎的な部分だと思うのですが、 みんなどうやって対処してるんでしょう。

◎ MI-P10 で動かないかも

カーネルソースを眺めていて気が付いたことが数点。 どうやらこのカーネル、 文字描画で自分でフォント展開している可能性があります。 前々回(お待たせしました zxLinux解説)で RAM容量の観点から MI-P10 でも動くであろうと書いてしまいましたが、 もしかしたらモノクロ変換が必要なので、そのままだと動かないかもしれません。 MI-P10 持ってないので未確認です。動いたらごめんなさい。

といっても修正することは難しくないので、 カーネルソースの修正だけで MI-P10 にもすぐに対応できるとは思います。 ただ、本気でこれのサポートやろうとすると、zxLinux の対応 3機種全部画面仕様が違うので、 MI-EX1(640x480 65536色)、 MI-C1(320x240 65536色)、 MI-P10(320x240 16階調) と、 全部そろえないといけないかもしれません。

◎ PC と同じソースがそのまま通る

zxLinux は Zaurus 上で動くとはいえ、ちゃんと Linux です。 PC と同じソースがほぼそのままコンパイル通ります。 ここまでくると、かなり面白くなってきます。 もちろん、まだまだライブラリの違いで引っかかるのと、 コンパイルが通っても必ずしも Zaurus で動くとは限りません。 例えば次の例のように・・

◎ 実数演算で固まった

かなり古典的ですけど、整数演算ベンチマークプログラムの一種 dhrystone2.1 のソースを試しにコンパイルしてみました。 いつものように、Makefile の修正だけでコンパイルは通ります。 

ZTOP    = /usr/local/zxlinux
ZINC    = $(ZTOP)/sh-hitachi-elf/include
ZLIB    = $(ZTOP)/sh-hitachi-elf/lib
ZGCCLIB = $(ZTOP)/lib/gcc-lib/sh-hitachi-elf/2.95.2/ml/m3e
ZBIN    = $(ZTOP)/bin
CC      = $(ZBIN)/sh-hitachi-elf-gcc -traditional -ml -m3 -I$(ZINC)
LD      = $(ZBIN)/sh-hitachi-elf-ld
ZSTRIP  = $(ZBIN)/sh-hitachi-elf-strip
LDFLAGS = -L$(ZLIB) -L$(ZGCCLIB)
Z0LIB   = $(ZLIB)/prochead_main.o $(ZLIB)/crt0.o -T $(ZLIB)/ldscripts/shlelf.x
Z1LIB   = -lxtalq -lm -lc -lgcc
CFLAGS  = -O2 -DHZ=60 -DTIME
OBJS    = dhry_1.o dhry_2.o
BINDIR  = /usr/local/bin

dhrystone: $(OBJS)
        $(LD) $(LDFLAGS) -o dhrystone $(Z0LIB) $(OBJS) $(Z1LIB)
        $(ZSTRIP) dhrystone

いつものようにファイルシステムイメージに転送してコンパクトフラッシュにコピー。 zxLinux で実行し、数値入力として結果出力まで進みました。 一番最後のトータルの結果(肝心なところ)だけ表示されずに固まります。

ソースを見ると、最後の結果だけ実数(float)で計算しています。 結果の表示も実数で printf( "%6.1f \n", Microseconds ) です。 あやしいので printf( "%6d \n", (int)Microseconds ) と書き換えてみました。 でも結果はかわりません。

固まる現象はリトルエンディアンとビッグエンディアンを間違えた場合に よく起こります。実数演算で固まるからには、 演算ライブラリ libgcc を間違えてリンクしている可能性があります。

実数演算のテストプログラム(double)を作って走らせましたが、 こちらはちゃんと動きます。 もしかして float 演算だけ動かないのでしょうか。 さらに、こんなコードを書いて試してみました。 

main()
{
        double  a, b;
        float   fa, fb;
        puts( "d" );
        a= (double)rand();
        b= a / 0.3;
        puts( "f" );
        fa= (float)rand();
        fb= fa / 0.3;
}

"d" の表示のあと、"f" を表示したところで止まってしまいました。 やはり何らかの float 演算で止まっているようです。 dhrystone のソース中、float の部分を全部 dobule にしたら動くようになりました。

MI-C1 で dhrystone2.1 の結果は 76923 でした。 残念ながら zxLinux は、上記のようにまだまだ単純な実数演算も怪しい状態です。 dhrystone で計測に使っている zxLinux の時計 API が正確なのかどうか、 またライブラリやコンパイルが SH1/2 でなく正しく SH3 用にオプティマイズされているのかどうか等 未検証部分が多いので、 この結果が信用できるかどうかはわかりません。

ちなみに開発に使っている Linux のノートPC (Pentium 133MHz) では 196078 (値が大きい方が速い)です。 最近の速い PC だったら、この何倍も速いはずです。

さて、それでは float 演算ルーチンを追うために、 次に手に入れるべきは gcc のソース・・!!
といきたいところですが、 今回はさすがに遠慮しておきます。

◎ ヒットしまくり

バグの数は、たいてい使ってる人の数に反比例します。 ゼロから自分で作ったばかりのプログラムだと、 利用者は自分一人しかいないので、 そこにバグが残っている可能性が一番高いわけです。

だから、問題が起こったときは利用者が少ない部分を真っ先に疑うのが デバッグの鉄則になります。 結局それは、他の人も使ってる可能性がある OS やライブラリを疑うな、 自分が書いたコードを疑えってことなのです。

周辺の開発環境から開発ツール、ライブラリ、 実行環境までありとあらゆるものを全部自分で用意したときは、 たとえ問題が起こっても、いったいどこを疑って良いのかすら わからなくなることがあります。 全部が全部疑わしいからです。 zxLinux を使っているとそんな状況に近い感覚です。

ほんの数日動かしただけ、それも表面的なとこだけで全然深く使ってないはずなのに このヒット率です。 他に使ってる人が本当にいるのかどうか心配になってきました。 少しずつちゃんと動くようになっていくさまは、 それはそれで非常に楽しいものなのですけどね。

◎ この先の zxLinux は

ちゃんと動いてくれば、かなり使えるものになりそうです。 特に PC 用のソースがコード無修正ですんなり通る様は これまでの開発環境 SZAB では味わえない感動があります。 それがポケットに入る PDA で走るんだからたまりません。

以前 SZAB を触って一番最初に行ったのも、 ターミナルエミュレータルーチンの作成でした。 Zaurus にアプリケーションを移植するために、 コンソール用アプリケーションが動く環境を とりあえず用意する必要があったからです。 ack、dash、aish、telnet、pdview など、 多くのアプリケーションがこのルーチンを流用しています。 ただし画面描画はできても、それ以外の部分では互換性がありません。 それなりにプログラムコードを書き換える部分は多く、 移植は意外に手間がかかります。

zxLinux を使えば、そのようなことを一切考えることなく、 一瞬で移植できてしまいます。 もちろん、ちゃんと動くようになれば・・です。 今公開されている zxLinux だけを見ると、 その状態まで持って行くにはまだかかりそうな感じがします。 公開から時間がかなりたっているので、 もしかしたら表に出ていないだけで かなり進化した「すごい」バージョンがすでに動いているのかもしれません。

インターネットの上では、 ユーザーサイドの盛り上がりや公開されている情報がまだまだほとんどありません。 実際使ってみて、それなりの知識も必要で始めるまでの敷居がかなり高いことや、 まだまだ不安定で動かない要素が多いこと、 極端な情報不足は痛感しました。

発生した問題や引っかかった点などは逐次説明してみましたので、 わずかながらでも情報不足に対する糧になればと思います。 興味ある方はもちろん、腕に自身のある方ならむしろ、 自分の手で Zaurus の Linux を作り上げるんだ、というくらいの意気込みで 挑戦して欲しいなと思ってます。

長いこと SHARP の小さい情報機器、 電卓とかポケコンとか使ってプログラミングをしてきました。 その魅力はやっぱり、 みかけからは想像もつかない能力が秘められていること、 それをユーザープログラムで能力を引き出すことができてしまうこと。 それは Zaurus にもしっかり生きています。

最後になりましたが zxLinux 、Linux を Zaurus で動かすなんて、 くやしいけど想像すらしていませんでした。 アックス の zxLinux スタッフのみなさん、 非常に面白いものを本当にありがとうございます。

[戻る]
[メニューに戻る] [ZAURUS総合] [DirectX] [Ko-Window] [Win32] [WinCE] [携帯電話] [その他]
フルパワー全開 Hyperでんち
Hiroyuki Ogasawara <ho>