前のコミットでの修正忘れを修正

消し忘れてた。
構文解析に assignment をサブファンクション化してソースを整理した

とくにコメントは無し
write_heap(), read_heap()に明示的なインライン指定版を追加

サイズ縮小と高速化をどちらも両立させたいという願望があるのだが、
現状はサイズがあまりにも酷いことになってしまっている。そろそろこれを問題に感じ始めてきた。
osecpuはバイナリーサイズを極限まで小さくできることが特長なのに、
osecpu-basicでは、現状、その特長をまったく活かせて無い。

現状は samples/wire2.bas をコンパイルすると、約２万行近い .ask が出力されてしまう。
この .ask のサイズは 400 キロを越える巨大さで、
これを osecpu-aska によって .ose へコンパイルしても、なお 100 キロを越えてしまう。
osecpuアプリで　100 キロ越えというサイズは、あきらかに異常な巨大さなので、これはマズい。

osecpuの潜在能力を考えれば、もっとコンパクトな .ask にできるはず。
（テキストエディターが1キロ以下で可能なのだから）

どうすれば、よりコンパクトな .ask を吐けるかを考えると、
やはり最適化に手を出すしかないとないと思う。
だけど、最適化は難しい。コードが益々難しくなってしまう。（現状でも手に負えてない状態なのに）

osecpu-basic でも、実は自分なりに相当に「小さな .ask を出力すること」は意識しているのだが、
それでも全然、wire2.basが２万行なのには、正直、内心、自分では相当がっかりしてる。
しかも .ose にコンパイルしても、これは 100 キロバイトもある。
正直なところ、自分のコーディング能力の低さが恥ずかしい。

泣き言はこれくらいにして、
では、具体的に「何が巨大さの原因なんだろうか？」と考えてみる。
２万行のソースコードをスクロールして「模様」を眺めてると、大体似たような模様の繰り返しで、
この模様は固定小数点数の定形的な（しかし適度にユニークで共通化は難しいような）処理の
羅列状態となっているようだ。

この模様の正体はたぶん "固定小数点数 <-> 普通のSInt32" の相互変換の定形処理っぽい。
ということは、ここをサブルーチン化すれば、個々の処理は２～４行程度で収まるはず。
つまり用意するパターンとしては:
固定小数点数 -> 普通のSInt32 のパターン
普通のSInt32 -> 固定小数点数 のパターン
上記が数回反復的に組み合わさったパターン
これらをサブルーチンとして用意し、これを用いるようにすれば、ソースサイズ縮小につながるはず。
しかし、これをすると代償としてラベルの消費量が大幅に増えることは明確。
ラベルは、osecpuの”仕様上”では32bit個、すなわち±２０億個使えるが、
現実的な実装では、現状のosecpuでは（ドキュメントによると）ラベル数は4096制限があるので、
ラベルは現状では枯渇の恐れが現実的にある、かなり有限のリソースという認識なので、
ラベルを多く消費することには抵抗がある。

でも、サイズ縮小のためなら、これをやるしか無い。
もしもラベル枯渇が問題になったら、その時はビルドオプションを用意して、
サイズ優先 or ラベル温存を、選べるようにすれば大丈夫だろうし。

とにかく、今はラベル枯渇のことは気にせずに、
とにかく .ask のサイズをを小さくする方を優先してみようと思ってる。

関係無いが、32bitの浮動小数点数を、ソフトウェアエミュレートで実装して、
floatを基本型にしてしまうことも当初は考えていたのだけど、
実を言うとこの osecpu-basic は kcube 書くのが目的で作り始めたので、
基本型がソフトウェアエミュレートによるfloatでは、
「kcubeが重くて動かないかもしれない」という懸念から、固定小数点数にしたのだけど、
wire2.bas を見るかぎり、osecpuの処理速度は、（予想よりも遥に）十分すぎる程に高速なので
これなら基本型をソフトウェアエミュレートfloatにしても、案外、軽く動いてくれるのではないか？と
密かに思い始めてる。