* decoderの利用
-(by [[K]], 2013.08.21)
** (0) はいけい
-[[hikarupsp_FrontEndCode]]を支援したい。
-OSECPU-VMでは、フロントエンド→バックエンドの変換をOSECPUアプリでやっています。なぜなら、こうしておけば他のCPU向けに移植するときに変換ルーチンを移植しないですむからです。
-[[hikarupsp]]さんはJavaScriptで変換しようとしているけど、変換をOSECPUアプリでやるほうが楽なんじゃないかと考えました（バージョンアップに追従するのも簡単です）。当然ですが、この変換アプリはバックエンドコードだけで書かれています。
** (1) きほん
-変換アプリはどこに入っているかですが、syslib.oseの中に入っています。しかしこれはライブラリ形式になっている上に、独自の簡易な圧縮がかかっているために、取り出すのは少々面倒です。ですからソースから.oseファイルを作ることにしましょう。
 prompt>amake0 decoder osectols.exe -DNODBGINFO0
-これを実行するとdecoder.oseというファイルができます。これが変換用OSECPUアプリです。

-次はこのdecoder.oseの使い方です。
--フロントエンドコードをメモリに読み込んで、出力先のバッファとテンポラリを確保して、Pxxレジスタでそれらを教えてあげるだけです。
--先頭2バイトのシグネチャはdecoderが感知しないので、自分で2バイトをコピーしてください。
 入力パラメータ:
 P02 = T_UINT8: &backend[2] （出力バッファ先頭）
 P03 = T_UINT8: &backend[backend-maxsize] （出力バッファの限界）
 P04 = T_UINT8: &frontend[2] （入力データ先頭）
 P05 = T_UINT8: &frontend[frontend-size] （入力データの終端：最終バイトの次のアドレス）
 P06 = T_UINT8: &temp0[0] （要素数が2M以上のテンポラリバッファ）
 P07 = T_UINT8: &temp0[temp-maxsize]
 P02 = T_UINT8:  &backend[2] （出力バッファ先頭）
 P03 = T_UINT8:  &backend[backend-maxsize] （出力バッファの限界）
 P04 = T_UINT8:  &frontend[2] （入力データ先頭）
 P05 = T_UINT8:  &frontend[frontend-size] （入力データの終端：最終バイトの次のアドレス）
 P06 = T_UINT8:  &temp0[0] （要素数が2M以上のテンポラリバッファ）
 P07 = T_UINT8:  &temp0[temp-maxsize]
 P0A = T_UINT32: &temp1[0] （要素数が16Kくらいあれば十分なバッファ）
 P0B = T_SINT32: &temp2[0] （要素数が64のバッファ：Pxxレジスタの個数）
 P0C = T_SINT32: &temp3[0] （要素数が4Kのバッファ：登録可能ラベル数）
 P0D = T_UINT8: &temp4[0] （要素数が256のバッファ）
 P0D = T_UINT8:  &temp4[0] （要素数が256のバッファ）
 
 アプリ終了時:
 R00 == 0 正常終了
 R00 != 0 変換失敗
 P02 == バックエンドコードの終端, つまり P02 - &backend[0] = バックエンドコードのサイズ
--バックエンドの実行エンジンをある程度完成させたうえで、decoder.oseの内容をダンプして配列にでも入れて、実行してください。

-参考情報：
--decoder.oseは以下の25命令しか使っていません（ver.0.72の段階で）。
 01: LB
 02: LIMM
 03: PLIMM
 04: CND
 08: LMEM
 09: SMEM
 0E: PADD
 10: OR
 11: XOR
 12: AND
 14: ADD
 15: SUB
 16: MUL
 18: SHL
 19: SAR
 1E: PCP
 20: CMPE
 21: CMPNE
 22: CMPL
 23: CMPGE
 24: CMPLE
 25: CMPG
 29: PCMPNE
 2B: PCMPGE
 34: (data)
** (2) なぜdecoderの利用を勧めるのか？
-楽だから！それ以外にはないです。

-フロントエンド→バックエンドにおいて、基本的な変換はそんなに難しくはないのですが、文字列を含むAPI呼び出しと型推論が入っているところはとても面倒です。きっとここをdecoderを使わずにやろうとしたら、途中で心が折れると思います・・・。
-せっかくここを.ose化しておいたのだから、これを利用しない手はありませんよ！

** (3) 将来の計画
-tek5デコーダも早く.ose化したいと前から思っています・・・。
--そのためには[[page0047]]の符号なし演算がほしい。そうしないとけっこう遅くなる。
--あとできれば構造体サポートもほしい。

* こめんと欄
-うわぁ！ありがとうございます！確かにデコーダーがOSECPUコードで実行されているところまでは突き止めたのですが、その先がわからず…。最近は忙しくて更新できていませんが、これならすぐ実装できそうです。ありがとうございます！ -- [[hikarupsp]] SIZE(10){2013-08-21 (水) 19:04:17}

#comment
トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS