SFLという言語には、状態遷移マシンからサブルーチンのようにサブ状態をコールする機能がある。これを使うと、たとえば、命令処理において共通のアドレスモード処理などをサブ状態として作成し、複数の箇所から呼び出しが可能となる。
（特に、VAXなどのマルチオペランドにアドレスモードが適用できるようなマシンには最適である）
これにセグメントと名前がつけられていて、私のツールでも当然ながらこの機能を前提に方式設計がなされている。ところが、セグメントを使っている人を見たことがないし、自分でもまず使わなかったので、デバッグをせずほったらかしにしていた。
（要求もなかったのもあり、自分で書いたチュートリアルにもセグメントを使う例題は載せていない）
先日の京都の出張において、会津のO氏から、セグメントを使おうとしたらうまく変換できなかったという情報を聞き、クリスマス連休に入る前に、自分で確認プログラムを作り、２時間程度かけて、デバッグした。
結果として、都合3箇所のバグがあり、（2箇所は単純な評価文の実行忘れ、1箇所は評価タイミングの勘違い）簡単に修正は行えたが、やっぱり、サポートしているつもりとサポートするというのは違う（笑）
自分のプログラムは、コメントは一切入っておらず、しかも、ポインタチェインを延々と追いかけるようになっているので、セグメントのように普段使っていない機能についてデバグしようとすると、思い出すまで一瞬時間がかかる。
たとえば、
r->opr.op[2]=p->opr.op[opr.op[0]->con.val]->opr.op[1];
といったような文は開発当初から3年半も経つと、10秒は考えないと何をしているかは分かりにくいのである。そこで、遅ればせながら、今回からはポインタチェインの修正箇所に関しては、関数として切り出して、関数名を見れば何のことかは少しは分かるようにした。
10秒理解にかかるというのは、やはりデバグ効率を相当下げるので、最初からこうしておけばよかったのだが、この後、どれだけの修正が入るのかというと、現行のSFL言語仕様にあわせる開発をする限りは、もうほとんど機能的にはFIXしているのではないかなぁと、ちょっと思ってもいる。
VHDLへの変換はまだプアだから、この部分を修正したりすることは、商用ユーザのリクエストがあればするかもしれないが・・
（ユーザの少ないVHDL版の機能アップは別料金もらわないと割が合わないかも？）
今度はセグメントもちゃんと動作するので、チュートリアル資料もそれにあわせて、セグメント動作を追加しておかなくては・・・
セグメントを使いたい人は20051222版以降をご利用ください。