khabaネタ
(6)
- (2010.06.22a)
- ○○という言語は、××という処理をこんなに短く書けます、みたいな話がある。しかし、それはkhabaでは問題にならない。だって適当なラッパーさえあれば、容易に他の文法体系になるのだから。ということは、デフォルト文法がどんなに書きにくくて使いづらい文法であっても良いということだ。
- しかし機能不足は許されない。狙ったコードがどうやっても生成できないようなものは許されない。
- 最適化とかもいらない。そういうことは上位がやればいいのだ。
- そもそも最初からきちんとしたものを作る必要が無いというか、その気がないんだから、最適化なんて考えるほうがどうかしている。
- サイズもどうでもいい。後から改良すればいいのだ。
- 大事なのはコード変換ができて動作する仕組みそのもの。
- (2010.06.22b)
- メモリを作るのは難しいが、定数の整数配列を作るのは難しくはない？
- ポインタがあって、そのポインタでリード＆ライト保証するのは難しい。しかしここをどうにかしないと先に進めない。
- (2010.06.24a)
- 作りたいもののイメージをまとめる。
- バイトコードなのでCPUやOSに依存しない。
- データには必ずフォーマット情報がつくので、意味不明なバイナリが存在しない。
- コンパイラベースなので動作が速い。
- 2000年問題とか、ファイルサイズのビット数の問題とかが基本的に生じない。エンディアンに悩むこともない。
- 一つのソース内にさまざまな言語を混ぜられる。それどころか、一つの関数の中にいろんな言語による記述を許す。
- コンパイルされるのはプログラムだけではない、データのコンバートも「コンパイル」の一種と見なす。そして変換されたものはキャッシュされる。
- それで何が得られるのか？
- 新しいプログラミング言語が作りやすくなるから、言語が進歩する。
- (2010.06.24b)
- 1ブロックのコードサイズが大きすぎた！どうする？
- 粒度をあげればいい。究極的にはインタプリタ動作のコンパイル、みたいな。規模は更に膨らむが、それでいいじゃないか。
- 構造体サイズやデータサイズについても同じ。
- そういうものに最初から配慮するのは非常に難しいから。当面は、何も考えないPCモデル向けでいいのでは？いろいろできるようになってから悩めばいい、悩んで何もできないでいるよりは。
- (2010.06.27)
- アラインが合わないデータについて。
- 16bitのデータを、1bitずれて入れてしまった。 0xxxxxxx 87654321 xfedcba9
- 32bitリードすると、xxxxxxxx xfedcba9 87654321 0xxxxxxx
- うまく行っているように見える。つまり、リトルエンディアンでは、LSBから詰める。
- 8bitのデータがある、bigでは、上位データから順にMSBから詰める。
- だから76543210
- littleでは下位データから順にLSBから詰める。だから76543210。
- bit1u/s関数、bit8u/s関数、bit16u/s関数・・・（bit8u/s関数＝DB相当）
- より上位のものは構造体。
- gh4はすべてbit4uで構成される。
- 推定が容易なものはフォーマット推定アルゴリズムを含めればよい。
- というか、デフォルトでみんな推定アルゴリズムを使用。・・・というわけではない。
- 65536Kbitのヘッダ。フォーマットヘッダ。
- 16bitのフォーマットシグネチャ（バージョン込み）。F00とか。
- gh4でデータ本体の位置。・・・などではなくて、G01のようなパケット構造に。
- フォーマットタグがない場合、全部bit1uとみなされる。
- フォーマット：
- bit1/2/4/8/16/32/64/128/256/...,u/sで28通りくらいリザーブ
- リピートプリフィクス（パッケージプリフィクスを含む）
- 32以降は拡張。拡張番号も指定できる。
- デフォルトでは、32が8bitのIBM-ASCII。
- 33はUNICODEの改造エンコード。
- 0でエンド、1で継続の方式。これだと文字化けが途中で止まる。・・・でも、化けはより上位のレベルでサポートされるべき（eccなど）なので、ここでは扱わない。
- じゃあgh8かな。
- 0xxxxxxx : 8=1+7
- 10xxxxxx xxxxxxxx : 16=2+14 (U+3FFF, ひらがなまではいける)
|
![[K Wiki]](k.jpg "[K Wiki]")
