- V2.02β版リリース！
(2003/03/10)
またまた、たて続けの登場で失礼するぞぇ(^_^;)
さて、先のV2.01βで、NetFrontやPicsel ViewerなどのARMネイティブアプリの
圧縮伸張も出来るようになって、最初のうちは、うまく動いているとのレポートを頂いておったのじゃが、
「使ってると、おかしくなることがある」とのレポートが最近寄せられるようになった。症状は色々じゃが、
- 圧縮伸張は正常に動く。
- Auto Launchで自動起動した時、
- PalmGZipのArchiveListから起動したら正常に動くが、
- @マークのAlias経由で起動すると、解凍が終わって起動する瞬間に落ちる
- 何回か起動していると落ちて始め、最終的にはresetさえ効かなくなり、完全消去reset+フルバックアップ復元
というのが、主な症状じゃ。前者は、圧縮伸張が正常なのじゃから、問題は、Alias(PGZipAlias)という事になるが、
68Kのアプリなら、そういう事は起こらんのじゃから、とんと、不思議な話じゃのぅ・・・(^_^;)
後者の方は、見ての通り、再現性がないので、全くお手上げじゃ(^_^;)
で、色々調べて、２，３の原因らしきものを見つけたんじゃ。
- 謎の'a68k'
PalmOS5では、68Kのアプリを起動すると、creatorが'a68k'で、
typeがアプリのcreatorという奇妙なリソースデータベースが自動的に作られる事を、
皆、知っておるか？勝手に生成されるので、うっとおしく思っておられる方も入るじゃろうな(^_^;)
実はこれ、アプリのリソースを取り出し、エンディアンを逆転させたものなのじゃ。
PalmOS5では、描画などはネイティブで行われるので、リソースはARMのエンディアンの方が好都合じゃ。だから、
68Kのアプリを起動する際、描画処理が高速になるように、ARM用にリソースを変換してキャッシュしておるのじゃ。
ま、この機構そのものは、妥当なものじゃろう。さして問題ではないが、
エイリアス経由で起動する場合は、これがガンとなる(^_^;)
- NetFrontやPcselViewerはARMネイティブアプリ
→リソースは初めからARMエンディアン
→a68kのリソースデータベースは必要ない。自動生成されない。逆にあってはならない
(アプリ本体から取り出さなければならないリソースを、誤ってa68kから取り出す恐れがある。)
- @NetFrontや@PcselViewer(Alias)は68Kアプリ
→a68kのリソースデータベースが必要。自動生成される。
- NetFront(元の本体アプリ)と@NetFront(Alias)は「creatorが同じ」
→@NetFrontの為に作ったa68kは、NetFrontの為のa68kと同じcreator/typeを持つ。
- ・・・という事は、元々のARMネイティブアプリを起動する際、
過去にAlias経由で起動した事があり、a68kが生成されていたら、
誤ってa68kからリソースを取り出そうとする可能性が大！
- もし、a68kから取り出そうとしたら、そりゃ落ちるわな(^_^;)
そんな訳で、Aliasを作る際に、ARMネイティブアプリの場合(リソース内に'code'が含まれてない場合)は、
creatorの4文字目を'X'(既に'X'の場合は'Y')に変更して、生成するようにしておいた。
これで、aliasのa68kリソースを、間違って本体のリソースと誤認する事は無くなるじゃろう(^_^)
68Kのアプリでもこの変換をした方がよいかのぅ？とも思ったが、68Kでは、まず先に元のアプリを起動して、
正しいa68Kリソースが出来てるじゃろうから、まぁ、変換せんでも良かろう、という事でやっておらぬ。
もし、問題があったら、Filezなどを使って、手動で変更しておくれ(^_^;)
- 巨大なheap
PalmOSでは、標準的な空き容量を知る方法が示されておらぬ。一般には、MemCardInfoを使うと
思われいるようじゃが、実は、このAPIが返してくる値は、本体の空き容量+heapの空き容量を合計したものである事が
知られておる。よって、PalmGZipでは、概算で、heapの空き容量を100KB程度として処理しておった。
ところがじゃ、PalmOS5のheapの容量は、なんと4MBもある(^_^;)
heapがデカいという事は、様々なメモリ制約が取れるという意味では、非常に喜ばしい事なのじゃが、
空き容量は100KBとして計算していたPalmGZipは大変じゃ(^_^;)巨大なheap空き容量があるもんじゃから、
本体空き容量が殆どない場合でも、あたかも、まだまだ空き容量があると勘違いして、
ストレージメモリを思いっきりぶっ壊しながら
圧縮伸張してしまってたようで、OSをぶっ飛ばしてしまっていたようじゃ(^_^;)
色々調べた末、MemHeapFreeBytesを使うと、正確な空き容量が分かる事を突き止めてな、
これを元に空き容量計算するように改変しておいた(^_^)
これは、PalmOS5だけでなくPalmOS4でも有効な話なので、PalmOS4ユーザを更新される事をお勧めするぞえ(^_^)
- arm-palmos-gccは変？
V2.01βまでは、prc-tools2.2のgcc(arm-palmos-gcc:v2.95.3-kgpd)を使っておったのじゃが、
吐いたasmを見ると、何か、69Kのコードを単にARMに置換しただけのような、
結構、非効率なコードを吐くのじゃ(^_^;)
そのせいか知らんが、何か、OSを壊してるような動きをするとの報告がされておる。
これは、前者の空き容量計算ミスのせいで、このgccは無実かもしれんが、今となっては確かめようもない(^_^;)
そんな訳で、コンパイラをArmlet Tools DR2のgcc(arm-elf-gcc:v3.2)に変更した。
このgccは、かなりクセがあり、arm-palmos-gccのように簡単には使えないのじゃが、
オリジナルの設定ファイルを用意するなどして、何とかarm-palmos-gcc並みに使えるようにしてみた。
吐くコードは効率的で、気のせいか(^_^;)コードサイズは小さくなり、速度も僅かに速くなり、安定動作するようじゃ(^_^;)
ま、どの対策も、実機での実験が出来ない以上、効果の程は良く分からぬのじゃが、
多分、V2.01よりはマシになるじゃろう(^_^;)試してみてくだされ♪(^_^)
- V2.01β版リリース！
(2003/02/27)
皆の者、たて続けの登場で失礼するぞぇ(^_^;)
さて、NZ90ユーザを悩ます巨漢アプリと言えば何か？皆の者には分かるかのぅ？(^_^;)
それはNetFrontじゃ。素晴らしい出来のブラウザじゃが、
大きさは何と2MBじゃ(^_^;)16MBしか無いマシンでブラウザが2MBとは、
まるでWindowsでIEが1GBあるようなモンで、
気が狂ったような状態と言えるじゃろうのぅ(^_^;)
で、当然の心理として、PalmGZipで圧縮したくなるわのぅ(^_^;)ところがじゃ、これが出来んかったのじゃ。
で、知り合いから貰って調べてみたら、実はこいつは、次期PalmOS6が見えて来るような、
凄まじく特殊な構造をしている事が分ったのじゃ。
- アプリ(appl)でありながら、codeリソースもdataリソースもない
→68Kのコードが一切含まれていない！
- tで始まる標準のUIリソースがなく、代りにaで始まるリソースがある
→中身は標準のUIリソースと同じようじゃが、エンディアンが逆！
- 未知のタイプのamdc/amddというリソースがある
→amdcの中身はARMのアセンブラ(^_^;)
→(結論)実は、完全ARMアプリを作れる規格が
既に存在しており、PalmOS5.0(CLIEのみ？)には、それを実行する隠し機能がある。
勿論、この事はSONYもPalmも公表しておらんし、聞いても教えてくれんじゃろ(^_^;)
じゃが、この構造は、次期PalmOS6でのアプリの姿を窺わせるようで、楽しみな事じゃな(^_^)
ま、PalmGZipは多様な形式に対応しているので、これ自体は問題ない(ARMネイティブアプリでも圧縮伸張できる)のじゃが、
問題はNetFrontのamdc/amddのサイズじゃ。
何と、amdcが1.5MB、amddが350KBと、Palmの本来の制限サイズ64KBを遥かに上回る
巨大リソースレコードとなっておる。勿論、通常の方法(DmNewResource)ではこんなレコードは作れん。
という訳で、PalmGZipはNetFrontを圧縮できていたのじゃが、解凍の際に、この巨大レコードを再生成出来ずに、失敗しておったのじゃ。
PalmGZipの処理自体は64KB以上のレコードにも対応できるように作っておるので、後は、この巨大レコードが生成できるかどうかだけじゃ。
勿論、現にそういうレコードが存在する以上、何らかの生成方法がある筈じゃがな(^_^;)
・・・『何らかの生成方法』・・・あったんじゃよ、これが、『神の新技(?(^_^;))』が。
しかも、これはPalmOS4.0でも多分できると思われる(^_^;)
今回のV2.01では、通常の方法(DmNewResource)が失敗した場合のみ、この技を使う事にした。
これにより、NetFrontも解凍実行できるようになった♪(^_^)
ただ、この技を使うと、そのアプリはHotSync経由でのインストールもバックアップもできなくなる。
prc/pdbファイルの形式で、１つのレコードのサイズは64KBに制約されとるからな。
NetFrontの場合は、インストールファイルには特殊なカプセル化が施され、
インストールと同時にデバイスリセットして、特殊なARMコールをして自己書き換えするという、
翁のわしでもビックリするような、かなりトリッキーな技を使っておるようじゃ(^_^;)
バックアップはできんままのようじゃな。
個人的見解じゃが、正直、これはMS-DOS末期に見られたような危険な技で、多用すべきではないと思う。
多用すれば、OSの安定動作を損い、またOSそのものの存在意義が揺らぐ気がするのぅ・・・。
そんな訳で、技の解説はやめておく事にする。
早く、OSとして正式に、レコードサイズ制限が解除され、HotSyncも対応してくれると嬉しいのぅ(^_^)
ちなみに、NetFrontは2MB→890KBになり、解凍時間は1.5秒じゃ(^_^)
頻繁にNetFrontを使わないのなら、これで1MB空くぞ(^_^)活用して下され(^_^)>NZ90ユーザ
- V2.00β版リリース！
(2003/02/25)
みなさ〜ん、おげんきですかぁ！？(^_^;)
実に、１年半振りの登場となるのうぅ(^_^;)
これはまぁ、わし個人がズボラかました(^_^;)という理由もあるじゃろうが、
本質的には、もはやPalmGZipが必要なくなったというのが一番じゃと思う。
PalmGZipのような自己解凍実行型のアーカーバの必要性は、CPUパワーとメインストレージのアンバランスに
よってもたらされるものじゃ。すなわち、PalmOS 3.x時代、2MBのストレージはあまりにも狭すぎたので、
CPUパワーを消費して、プログラムのサイズを縮める事には意義があったのじゃ。
しかし、PalmOS 4.xの時代、ストレージは8MB,16MBと拡張され、随分と余裕が出来た。また、プログラムサイズも数百KB〜1MB超が
珍しくなくなり、解凍時間に数十秒要するようになり、解凍する事がストレスになるようになってきた。
加えて、メモリスティックやSDカードの等の外部ストレージメディアが整備され、自己解凍実行型アーカーバは必要なくなったのじゃ。
こうして、PalmGZipはもはや過去の遺物になったのじゃが、PalmOS 5.0の登場で、状況は一変する事になった。
既に、ご存知の通り、PalmOS 5.0は、CPUとしてRISCのARMをアーキテクチャーを採用しておる。この事は、次のような状況を生んだ。
- ストレージ量が相対的に低下 ... ARMのようなRISC CPUは、x86や68KのようなCISC CPUに比べ、一般的に
メモリー効率が悪い、すなわち、同じ処理内容のプログラムを書いた場合、CISC CPUに比べ、
RISC CPUはプログラムのサイズが大きくなる為、ストレージが相対的に狭くなるのじゃ。
PalmOS 4.0の時代は、16MB「も」あったメモリーが、PalmOS 5.0時代になると、
16MB「しか」ない、という事になる訳じゃ。
- 処理能力が飛躍的に向上 ... メモリー効率とは逆に、ARMのようなRISC CPUは、x86や68KのようなCISC CPUに比べ、
一般的に対消費電力、対クロック処理量が良いという事が言われる。
例えば、CLIE NZ90は、XScaleの200MHzのARM CPUを積んでおる。クロック200MHzと言えば、パソコンの感覚から言えば、
いかにも低速に見えるかもしれんが、実行速度で比較すると、(独断と偏見で、ざっくりと言うと(^_^;))Pentium 800MHzに相当する処理能力がある。
表面上のクロック数で騙されてはならんぞ(^_^;)しかも、表面クロックが低いという事は、消費電力が少ない、つまり、
バッテリーが長持ちするという事で、PalmのようなPDAにはうってつけのCPUと言えるじゃろうな(^_^)
そんな訳で、PalmOS 5.0用のPalmGZipを作る事には意義があるじゃろうという事で作ってみる事にした。
わし自身のARMプログラミングスキル習得も兼ねてな(^_^;)
移植ポイントは２つ。
- アプリ自動削除機能の移植 ... この部分は、HACKと同じような手法を用いて実現していたのじゃが、
既にご存知の人も多いじゃろうが、PalmOS 5.0ではHACKは動かない。当然、PalmGZipのこの機能も動かぬ。
そこで、PalmOS 5.0で導入されたHACKの代替機能Notification Managerを使って、この機能を実現する。
- 圧縮・伸張処理をARMネイティブで実行する ... PalmOS 5.0には、PACEと呼ばれる
68Kエミュレータがあり、既存のアプリは、この上で68Kコードのままで動作しており、大部分のアプリは
ARMに書き直す必要性がない。PACE上でも充分に高速じゃからじゃ。
唯一の例外が、暗号化関連の処理や、PalmGZipのような圧縮伸張処理のような、
CPUをガンガンにブン回すような処理じゃ(^_^;)
そういうアプリの為に、PalmOS 5.0にはPceNativeCallというシステムコールが用意され、
ARMネイティブで書いた処理を実行できるようになっておる。今回は、PalmGZipの圧縮伸張処理を
ARMネイティブでコンパイルし、PceNativeCallで呼び出すようにする。
では、まずは、どの程度の能力があるのか、わしが持っている中で、一番の巨漢アプリ(^_^;)
大戦略for Palm(1.5MB)を使って比較した結果を見てもらおう(^_^)
| 機種名 |
PalmGZip |
圧縮 |
伸張 |
PEG-T600
(68K 33MHz/Dragonball VZ) |
V2.00 for OS4.0
(68K code) |
225秒(7.2KB/秒) |
25秒(65KB/秒) |
PEG-T650
(68K 66MHz/Dragonball Super VZ) |
V2.00 for OS4.0
(68K code) |
122秒(13KB/秒) |
14秒(116KB/秒) |
PEG-NZ90
(ARM 200MHz/Intel XScale) |
V2.00 for OS4.0
(68K emulate) |
150秒(11KB/秒) |
15秒(108KB/秒) |
PEG-NZ90
(ARM 200MHz/Intel XScale) |
V2.00 for OS5.0
(ARM native) |
10秒(163KB/秒) |
1秒(1.6MB/秒) |
CLIE Simulator
(x86 2.4GHz/Pentium4) |
V2.00 for OS4.0
(68K emulate) |
80秒(20KB/秒) |
5.5秒(296KB/秒) |
CLIE Simulator
(x86 2.4GHz/Pentium4) |
V2.00 for OS5.0
(x86 native) |
1.7秒(958KB/秒) |
0.5秒(3.3MB/秒) |
68K 33MHzと比較して、実に20倍以上の性能が実現できたのじゃ♪(^_^)
66MHzのSuper VZのマシンと比較しても10倍以上あり、解凍時間は、大戦略のような巨漢アプリでも1秒程度だから、
殆ど気にならないじゃろう(^_^)
そんな訳で、まだβ版の段階じゃが、皆さんにも試してもらおうと思ってな、今回公開する事にしたのじゃ(^_^)
ちなみに、PalmGZip V2.00には、PalmOS 5.0用(PGZIPOS5.prc)とPalmOS 4.x用(PGZIP.prc)が入っておる。
OS5.0用は、さっき言った通りで、OS 4.0用は、基本的に、旧V0.94と変わりはないんじゃが、Palm OS3.x時代には、
メモリアロケーションの制限や、コールバック関数のバグなど、OS自体に問題があって、色々と神代の技(^_^;)を
使っておったが、PalmOS 4.0では、そのような技が必要なくなったので、そういうトリッキーな部分を削除して、
シンプルに安定動作するようにしてある。もし、あなたがPalmOS 4.0のマシンをお使いなら、旧版(V0.94)の代わりに
使ってくだされ(^_^)
・・・で、誠に申し訳ないが、後のPalmware開発者よもやま話でも言うように、色々な問題がある為、
PalmGZip自体は、引き続き、お賽銭ウェアのままじゃが、ソース差分公開は、当分、勘弁してくだされ。
自分で改造してみたいとか、ARMネイティブでプログラミングしてみたいという方は、まずは、
この後にある、わしからの助言(警告?(^_^;))を読んで熟慮してから、自力で取り組んでくだされ(^_^;)
さて、ここからは、Palmware開発者向けのよもやま話じゃ。あなたがPalmGZipを単に試したいだけなら、
ここから先は読まなくても良いぞ(^_^;)トップページに戻って、ダウンロードして試してくだされ(^_^)
Palmware作家の中には、ここまでの文を読んで、「自分でもARMプログラミングしてみたいなぁ」と
思った方もおられるかもしれんな(^_^)
じゃがな、悪い事は言わん、PalmOS 5.0のARMプログラミングはやめといた方が良いぞ(^_^;)
まずは、さっきも言ったとおり、性能比較表にもあるように、PACEのエミュレータの68Kコードの実行速度は、
66MHzのSuper VZ相当の能力に設定されておるようじゃが、PalmOSのシステムコールはARMネイティブで処理され、
劇的に高速化されておる。特に描画周りの高速化は凄まじい。
世の殆どのPalmwareの処理時間は、システムコールでの処理時間で占められており、ARMネイティブにしなくても
充分に高速化の恩恵は受けれるのじゃ。後に述べるような苦労をする位なら、何もしない方が幸せじゃと、わしは思うがな(^_^;)
何？「それでもARMプログラミングしたい！」とな？好奇心旺盛な方じゃて(^_^;)
ではな、わしからの２番目の助言じゃ。
悪い事は言わん、ARMプログラミングするなら、CodeWarrior V9.0を買いなさい。
今まで使っていたV8.x以前では駄目じゃぞ。つい最近発売されたばかりの最新のV9.0を買うのじゃ。(わしは使った事ないが(^_^;))
その理由は、この後に述べるgccベースの開発の問題点を見れば明らかじゃろう。
何？「開発費を掛けずに(フリーツールで)ARMプログラミングしたい！」とな？
ここまで言ってるのに、おぬしも奇特な方よのうぅ・・・(^_^;)
フリーと言えば、gccしかあるまい。幸い、68K時代には、prc-toolsという名で、gccベースの開発ツールが
整備されておったな。今までそれを使って開発してきた人は、それを継続して使いたいと思うのは自然な事じゃな。
prc-tools-2.2には、arm-palmos-gccなど、それらしい名前があり、また、PalmSourceからも
ArmletToolsDR2など、コンパイラとライブラリ、サンプルがセットになったものが出されていて、
いかにもフリーツールでも出来そうな気がするな(^_^;)
・・・では、わしからの最後の警告じゃ。
地獄へ行く覚悟は出来ておるか？(^_^;)
まず、ARMプログラミングの現実から教えてやろう。
- ハッキリ言って、OSもライブラリも、何もない ... ARMを実行する為のシステムコールPceNativeCallは
「ユーザ指定のパラメタを一つ渡し、指定されたアドレスから始まるARMコードを実行する」という機能をもつ。
逆に言えば、「それ以外の機能は一切ない」。
何がないのかと言えば、標準では
- Palm OSのAPIは全て使えない(自分でラッパーを作らなければならない)
- strcpyやisalphaなど、C言語の基礎中の基礎のライブラリも一切ない(自分で作らなければならない)
- 一番強烈なのが、グローバル変数や関数ポインタはおろか、文字列定数など、C言語としての当然の機能も動かない
- ARMはRISCであり、強いデータアラインメント制約があるので、C言語レベルでも、
アライメントを意識して注意深くコーディングしないと、見つけにくい、思わぬバグにハマる。
(その他、GOT fixup関連で、ポインタ系のグローバル変数初期化が動かないなど、幾つかの特殊な注意が必要)
- デバッグ環境が極めて貧弱 ... PalmOS Simulatorは、x86 nativeで動くPalmOS 5.0。
従って、PceNativeCallで呼ばれる先はx86のルーチン(Windows DLL)。PC上でARMルーチンを実行/デバッグする術がない。
(これが、POSEのようなPalmOS Emulatorとの大きな違い)、ARMのデバッグは実機で行わなければならないが、
PalmOS 4.0にあったようなデバッガ接続の為の機能(ARM debug nub)がARM側にはないので、結局、デバッガは一切使えない。
(デバッグは昔ながらのprintfデバッグ(PalmOSならFrmCustomAlertデバッグ?(^_^;))になるが、そのFrmCustomAlertも標準ではないので、
自分でラッパを作らなければならず、これさえもバグってしまったら、もはや、デバッグする術なし(^_^;)神代の昔の技、机上デバッグのみとなる(^_^;))
第1項の3番目の「文字列定数が動かない」というのは、ピンと来ない人も多いじゃろう。これはな、
int a;
a = 1;
というコードは動く(aは1になっている)けれども、
char* p;
p = "test";
というコードは動かない(pは"test"を指していない！)という事じゃ。
これで果たして、「C言語でプログラミングできる」という状況と言えるかな？(^_^;)
この現象の理由を理解する為には、OS(オペレーティングシステム)における、実行イメージのロードと実行の仕方と、
コンパイル時に(ユーザが知らないうちに、暗黙のうちにリンクされる)ctr0.o(void startup( void ))などの
gcc内部関数の動作を理解しなければならぬ。
解決策だけ言っておくと、これ直すには、実行イメージから、.data/.bss/.got sectionを取り出し、heapを確保してコピーし、
.got section内のGOTを.code sectionと.data/.bss sectionに分け、それぞれ正しいオフセットにfixupする必要があり、
そのためのstartupルーチンを自前で、ARMアセンブラで書く必要がある。
この説明では、大半の人がチンプンカンプンじゃろうな(^_^;)
チンプンカンプンな人には、gccを使ったARM開発は無理という事じゃ。
逆に、この説明で分かった人、そうなんじゃ、PceNativeCallはそんなレベル(単なるjump文)にしか過ぎんのじゃ。
これは、かなり高いハードルで、このままでは、本当に、単純なデータ処理サブルーチン位しかARMに回せないという事じゃ。
わしの場合、PalmGZipでは多数のHuffmanテーブルがあり、fixupせずに移植するのは困難だったので、
- gccオプションとして-fPICを指定して、shared library相当のオブジェクトを作り、
- 実行イメージは(.code/.data等全て)MemPtrNewで確保した領域に全てコピーし、
- コードの先頭に、GOTをfixupする為のオリジナルのstartupルーチンをinline asmを混ぜて書く。
という事をして、何とか「人並みのC言語環境(^_^;)」になるようにした。これをする為に、
ARMの命令セットを理解しなけりゃならんわ、gccのELFバイナリ形式を理解せにゃならんわ、
-fPICで吐かれるshared libraryタイプの実行イメージを理解せにゃならんわ、エライ目に遭ったわ(^_^;)。
第2項の問題の例を2つ示しておこう。これは実際にPalmGZipでハマった奴じゃ(^_^;)
char arg[2+4];
*((short*)(arg+ 0)) = 1;
*((long*) (arg+ 2)) = 2L;
(グルーバル変数として)
char buf[10];
char* pBuf = buf;
どちらも、C言語では良く見かける表記で、何ら問題はなさそうじゃが、
ARMの中では、両方×じゃ
まず前者。ARMはRISCであり、強いアラインメント制約がある。つまり、
- ワード(4byte)データは、必ず4の倍数のアドレスでアクセスしなければならない
(そうでないアドレスの場合、CPUレベルで強制的に4の倍数アドレスに揃えてアクセスする)
- ハーフワード(2byte)データは、必ず2の倍数のアドレスでアクセスしなければならない
(そうでないアドレスの場合、アクセス結果は不定)
なのじゃ。この例では、argが4 byteアラインメントされていたとすると、最初のshortの型キャストは、
4の倍数のアドレスからハーフワードを書き込んでいるので動くが、次のlongの型キャストは、
4の倍数のアドレス+2からワードを書き込んでいるので、CPUレベルで強制的に4の倍数アドレス、
つまり(arg+0)に変更されて書き込んでしまう。しかも、この時、68Kみたいなbusエラーは発生せず、
x86のように2回の書き込みサイクルを使って自動合成するようなマネもしてくれない。
黙って違うアドレスに書き込んで、吹っ飛ぶだけじゃ(^_^;)
RISCは、こういう検知や補正をしない分、単純で高速なのが特徴なのじゃが、プログラムする側は
本当に注意しないと、エライ目に遭うぞえ(^_^;)
正しくは、
char arg[2+4];
((unsigned char *)(arg))[0] = (unsigned char)((unsigned long)(1));
((unsigned char *)(arg))[1] = (unsigned char)((unsigned long)(1) >> 8);
((unsigned char *)(arg))[2] = (unsigned char)((unsigned long)(2L));
((unsigned char *)(arg))[3] = (unsigned char)((unsigned long)(2L) >> 8);
((unsigned char *)(arg))[4] = (unsigned char)((unsigned long)(2L) >> 16);
((unsigned char *)(arg))[5] = (unsigned char)((unsigned long)(2L) >> 24);
じゃ。argが2の倍数の保障がない場合は、最初のshortの型キャストの方も飛ぶおそれがあるので、
そちらもバイト展開しておくべきじゃろう。ちなみに、ARMは68Kと違い、x86と同じ、リトルエンディアンなので、
こういう風にしてあるが、こういう処理は、実際のARMプログラムでは、システムコールなど、
68K側のルーチンを呼び出す際に多用されるので、ビットシフトを逆順に並べて、
マクロ関数として定義しておくと便利じゃろう。
この問題は、CodeWarriorでも起きるじゃろうから、ARMに関する共通の注意点と言えるじゃろうな。
後者の例は、先ほど述べたgccのGOT fixup問題じゃ。この例では、pBufはbufを指していない。
先ほど述べたオリジナルのstartupルーチンで、殆どのオフセットを正しく参照する事が出来るようになったが、
この手の初期化子の中に他のグローバル変数のポインタが入っているものだけは、fixupされないようじゃ。
これは、コンパイルがshared libraryとして行われる点も関係しているのじゃろうな。これも、bus error等は一切出ず、
黙って実行しておかしくなるだけじゃ。非常に見つけにくいバグで注意が必要じゃ。
第3項の問題は、読んだ通りじゃ(^_^;)ARMのデバッグがどれほど大変か、お分かり頂けるじゃろう(^_^;)
ちなみにじゃが、これが今回、V2.00のソース差分を公開しない最大の理由なのじゃが、
実は、わしはPalmOS 5.0のマシンを持っておらん(^_^;)
デバッグや性能測定に使ったPEG-NZ90は、知り合いが買ったので、それを使わせて貰ったのじゃ。
だから、本格的なデバッグが一切できぬ。公開した以上、Tungstenなどで試される方も出てくるじゃろうが、
万が一、問題が起きても、わしには修正する術がないのじゃ。
(SimultorでのデバッグがARMプログラミングに関しては無意味なのは既にお分かりじゃろう(^_^;))
自力でデバッグできない以上、逆に公開すべきか？とも考えたが、さっきも言ったとおり、オリジナルの
ARMアセンブラルーチンなど、かなり開発環境依存な事もやっているので、普通の人たちに公開しても
無意味じゃろう、そう考えてな、公開は止めにした。
もし、Tungstenを持っていて、V2.00がバグって、自前で修正してみたいという、多分、とっても奇特な方(^_^;)が
おられたら、個別に連絡くだされ。検討させて貰おう(^_^;)
また、お賽銭が、PalmOS 5.0マシンが買える程に、多額にたまったら、その時はその時で、また検討させて貰おう(^_^;)(^_^;)
ま、当分、公開はない、と思っていただいて良いと思うぞ(^_^;)
- V0.94(00/06/04版)に致命的バグ！
(2001/06/06)
わっちゃ〜、やってしもうた・・・(;_;)
一昨日公開したV0.94(00/06/04版)じゃが、これには致命的なバグが含まれておる！
今、修正版V0.94(00/06/06版)をアップしたので、もし、あなたが旧版のV0.94を
使っておられるなら、速やかにインストールし直してくだされ。誠に申し訳ない<(_ _)>
・・・しかし、gccにはやられたわい(^^;長らく、Palmwareの開発をしておらず、
その間に開発環境がNT4.0→2000に変わってな、それに伴ってgccもアップグレード
してたんじゃが、今まで一回も使ったこと無かったんじゃ。
そんで、今回初めて使った訳だが、何と、ソースは一切変えてないのに、究極のハッカー技:asm(...)の所で、
BusErrorを起こすようになってしもうてた(^^;
(そんな技使うからじゃ！とは言わんでおくれ...(^^;)
しかも、必ず落ちる訳ではなく、不定期に落ちるので気が付かずにアップロードしてしもうた。
しかも落ちる時は、フルリセットを掛けないと直らない、全データが消滅するという、
まるでウイルスかボムのようなバグになってしうもうた。
落とされて、フル復元させられるハメになってしまった方々、誠に申し訳ございませぬ。<(_ _)>
その他にも、
- まだアーカイブがない初回起動時に落ちる
- J-OSとPalmOS日本語版では、文字列の並びが違う(StrCompareが違う結果を返す)ので、
自前でStrCompareを作成
- ソート処理(クイックソート)にミスを発見
などなど、細かいバグも色々発見したわなさ。(^^;
たかがリストのソートだと思って、なめて掛かったのが失敗だったな
「プログラムはやっつけ仕事でやってはいけない。自分のプログラムほど、アテにならないものはない。」
という、神代からの金言は、現代においても有効なようじゃ。(^^;
何にせよ、改めまして、フル復元させられるハメになってしまった方々、誠に申し訳ございませぬ。<(_ _)>
- V0.94リリース！
(2001/06/04)
皆のもの、まだわしの事をおぼえておるかえ？(^^;最近は、俗世の事に忙しく、
すっかり、Palmwareを作っておらんので、皆から忘れられてしもうたかもしれぬな(^^;
今日の用向きは、PalmGZipのエンハンスじゃ。
つい先程、当神社に手厚いお賽銭と願い事があってのぅ、そこには、PalmGZipに対する感謝の念と共に、
- 圧縮リスト表示がABC順で並べられないかと思っています。
・・・ってな感じの事が書いてあった。なる程、あった方が便利じゃな(^^)
データベースの方の並べ替えは、データ数も多く、色々と困難な点があるのじゃが、
圧縮アーカイブ側だけで良いのなら、そう大した手間でもあるまい。
まして、手厚いお賽銭を頂いたとあっては、望みを叶えぬ訳にはいくまいて(^^;
そんな訳で、機能的には何も変わらんが、使い勝手向上という意味で作っておいたぞよ(^^)
使いたい人は使って見て下され(^^)
- V0.93リリース！
(2000/10/25)
皆のもの、息災かえ？(^^;最近、割と頻繁に更新しておるのぅ(^^;
さて、今日現れたのは他でもない、PalmGZipをエンハンスしたからじゃ。
何でエンハンスしたかというと、実は、驚いた事にガイジンさんからメールを頂いたのじゃ(^^;
(わしは、このページでしか公開しておらぬし、このページは日本語onlyじゃ。どこでどうやって流れていったのじゃろうな？(^^; )
勿論、そのメールは英語で書いてあったんじゃが、まぁ内容を要約するとじゃな、
- PalmGZipはシェアウェアのPalmzipより出来が良いね♪(^^)
- "create SFX Alias"がチェックされていて、Preferenceの"App self-delete on SFX exec"も
チェックされている(標準の設定だな)時は、圧縮に成功して起動用のエイリアス作ったら、
元のアプリケーションは削除した方がいいんじゃない？
だって、折角圧縮したんだから、無駄にメモリーに残しておく必要ないじゃん(^^;
- それと、今現在のアーカイブのサイズと平均圧縮率を表示してくれたら嬉しいな♪(^^;
- ちなみに、アーカイブは"Archieve"じゃなくて"Archive"だよ(^^;（うっ・・・(^^; )
・・・ってな感じじゃった。なる程、指摘は最もな事じゃな。まぁ、初回起動されたら
元のアプリは消されるんだから、あんまり緊急性はないが・・・(^^;
まぁ、誉めてくれてるし(最後のはチクっと来たが(^^;)、大した改造じゃないので
直しておこうかのぅ・・・という訳で、作ったわけじゃ。
言わば、機能的には殆ど変わらん訳だが、使い勝手という意味じゃ、中々、良い改造かも
しれぬ。
まぁ、使いたい人は使って見て下され(^^;ま、V0.92のままでも問題ないと思うがな(^^;
- V0.92リリース！
(2000/07/10)
いや〜、またまた更新が久しぶりになってしもうたのぅ(^^;
これからは、わしの事をハレー彗星の翁と呼びなされ(^^;
(誰も呼ばぬか・・・(^^;)
さてさて、このGalmGZip、先日行われたソフトバンクの雑誌・DOS/V magagine主催の
Palmwareコンテストに応募しとったのじゃが、な、な、なんと！！(^^;
準入選相当のPalmComputing賞を受賞
してしもうた(^^;
元はと言えば、編集部から「応募してくれぃ！」とのメールが来たので、
「あ、別にええよ(^^)」と軽い気持ちで送ったもので、本人さえも
すっかり忘れてたんじゃがな(^^;
まぁ、大賞がない事からも分かる通り、今回はきっと、神様と御一行様(^^;が
応募辞退したりと、あんまり競争相手が居なかったので、こういう結果に
なったんじゃろうな(^^;ま、何にしても、あり難い事じゃて♪(^^)
まぁ、受賞も嬉しいが、何と言っても嬉しいのは、副賞として
PalmVxとPalmIIIcを贈呈された事じゃな♪(^^)
一気にPalmが３台になってしもうたわいな♪(^^)
そんな訳で、編集部から贈られたPalmVx,PalmIIIcでキゲン良く遊んでたのじゃが、
・・・・・・あり？PalmGZipの動きが変(^^;アーカイブリスト部分の表示が
ＵＩ操作に関わらず変化しない。あり？あり？？？(^^;
でまぁ、色々と調べてみるとじゃな、どうやら、
PalmOS V3.5は、V3.0に比べ、テーブル関係の所に仕様変更がある
のが原因で動かなくなったらしい。
具体的には、TblSetCustomDrawProcedureで呼ばれるコールバックプロシージャ
(TableDrawItemFuncType)じゃがな、以前は、グローバル変数やスタティック変数に
アクセス出来ていたが、V3.5では完全に独立したヒープ空間を割り当てられて呼ばれる為、
アプリ側のグローバル空間の参照が出来なくなったようじゃ。
まぁ、コールバックからグローバルへのアクセスは、あまり行儀の良いプログラムじゃ
ないからのぅ、ま、わしのプログラミングが悪いのじゃが・・・(^^;
さりとて、一度、グローバル前提で書き上げたコードをオブジェクト指向型の局所
グローバルプログラミングで書き直すのは結構、面倒じゃ。WIN v3.1→mfcの例を
出すまでもなくな。
そんな訳で、またもや悪魔の技(^^;で、取り合えず
動くようにはしておいた。これをV0.92として公開するので、PalmOS V3.5のユーザの方は
これを御利用くだされ。(もっとも、メモリーが8MBもある V3.5では、当面、PalmGZipの
出番はなかろうがな・・・(^^;)
- V0.91リリース！
(2000/01/05)
いや〜、更新も久しぶりじゃのぅ(^^;皆、息災か？(^^)
最近、わしはSimCityとSnapConnect for c3を買ってゴキゲンじゃ(^^;
(ちなみに、SimCityではメガロポリス市長にまでなって、世界2位に登録
されたぞぇ♪(^^)奇特な方々は、こちらで御覧下され。)
(→SimMayor Hall of Fame)
さて、SimCityやPalmscapeなどの重量級のアプリをPalmGZipで扱っていると、
頻繁にFatal Errorが起こるようになってのぅ。ちぃと調べてみたら、
次のような事が分かった。
- 空き容量不足の時に圧縮・解凍するとFatal Errorになる。
... すまん、これは、わしの手抜きじゃ(^^;チェックルーチンを入れておらなんだ(^^;
- Palmscape,POPJなど内部からモデム/ネットワーク等の環境設定を行うアプリを
自動削除機能付きで自動伸長実行した場合、設定を終わらせた時にFatal Errorになる。
または、アプリが削除されずに残ってしまう。(ダイアルアップ接続した場合にも起こる。)
... PalmOSでは、モデム/ネットワークの設定などは、実は別アプリとして
実行されておってな、設定が終わると、自動的に元のアプリを再実行する仕掛けとなっておる。
自動削除付きで実行すれば、設定に行った時点で削除されるので、戻ってこようと思っても、
もはやアプリは存在せぬ。そりゃ、落ちるわな(^^;
まぁそんな訳で、この２つを中心に修正してみた。今まで、これらの現象でお困りだった方々、
試してみて下され(^^)
なお、解凍を行うには、一時的なバッファが約250Kバイト、そして、解凍後のファイルサイズ分の
空き容量が必要じゃが、空き容量ギリギリのサイズで解凍すると、PalmOSの動作が怪しくなる
ようなので、更に100Kバイトの空き容量を余裕としてみておる。つまり、
解凍するには解凍後サイズ+350Kバイトの空き容量が必要と覚えておいてくだされ。
-
動作確認は、今の所WorkPad/c3のみじゃ。ただ、身近に
PalmPilot Pro+J-OS(Free版)を持った奴が居るので試して貰ったが、
とりあえずは動くようじゃ。PalmOSのVer.が3.0以上なら
問題なかろう。
-
ただし、こういうプログラムの性質上、アセンブラを使用したり、
System Onlyの機能を使ったり、果ては、システムコールの乗っ取りを
やったりと、相当危険なプログラム
であると心せよ。
こうやって、世間に公開する以上、最低限、自分で使ってて問題になる
ような個所は全て潰してあるが、まだα版のテスト中じゃ。
使う前に必ずフルバックアップを取って
いつ完全リセットで中身が飛んでも構わないように
心して使用せよ。
-
開発は、gccで行っておる。ソースも真のフリーウェア精神に従って
公開しておるので、活用して下され(^^)
一緒に置いてある元のgzipソースは、gzip-1.2.4として、広く
配布されているものじゃ。他のサイトから取ってきても良かろう。
-
PalmOSはUNIXやWindows,MS-DOSなど、およそデスクトップ用OSとは
えらく違うので、随分と改変/追加しておる。
特に、
-
データーベース型補助記憶システムなので、open/read/write/closeは
独自のエミュレータを作って対応。
-
(MS-DOSでも出来る(^_^;))64Kバイトの配列allocが出来ないので、
特殊な独自allocルーチンと、32Kバイト配列でも動くように、
アルゴリズムそのもののチューニング。
-
自己解凍実行用のマイクロアプリテンプレートと自己削除用の
システムコール乗っ取り。
など、幾つかの『神代の失われし技(=当時の通称:893技(^_^;))』を
使っておる。その他、
-
lzh/packなど複数形式対応機能の削除。deflate/inflateのみ。
これに伴い、余計なファイルヘッダなどは全て削除して、小型化。
-
Palm用UIソースの追加。
なども行っておる。
これは、御神体(Palm)にGNUのgzipを移植したものじゃ。