[MD:868]CCL coding system on Meadow.

[Tanaka Akira <akr@xxxxxxxxxxx>]

In article <ur9y5yl51.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
  Miyashita Hisashi(宮下 尚:HIMI) <himi@xxxxxxxxxxxxxxxxxxxxxxxxx> writes:

> でも、まだまだ最適化できる。

ccl-b64-array を 4種類作って実行時の bit shift を削除するとか、loop
unrolling をするくらいを思いついたのですが、ほかにあるでしょうか?

> あ、ちなみに、=のpaddingがないと、途中で切れます。^^;;;

encoded-word 専用と割り切るんならこれはかまわないんですが, もし処理す
るんなら CCL_EOF_BLOCK でどうにかするんでしょうね。

でも, read で何バイト読んだか調べるのがなかなか厄介な気がします。
今の CCL では毎回 read する前に r1 .. r4 に -1 とかを入れておいて調べ
るしかないような気がするんですがなんかうまい方法はないもんでしょうか?

コンパイラの支援が得られるなら, CCL_EOF_BLOCK に入る原因となった read
命令のアドレスを参照できるようにしておけると, CCL_MAIN_BLOCK に余計な
処理を入れなくて済むので幸せなのですが。
(コンパイラの支援が得られない場合の)次善の策としては, read に複数のレ
ジスタを書いた時に何バイト読んだのかだけでも知ることができるとちょびっ
と幸せになれるのですが。

;; という CCL の拡張の提案なんですが、演算子でやるのは不自然なような気
;; もしますね。

あと、正しくない文字を読み飛ばさなくなってますね。これもまた
encoded-word 専用なら問題ないんですが、一般の Base64 を扱うとすると改
行を読み飛ばせないので問題です。これを解決するには... 1byte ずつ読むし
かないような気がしますねぇ。

>      (r0 = r1 ,ccl-b64-array)

うぅむ、こんな表引きができるなんて知りませんでした。
ccl.el の先頭のコメントの syntax には書いてないし。
あ、ccl-compile-set のコメントには書いてあるか。

In article <199808250042.JAA18994@xxxxxxxxxxxxxxxx>,
  Kenichi Handa <handa@xxxxxxxxx> writes:

> あの、貧弱なドキュメントをベースに良くプログラムが書けるものだと感心し
> ております。^.^;;;

そのドキュメントってのはどこにあるんでしょうか?
私は ccl.el のコメントしか知らないんですけど。

;; Emacs 20.3 を ccl で grep してみたけどそれらしいものは見当たらりま
;; せんでした, ってことはコメントのことを指しているのだろうか?

> Richard によると１〜２週間で bug fix version 20.4 を出すそうです。それ
> に、CCL の追加演算子を紛れ込ませることも可能です。適当な演算子を提案し
> てください。

演算子じゃないんですが、ccl-execute-string で文字列の先頭からではなく、
途中から読み始めるオプション(もしくは ccl-execute-substring などといっ
た builtin) が欲しいです。

;; 終りを指定できるオプションもあれば嬉しいです。encoded-word からいち
;; いち substring しなくて済むことになりますし。

もともと私は字句解析を行なう状態遷移機械を高速化するために CCL を調べ
始めました。つまり、文字列の上で CCL で書いた状態遷移機械を走らせて,
最後に通った受理状態とその位置をレジスタに記録しておいて後から読み出す
わけです。

ところが、今の ccl-execute-string だと文字列の途中から読み始めるという
ことができないので、すでに読んだ部分は読み飛ばすという処理を入れないと
いけません。このような実装で文字列全体をトークンに分割すると, 各トーク
ンを認識する毎にそれ以前のトークンを読み飛ばす処理が入るわけで、文字列
の長さの2乗くらいの処理時間がかかってしまってすごく悲しいんです。

;; ま、知合いの小林君に頼んで ccl-execute-substring を実装してもらって
;; 速度を測定したん結果、CCL 版の状態遷移機械の実装があまりに素朴なの
;; か, Emacs Lisp 版のほうがあまりに最適化されすぎているのか、現状では
;; まだ Emacs Lisp 版の方が微妙に速いんですけどね。
-- 
[田中 哲][たなか あきら][Tanaka Akira]