書きなぐりメモ

  • (by K, 2009.09.25)

(1)

  • とりあえず、レジスタとAPI呼び出ししかできないkhabaを作る。次に簡単な演算や条件分岐もできるようにする。そしてタスクセーブポイントも。 -- K 2009-09-25 (金) 19:09:16
  • それでやっとメモリが出てくる。メモリは難しい。がんばる。 -- K 2009-09-25 (金) 19:13:29
  • データレジスタは必ず符号付き。メモリは符号なしも可能。 -- K 2009-09-25 (金) 20:52:44
  • 無駄な命令の自動除去があれば、プログラミングは楽になる。レジスタに関してならできるはず。32bitごとでいい。メモリだとポインタアクセスされる可能性や、同じではない表記でアクセスされる可能性があって簡単ではない。逆に考えると、それらの問題を設定できればいい?(他の方法ではアクセスしないと。) -- K 2009-09-26 (土) 06:21:32
  • タスクセーブポイントまではレジスタの使い方がおかしくてもとがめられない。ESIを破壊してもよい。 -- K 2009-09-26 (土) 06:24:20
  • タスクセーブポイントの挿入が不適切でも、推奨されないだけで、使えないわけじゃない。ということにすれば、普通のC言語の利用もとりあえず可能になる。これはいける。 -- K 2009-09-26 (土) 06:57:15
  • khabaのコードは適当なツールを使えば、x86のXCOFFや16bit-objなどにできなくてはいけない。APIもライブラリも含めて、しかるべき形式にコンバートされる。16bitなら、DOS用とBIOS用とかテキストVRAM直接制御型の区別もあるべき。これらが同一のkhabaバイナリから生成できる。 -- K 2009-09-27 (日) 07:50:38
  • khaba的にimmモードで書かれたMOVだとしても、実機用バイナリではmemになったりする。同様にimmなAPIだとしても、実機用でmemになってかまわない。コンバータはAPIのフォーマットを理解できる。だからimmで書かれても切れ目が分かるし、自動補完部分を事前に補うこともできる。サイズよりもその後の変換のしやすさをとれば、マルチファンクション型もシングルファンクション型に変換される。必要なら最終段階で再マージすればいい。 -- K 2009-09-27 (日) 08:11:50
  • khabaの式は順ポーランド記法で。これならオペコードが先行するので、オペランドの型推定が可能。サイズ削減に貢献できる。 -- K 2009-09-28 (月) 01:09:42
  • int系の場合:Dn、非負の定数(gh4)、負の定数(gh4)、メモリ、intを返す何らかの演算。 -- K 2009-09-28 (月) 01:23:58
  • Dnの必要ビット数、そのほかの型についても必要ビット数は、省略することが可能である。その場合、そのデータ型への演算に使われる定数から必要ビット数が推測される。そのビット数以上でなければ、バイトコードでの記述を省略することができるわけだ。 -- K 2009-10-11 (日) 21:12:27
  • 負の数はgh4が12bit形式以上のときに符号拡張するということで十分に思えてきた。 -- K 2009-10-12 (月) 11:56:13

コメントお名前NameLink

リロード   新規 編集 差分 添付   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS
Last-modified: 2009-10-12 (月) 11:56:13 (3383d)