.ask （マクロアセンブラソース）の窓最適化処理の実験的プログラムを追加

着眼点は単純で
「アセンブラソースを短くすれば、吐かれるバイナリーも（概ね）短くなるはずだ」
という単純な考え。

そこで、アセンブラソースコード中での、コードの重複箇所を検索し、
重複箇所を関数化してしまうことで、全体のソースは少しだけ短くなる。と思いついた。

具体的な処理内容は単純で、以下のような考え方:

（各アルファベットが１行分のソースコードだと思ってください）
A B c d e A B f A B e d c A B
のようなコードがあったとして、
このコードには A B という命令パターンが 4箇所も重複して登場している。

そこで、この A B を切り分けて、関数にしてしまう。
F(A B)

そして、元のコード中での A B の部分を、この関数への呼び出しに置き換える。
（例えば、関数呼び出しを F で表すとします）
F c d e F f F e d c F

２つのソースをマージすると
F c d e F f F e d c F と F(A B)

これで、もしも A B が十分に長くて、かつ、登場頻度も多ければ、
この最適化によってソースコードは短くなる。

これだけのことです。

osecpu はラベル以外の場所へジャンプすることはできません。（耳タコですが）
また、ドキュメントによると、割り込み処理等も、ラベル位置を軸として行っていくような
方針だったと思います。

すわなち、osecpu のアセンブラコードでは、「ラベルの存在しない区間」に限って考えれば、
その区間を勝手に適当に分割したり、移動したりしても、処理の流れには絶対に影響無いことが
「ラベル」という制限によって保証されている。

ラベルという制限のおかげで、
ラベル以外の場所へジャンプで割り込んで利用される可能性を０％と考えることができるので、
そのおかげで、アセンブラコードを好き勝手切り貼り、並べ替えでき、それどころか
区間内で整合性さえ保てていれば、命令順序を入れ替えても動きうる。
それもこれも、「ラベル以外の場所へは絶対にジャンプされない」という保証があるおかげ。

このように、ラベルという制限のおかげで、アセンブラの命令順序の並べ替えを、
非常に単純なアルゴリズムだけで行うことができる。
もしもラベルによる制限が無かったら（自由なジャンプが許されていたら）、
今回のような最適化は、もっと遥に難しくなる。ポインタのあらゆる可能性を予測しなければならないから。

ところで、今回の実験では具体的には 10 行のコードが 8 箇所で重複していた場合に、
それを関数と、関数呼び出しに置き換えているだけ。
これは、.ask 段階では小さくなったが、.ose 段階では逆に肥大化してしまった。
残念なおしらせ。
マクロアセンブラだから、行数とニモニック数は必ずしも比例しないということなのかもしれないし、
また、関数呼び出しとリターンにスタックを用いているが、この辺りのコストが高いのかもしれない。

実験としては（肥大化してしまったので）失敗だが、
しかしながら、アセンブラコードを（かなり適当な感じに、機械的に）切り貼りしても、
それでも動くコードの状態を保てるということが分かったのは収穫だった。

この手応えだと、たぶん、もっと汎用的な「osecpu-askaソースの”機械的な”最適化ツール」も
可能なのではなかろうか？と思った。
たぶんプログラム的には囲碁や将棋のAIプログラム作るのと似たような処理になるはず。
（最もスコアが高くなる経路を探しだす問題と同様の作りになるはず）