![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
* aclib #3 -(by [[K]], 2020.09.09) ** (1) メモ -[2020.09.09(水) #1] --osdev-jpのkagura1050さんにとてもいいことを教えてもらいました。古い環境とかだと、SDL2用のドライバはないけど、SDL1用のドライバがある、というケースはまあまああるそうです。だから、aclibもSDL2だけではなくSDL1用も作れば、それらも全部サポートできることになりそうです。 --ぜひやりたいです。 -[2020.09.09(水) #2] --aclibは[[K]]にとって全く新しいことをしているというわけではなく、以前に使っていたblaライブラリを手直しして、SDL用のドライバを書いて、hrb_esb02bの時に作ったドライバも使って、それで整理した程度です。 -[2020.09.09(水) #3] --aclibみたいなライブラリってどうやって作っていくのが賢いのかな。まずSDL版かWin版か、まあどちらでもいいけど、とにかくどちらかに絞って必要な機能をそろえて、それからほかの環境向けに移植していくのがいいのかな。 -[2020.09.11(金) #1] --よしわかった。SDL2.0版を先に作ればいいんだ。最初にWindows版を作ろうと最初思ったけど、それだどSDL2.0版ができるまでblaライブラリと同じことを繰り返すだけになってしまう。 -[2020.09.11(金) #2] --いろんなビット数のCPUで問題なく動くようにすることを考えると、気軽にintとかを使うべきじゃないなと思いました。intの幅はCPU依存なので（C言語の規定では16bit以上にせよとしか書かれていない）、それだと期待通りにならないケースもありそうだなと思いました。 --ということでAInt16とかAInt32を積極的に使うことにします。 -[2020.09.14(月) #1] --デバッグモードが全くできていないですが、グラフィックのほうはそこそこできるようになってきたので、そろそろ一度uploadしようかなと思っています。 -[2020.09.18(金) #1] --昨日totoさんにmandel.cでの不具合を教えてもらえて、原因を考えて、今日になってひらめいたのですが、やっぱりこういうのって、ライブラリとして言語本体よりも先に公開したからだよなあと思いました。ライブラリはまだ規模が小さいので、問題の切り分けが簡単なのです。言語の一部として組み込まれて公開していたら、きっと切り分けられなくて直せなかっただろうなあ、と。 -[2020.09.18(金) #2] --大雑把に言って、どういう順番で開発を続けようかなと迷っています。現状、aclライブラリはただのSDL2.0のラッパーライブラリでしかありません。これがSDL以上のものであるためには、SDLにできないことができなければいけないです。そうすると「はりぼてOS」向けのaclライブラリを作ることを優先するべきでしょうか。しかしなあ、きっと作ってもほとんどだれも使わないような気はします。そうすると、それは「aclライブラリはSDLライブラリよりも移植しやすい」という証明をするためだけの存在で、なんだかなーという気はします。 --それよりもデバッグ支援機能を先に作るべきでしょうか。そうするとSecHack365との整合性はかなり良くなります。ライブラリに何ができて何ができないか（＝言語からやらなければ実現できないことは何か）を明確に示すことができるでしょう。それはそれで有意義なことです。 --一方で、aclライブラリを利用したアプリをもっとたくさん書くとか、チュートリアルを書き足すとか、そっちの方向性もあり得ます。 --さらに、aclライブラリはこのあたりで一区切りということにして、言語本体の開発に注力する道もあります。 --ということで、選択肢がたくさんあって、忙しいなあという感じです。 --（まあでも、「はりぼてOS」向けのaclライブラリの移植は大した手間ではないので、悩んでいないでさっさとやってしまえばいいような気はします。） -[2020.09.20(日) #1] --SDL2.0って適当に使っているとうまくいかない場合があるのがわかってきたので、それも吸収できるライブラリになれたらいいなあ。 -[2020.09.22(火) #1] --SDL2.0はおそらく複数の人々によって実装されていて、機種によってドライバの完成度は多少の差があるのではないかと思うようになりました。そういうときに、「これはSDL2.0の仕様違反なのだから、aclライブラリが正しく動かなくてもacl側のせいではない」と言ってしまうことも十分可能だとは思います。 --しかし私はOS自作経験者で、OSのドライバを書くときはそんなふうに言ってみてところで手持ちのハードウェアが動くようになるわけもなく、結局優先するのは仕様ではなくて実機でした。建前よりも現実です。 --ということでaclライブラリでもSDL2.0の挙動がちょっと微妙だったり未実装部分があるかもしれないという前提にたって、細かい制御オプションを付けておくことにしました。 --今日作った「-DAOPT_FORCE_LEAPFLUSH=100」は、もしSDL2.0側がウィンドウ状態の変更を通知してくれなくても、常に一定間隔（この例では100ms）でflushすることで、画面が壊れないようにします。 -[2020.09.23(水) #1] --[[aclib20]]にkray.cを書きました。ずっと前からこれを書きたいと思っていたので、それがかなってうれしいです。 -[2020.09.25(金) #1] --aclライブラリのWindows版を作り始めました！ -[2020.09.25(金) #2] --aclライブラリのWindows版がおおむねできたかも！間に合えば今夜中にuploadします。 -[2020.09.25(金) #3] --uploadしました！ → [[aclib21]] -[2020.09.28(月) #1] --このaclライブラリは、単にグラフィック描画APIを共通化するだけではなく、セキュリティにも配慮することが期待されています。なぜならaclライブラリはSecHack365の教材という側面もあるからです。 --ということで、「セキュリティを意識したライブラリ」として、デバッグモードを実装しています。デバッグモードにすると、ライブラリ関数に渡される引数でおかしなところはないか、しつこくチェックするようになります（代償として実行速度は低下します）。 --でも実装しながらこうも思うのです。「こんなポカミスを検出できるようにしたところで、それで助かる人なんて実際いるのだろうか。結局何の役にも立たないチェックなんじゃないか」と。 --そうしたら、なんと・・・invader.cをデバッグモードでコンパイルして実行したら、バグが見つかってしまいました（笑）。早速有用性を自ら証明してしまいました。ちょっと情けなくて恥ずかしいけど、役に立ってよかったです。 -[2020.09.28(月) #2] --aclライブラリでは、デバッグモードの時に、任意のポインタを渡すと、そのポインタでアクセス可能な下限（つまりmallocのときに返されたアドレス）と、アクセス可能な上限（つまりmallocのときに返されたアドレス+サイズ-1）の両方を高速に返す機能を提供するようになります。 --この情報を使って、デバッグチェックの際にアクセス違反がないかどうかをチェックすることができます。mallocしていない領域をfreeしようとしたとか、mallocしたときとはちょっとずれたアドレスでfreeしようとしているなどの場合は、malloc内部のヒープチェーンがおかしくなるようなことはなく、すぐにエラー終了するようになります。 --ヒープチェーンが壊れると、結局どのfreeがまずかったのかを突き止めるだけでも大変な苦労をするのが普通ですが、aclライブラリではこれが簡単に発見できるようになるというわけです。 --aclライブラリでのウリは、任意のポインタからこの下限上限を得るのにかかるコストがO(logN)で、またmallocやfreeやreallocの追加コストはO(1)で済むというところです。 --だからデバッグモードでこの機能をONにしてもアプリケーションは少ししか遅くなりません。 -[2020.10.06(火) #1] --最近作っている機能を紹介しておきます。まずmalloc/freeをすべて監視して、内部にリストを作り、mallocすればリストに追加され、freeすればリストから消える、そういうものを作りました。 --これでfreeし忘れ（＝メモリリーク）や、freeの間違い（＝mallocしていない領域をfreeしまうバグ）を簡単に検出できるようになりました。 --この機能を背景に2017年に作っていたfast-indexをaclライブラリ向けにリメイクしました（厳密には、配列とKISLを動的に切り替える旧KCL_FastIndexのリメイクではなく、KISL部分だけを作り直したものです。 --作り直しでの体験としては、このmalloc/free監視機能によってバグが見つかることはなかったのですが、しかしそれでもバグっていないことを確認することには大いに役立ちしました。安心感が違います。 --ということで手ごたえがあったので、今後はmalloc/freeだけではなく、init/deinitも同じような仕組みで管理しようと思っています。だからその部分を開発中です。 -[2020.11.01(日) #1] --もっとアプリを増やしたいと思っていて、今はOSASKアプリからの移植を検討中です。まずは20年くらい前のアーカイブを発掘しなければ！ -[2021.01.13(水) #0] --aclをどんどん拡張して、いろんなことをやらせたいと思っています。まずは任意の構造体をファイルにセーブしたり、ロードしたり、表示したりする機能を付けたいと思っています。 -これがあると何がうれしいのかといえば、まずデバッグに使えます。データ構造がどうなっているのかじっくり確認するのが楽になるはずです。・・・今までは、「一度確認すべき」ということはわかっていても、表示させるのがめんどくさいからまあいいか、になりがちでした。それがもっと気楽にできるはずです。 -次に設定ファイル読み込みなどに使えます。アプリ側でせっせとパースしないでいいのでだいぶ楽になるはずです。 -そしてこの機能は、将来タスクセーブを実現するためにも使う予定です（というか、そもそもそれをやりたくてあれこれ考えてできた副産物です）。 --これがあると何がうれしいのかといえば、まずデバッグに使えます。データ構造がどうなっているのかじっくり確認するのが楽になるはずです。・・・今までは、「一度確認すべき」ということはわかっていても、表示させるのがめんどくさいからまあいいか、になりがちでした。それがもっと気楽にできるはずです。 --次に設定ファイル読み込みなどに使えます。アプリ側でせっせとパースしないでいいのでだいぶ楽になるはずです。 --そしてこの機能は、将来タスクセーブを実現するためにも使う予定です（というか、そもそもそれをやりたくてあれこれ考えてできた副産物です）。 * こめんと欄 #comment
