Simultaneously http://www.grenvillecollege.co.uk/ pay day loan like soluble prioritise the political fight for a better deal for pay . * OSECPUのQ&A #0000 -(by [[K]], 2013.05.25) ** これはなあに? -今まで寄せられた質問にこちらで答えることにします。誰かが分からないことは、他の人にもきっとわからない。二度同じことを答える余裕はきっと僕にはないから。 ** Q&A -''[Q0000] CND命令って何ですか?'' --CND命令は、後続の1命令が条件付きであることを示します。CND(R11); R12 = 1; みたいにすると、R11の内容によって、 R12=1; を実行したりしなかったりします。 --CND命令は指定されたRxxレジスタの最下位ビットだけを見ます。つまり奇数か偶数かしか見てないわけです。最下位ビットが1だと後続の1命令を実行します。0だと実行しません。 --OSECPUは条件分岐や条件MOVなどの命令を持っていないのですが、このCNDプリフィクスを使うことで、普通の分岐命令を条件分岐命令に変えることができますし、普通の代入命令を条件代入命令に変えることができるのです。 -''[Q0001] C言語からASKAに変えるツールはありませんか?ないとしたら作る予定は?'' --現状ではそのようなツールはありません。作る予定も今のところはないです。ASKAはアセンブラとしては結構優秀なので、C言語はなくても困らないかなーと[[K]]自身は思っています。 --もちろんそう思わない人もいるでしょう。その人が作ることを妨げるつもりは全くありません。もしうまくできたら教えてください。 --なおASKAだけでも最終的には[[memo0003]]の 2013.04.13 Sat の理想形くらいのソースは処理できるようになります。結構C言語っぽくて満足かなと自分では思っているのですが・・・。 -''[Q0002] OSECPUのスタックの使い方は?'' --OSECPUでは、バイトコードのJITコンパイルにあたっては、PUSH/POP/CALL/RET命令を使わずに翻訳しています。そのためESPレジスタの値は基本的に不変です。 --ただ例外があって、それはバイトコード側からosecpu.c内のC言語の関数を呼び出すときです。このときは引数をPUSHしますし、呼び出しもCALL命令を使っています。これはやむをえずそうしているのです。こうしなければC言語で書かれた関数は呼び出せません。 --ESPのスタックを基本的に使わない理由はいくつかあります。 ---スタックをいじってしまうと、スタックにまつわるセキュリティ問題に巻き込まれやすい(気がする)。 ---OSECPUの命令セットはそもそもスタックを前提にしていないので、特に使う理由がない。 ---ちなみにESPなスタックを使ってはいないものの、独自に管理しているスタック状のデータ構造体は持っている。そうしないと再帰などができないから。 -''[Q0003] OSECPUはgithubを使わないんですか?'' --ええと最初は使おうと思っていました。 https://github.com/h-kawai/osecpu_ver000 に残骸が残っています。しかしどうもうまく行かなくて(会社のアカウントの設定と混ざった?)、ここで数時間をつぶすくらいならOSECPUを少しでも書いたほうがマシだと思い、現在のようなレトロな方式に至っております。 --(2013.06.27追記)Livaさんのご好意で、githubもできました! https://github.com/liva/osecpu -''[Q0004] OSECPUのライセンスはどうなっているのですか?'' --そうですね、今まで手抜きでライセンスについて全く触れてきませんでした。KL-01というオープンソースライセンスを適用します。 --ライセンス文はここで読めます。→ http://osask.net/w/497.html --KL-01には明記されてなかったと思いますが、派生物(改造したもの)にOSECPUを名乗らせるのは原則としてはできません(事前の許可を取ればできます)。ドキュメント及び著作者名表示も含めて無改造なら問題ありません。名称問題は商標権などにも関係する問題で、これはオープンソースとは別の問題です。 -''[Q0005] ASKAがよくわかりません!'' --すみません!!それはつまりドキュメントが足りないということですよね?それとも文法がC言語の方言みたいになっていて気持ち悪くて生理的に受け付けないということですか?もし文法のほうが問題なのでしたら、それはすぐにはいかんともしがたいので、言語を作っていただくか、もしくはOSECPUを当面の間スルーするしかないように思います。残念ではありますが。 --ドキュメントが少ないということでしたら、それはセキュリティキャンプの事前学習が始まるまでには準備します。そうしないと始まりませんからね・・・。 --で、文法が気持ち悪いのほうに話を戻しますが、まずASKAはアセンブラです。アセンブラというのはCPUごとにすごく違っていて、代入一つとっても、MOVだったりLOAD/STOREだったり、まあいろいろあるのです。僕はそれを覚えるのがだんだん嫌になってきました。条件分岐のJccのccの部分も嫌いでした。そういえば分岐命令がBccのCPUもありますね。 --そこで代入はイコールでいいじゃないか、条件分岐はifで書けばいいじゃないかということになりました。ただそれだけのアセンブラがASKAです。その割り切りさえ飲み込めば、ASKAにいろいろな制約があることもきっと受け入れられます。アセンブラなのですから、できないことがたくさんあるのは当たり前なのです。 --ASKAのいいところは、とりあえずなんとなく「読める」ことです。書けるようになるためには禁止事項を覚えなければいけませんが、読むだけならそんなの関係ないわけです。他のCPUのアセンブラではこうは行きません。まず読めないのです。その分だけマシなんです。・・・とりあえずそういうことにしておいてください。 --詳しいことはドキュメント待ちということで。 --ちなみにどうしてドキュメントをなかなか書かないのかといえば、ASKAがまだ未完成だからです。現状の文法でもいろいろ書けはしますが、しかし実装予定の機能をもう少し足せば、ドキュメントが一気に書きやすくなるんです。だからそれができてからドキュメントを書きたいんです。それだけのことなんです。あなたがプログラマなら、この気持ち、きっと分かりますよね? --あとOSECPUで使うASKAはOSECPU-ASKAで、Google検索で出てくるASKA(以降これをOSASK-ASKAと書き分ける)とは別物です。はっきり言ってOSECPU-ASKAのほうが完成度高いです。でも代入が=で書けるとかif文があるなどの基本コンセプトは同じです。 -''[Q0006] app0006でASKAコードでは点を打った後で再描画命令を走らせてません。なのに、どうしてウィンドウが描画されるのでしょうか?もしかして、アプリ終了時にOSECPU側で再描画命令を走らせてますか?'' --はい、ご明察です。OSECPUは以下の条件が成立すると、(結果的に)終了時に再描画命令が自動で実行されます。 アプリ内でグラフィック命令を使ったのに、sleepを一度も呼び出していない。 --この条件が成立すると、[[page0039]]の(1)の説明にあるように、junkApi_sleep(0, -1);が自動実行されます。 --そしてこのsleepがウィンドウ全体の再描画命令を含んでいるのです。 -''[Q0007] R00~R1F, P01~P1Fがローカルレジスタってことになっているけど、呼び出し元でR00=5にしておいたら関数内でもR00=5になっているみたいなんだけど、これはどういうこと?本当にローカルになっているの?実はグローバルだったりしない???'' --これはいい質問です。基本的にこれらのローカルレジスタは、呼び出し元の値がすべて引き継がれます。ですから必要ならそのまま利用していただいて構いません。つまりR30とかじゃなくても、R00などを引数代わりにすることも可能と言うわけです。 --そしてこれらのローカルレジスタの値は、関数内でどのように変更したとしても、関数から出るときに元の値に戻されます。そういう意味で「ローカル」なのです。 -''[Q0008] P30って汎用レジスタ?関数の戻り先のための特殊レジスタじゃないの??'' --これもいい質問です。P3Fが特殊レジスタだったので、確かにP30もそう見えるのは妥当だと思います。 --しかしこれは汎用レジスタで、関数呼び出し時以外は、他のテンポラリレジスタと同様に好きな用途に使ってもらって構いません。 -''[Q0009] JIT-VMで動かすより最終的にはネイティブコードにプリコンパイルした方が早そうな気がしますが何故JITなのでしょうか?'' --プリコンパイル方式だと、OSECPUのバイトコードの方ではなく、コンパイル後のコードが出回ることになる可能性があります。そうなれば、それはx86のコードのそのものなので、もはや中で何をやっているかは配布元を信じるしかなくなります。つまりセキュアではなくなるのです。OSECPUのバイトコードなら、どんなにひどいコードであってもシステムを破壊することはできないので、僕たちユーザは安心して他人が作ったプログラムを実行して遊ぶことができます。 --また現在のところ、JITコンパイルにかかる時間は1ミリ秒とかその程度なのですが、これならJITコンパイラをデフォルトで考えていいと僕は思っています。 -''[Q0010] PALMEM0やPASMEM0の第三引数に間違えてRレジスタを渡すとコンパイラが落ちる!'' --すみません、それはその通りです。PALMEMなどは引数チェックをしないマクロで即席で作っているので、そういうミスには弱いというか無力です。どうか当面はいたわって使ってあげてください。将来的には何とかしたいです、もちろん。 -''[Q0011] P30って関数の引数を渡すのに使っちゃいけないの?'' --関数を呼び出すときには、リターンアドレスを伝える必要があります。そうしないとOSECPUでは戻ってこられないのです。ということで、P30はリターンアドレスを伝えるために使われます。つまり暗黙の引数なのです。ということで、一般的なポインタ引数はP31から自由に使えることになります。 -''[Q0012] OSECPUは今のところ他のOSの上で動くVMでしかないけど、これは「とりあえず」そうしているだけで、本当は独立したOSになりたいんですよね?そこからが本番なんですよね?'' --うーん、まあどれが本番かと聞かれると自分でもよくわからないのですが、しかし現在のVM方式は、「とりあえず」ではありません。これはこれで大切なOSECPUの実行形態です。 --OSECPUが目指していることの一つに「すべてのOSの底上げ」ということがあります。つまりすべてのOSにアプリケーションを提供できるようになりたいのです。これがあれば、新規にOSやCPUを開発しても、とりあえず20KB程度のosecpu.cさえ移植すれば、OSECPUアプリがすべて引き継げるということになります。だからOSやCPUの開発者は、既存の物との互換性なんか気にせずに、自分の思いのままの仕様のOS/CPUが作れるはずです。そうやっていろいろなOSやCPUが生まれて競争していけば、きっとより良いものが残っていくでしょう。 --OSECPUは完璧とかオールマイティを目指していません。・・・小規模かつ高い移植性を追求した結果、基本的な命令しかサポートできず、それゆえに各CPUの最高速度は出せないのではないかと思われます。高い性能が求められるアプリについては、各OSのネイティブアプリとして実装されればいいと思っています。この妥協があるからこそ、OSECPUは現在の品質を達成できているのです。そもそもアプリのすべてに高い性能が必要なわけではありません。それに専用アプリがそろうまでは、OSECPUアプリで妥協するという選択肢もあり得ます。そういう「選択肢の提供」「すみわけ」を実現するためにも、OSECPUのVM版は必要な形態なのです。 -''[Q0013] signedな右シフトしかないの?unsignedな右シフトがほしいよう!'' --ほほう、これはなかなかマニアックな質問ですね。はい、ちゃんと手段は検討済みです。 --(a) 1ビットだけシフトしたい場合: i >>= 1; i &= 0x7fffffff; これでOKですよね? --(b) nビットシフトしたい場合: i >>= n; i &= (0x7fffffff >> (n - 1)); これでOKですよね? --(a)が理解できれば、(b)も理解できると思います! -''[Q0014] フロントエンドコードをバックエンドコードに変換したいのですが、何かいい方法はありますか?'' --はい、まさにOSECPUは内部でそれをやっていますので、OSECPUにやってもらいましょう。 --たとえばコマンドラインで、 prompt>osecpu app0000.ose debug:2 --としてください。すると普通に実行される直前に debug2.bin というファイルが生成されます。これは内部で生成されたバックエンドコートです。ファイル名を*.oseに変更すればそのまま実行もできます。 --最近のバージョンでは、内部の手抜きの都合でちょっとNOP命令が多めに入っているところもありますが、まあそれは許してやってください。 -''[Q0015] app0080とかを見て思ったのですが、x*yメモリ領域をx*y画像とみなして一気にフレームバッファへ複写する命令があれば、アプリはもっと小さくなりませんか?'' --おお確かに!小さくなるだけではなく実行速度も上がりそうです。採用します! ** こめんと欄 -このページにこめんと欄はありません。このページの内容にコメントしたいときは[[impressions]]にお願いします。