khabaネタ
(1)
- 構造体のバイナリ化・互換性の担保はできるとしよう。それはそれで結構だけど、演算はどうだろう。「○○の値+1」にしたいとか、そういうことだ。
- これを認めることにすると、結局、関数を書きたくなる。となると、構造体の中にkhabaのバイトコードを書く感じになるだろうか。その関数はいつ評価するのか。
- 関数そのものを表すのか、そのときの状態で関数を計算してその結果を代入するのか、それとも値が必要になった段階でそのつど計算させたいのか。依存関係を追跡すればある程度高速にはできる。
- うーむー。
(2)
- 上記はつまり、構造体の中にメンバ関数が含められるということとなんら違いはない。
- メンバ関数は、依存関係を書くべきだ。つまり何を入力とし、何を出力とするのか。I/Oへの入出力も立派な依存関係だ。cpuタイムを消費する事だってそうだ。この厳密な意味においての出力結果が無いものについては、存在価値がない。
- khabaのバイトコードを書くのが面倒なら、とりあえずia-32のままでもいい。ds:esiとss:esp。
(3)
- そもそもkhabaの目的はなんだ？
- 機種の差を越える。
- シェルとプログラミング言語とで文法を同じにする。
- 速度を担保する。→インタープリタでもあり、コンパイラでもある。両方の性質を持つという意味ではなく、両方実装するという意味。
- バイトコードをia-32そのものにしたら、どこまで簡略化できる？この場合命令は全て16進入力、シェルも16進入力。
(4)
- 適当に数時間でできるものを妄想してみる。
- すぐに暴走するのは目に見えているので、例外を充実。当面はエミュレータ上で実行。
- 当然リング3。
- EAX以外は保存するというのがデフォルト。C言語のルールとは違うが、C言語なんか知るか。C言語のコードを使いたければ、PUSH(ECX);PUSH(EDX);CALL(func);POP(EDX);POP(ECX);return;でラップしたらいい。
- いろいろ考えてみたけど、基本文法がx86バイナリだと、しんどすぎる。やっぱりC++ふうがいい。
(5)
- (2009.09.01)
- 構造体のメンバに番号ラベルをつけたものが配列
- a[123]とa.123は同じもの。int& a.label = a[123]; とすれば、a.labelでもa[123]にアクセスできる。これはつまりメンバの追加？いや違う。&なので、a[123]の値が変われば、a.labelの値も変わる。だからlabelは123のエイリアス。
- khabaにおける型とは、オブジェクトを生成するときに使うもの。関数の引数で使うときは、インターフェースがあればそれでいいはずだ。継承しなければいけないということではない。
- 文を文字列で生成してevalできる。
- (2009.09.15)
- バイトコード体系を構築し、evalの値をバイトコードにコンパイルできるコンパイラを作れば、インタプリタもコンパイラも全部できる？
- 捨て構造体と、捨て関数が書ければいい。
- プリプロセッサはどうする？
- int a = 10;
- &int a = 10; だと実質static。いやまて、ほほうポインタだとstaticっぽくなるのか。定数の&も取れる。ということは定数も含めて全てオブジェクトはヒープかスタックにある。ということは、&の初期値やポインタを取ったものはいつかはdeleteしなければいけない。確かにそれはそうだ。
- int[123] a = { 1,2,3 }; int[123] b = { 100: 1, 2, 120: 3 };
- オブジェクトの型情報とかは別空間にある。
- 引数内に関数（への参照）を書きたいとき、{}の前にfunctionを書く。
- (2009.09.16)
- khbのバイトコードコンパイラを書く。そこから全てを構築しよう。きっとできるはずだ。
- 高級言語編：
- プリプロセッサはいらない。inline関数とconst int a = 100;とかでほぼ代用できる。
- eval関数を記述することがインタプリタ、コンパイラを記述することと同義。
- 例：入力＝プログラム＆環境、出力＝変換されたプログラム＆環境
- 最終的には機械語で出力する。その一個前がSKA形式の出力。これに大量のinline関数やconst定数が付いて、ASKAになる。そしてkhabaバイトコードから各CPU向けのASKAに変換するeval。さらにC++っぽい言語からkhabaバイトコードに変換するeval。これで言語処理系は出来上がりのはず。
![[K Wiki]](k.jpg "[K Wiki]")
