-------------------------------------------------------------------------------
ＳＴＫ開発履歴
-------------------------------------------------------------------------------
v0.x	1994/10-1995/1

	そりゃもう、大変でしたわ。いろいろ変わるし。
	現在の原型が出来るまでに、中１月ほど中断もあったけど、
	３ヶ月以上かかってる。私のプログラム開発にしては、異例の長さ。
	（ただし、バージョンアップを除く。）

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
v1.0	1995/1

	初期バージョン
	テキスト解釈実行型

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
v2.0	1995/2

	中間コード実行型（高速化：v1.0比３倍以上）
	各種デバッグ
	エラーチェック強化
	一部トークン変更・追加

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
v2.1	1995/2/28

	内部変数処理変更(VARSYS2)
	　実行時の使用メモリー縮小
	　（プログラムサイズも少し縮小）
	　高速化（したはず・・・変数回りのみ）

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
v2.2	1995/3/3

	条件ｼﾞｬﾝﾌﾟ先を持つコマンドのｼﾞｬﾝﾌﾟ先確定処理
	２回目以降のジャンプが高速化される
	コマンド[ftell]の追加（と言うより無効になっていたのを有効にした。）

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
v2.3	1995/3/13〜9/8（途中中断有り）

	＊配列の大幅変更
	
	(1)文字列・文字列配列の廃止と新型配列の定義
	従来の数値配列を拡張し、BYTE/WORD/LONGの３種類にして、指定要素の
	アドレスを返すトークンを作る。
	固定文字列長はmax255ﾊﾞｲﾄ(unchar)とする。（長さ記録の最適化）
	これ以上の場合は、配列に結合して格納する。
	これにともない、１トークン長も255バイトに制限する。
	文字列関係トークンの処理が少し複雑になるが（長さ判定）、
	配列の有益性を高めるためにはしかたない。

	(2)配列名のスタックに積む値を絶対アドレスから相対アドレスに変更
	絶対アドレス化は利用時（＝関数内）に行う。
	これは、スタックに積まれた時から、実際に関数に使われるまでの間に
	配列領域先頭アドレスが変更にある場合があるから。

	(3)配列系関数名の統一

	この配列の変更にともない、デバッグトークンや、配列、文字列に関わる
	関数はすべて修正した。引数のスタックに積む順が変わったトークンもある。

	＊デバッグ
	  vlock/vunlockが効かなかったのを修正した。
	　引数チェックを強化など

	＊多くの関数をNSTACKを引数とするように変更
	　NSTACKの構造が変更されても簡単に対応出来るようにするため。
	  Push/PopNStack等

	＊エラーメッセージの統一
	　「〜がおかしい」を「〜異常」に統一

	＊STKnumret()相当の処理をSTKinterpret()に内蔵
	　トークン関数のリターン値NOKで判断。
	　これにともない、リターン値の数値設定を変更。

	＊スタック操作が一番楽になるようにトークンの引数順を一部変更
	　これにより、Ｃの関数と同じ名前のトークンでも引数順が異なる
	　ものが出てきた。（ファイル系に多い）

	＊余り使わないトークンの削除
	　**,SCREEN,[,],[]等

	＊ＧＣＣレベルの最適化工夫による高速化と省メモリー
	　各種処理の最適化。
	　?STACK/stksys構造体などグローバル変数はレジスター割り付けされないので、
	  使う内容をローカル変数にコピーして最適化の対象にする。
	  また、その他の部分もソースの記述を徹底的に最適化する。
	　（何種類かの記述を行い、コンパイル結果が一番小さくなるものを選ぶ。）
	　これによりプログラムサイズはVer.1より小さくなった。

	＊デバッグ用のRemakeTokenの改良
	　数値と固定文字列を元テキスト参照に変更
	　これに伴い元テキスト参照のためのコメントコード(SCCOMT2)を追加し、
	　これに関する処理を追加
	　（固定文字列の逆変換ルーチンが抜けるため、処理を追加してもサイズが縮小）

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
v2.4	1995/9/9〜9/18

	＊中間コードの偶数バイト化
	　識別子の後ろに属性長を常に持たすようにして統一。
	　これにより、メモリーアクセスをすべてctol/ltoc経由から直接に変更する。
	　本体の省メモリー化と実行スピードの若干のアップ。
	　（実行時メモリーは中間コードが大きくなる分必要になるはず。）

	＊SCNOPではなくSCSKIP lenでラベルの絶対アドレス後の領域を埋める
	　若干のスピードアップしたはず（特に長い名前のラベルを使った時）。

	＊SCCOMTを変更
	　中間コード領域にラベルを埋め込まず、テキスト参照にする
	　（数値・固定文字列のテキスト参照と似ている。）
	　中間コードの縮小

	＊デバッグ
	  (1)RmakeToken系（数字／一時文字列が２重表示されていた）
	  (2)fncv:ﾛｰｶﾙｴﾘｱの最大段数チェックが間違っていた（これによりアドレスエラーが出た）
	     bs.stkがﾛｰｶﾙｴﾘｱ不足で止まることがあるので、初期最大段数を20->40にした
	     (stk.h:LOCAL)
          (3)前方参照のラベル名長が1,2の時のコード破壊を修正
	     （中間コードのバイト数が増えているのに対応できてなかった）
	  (4)ローカル変数定義モードがグローバルと異なっていたのを修正
	     グローバルはBIT0,ローカルは0だった(vardumpがおかしくなっていた)

	＊stk.c内に有ったAddComToken()を外部利用可能な関数として独立する

	＊コマンドリンクテーブル最初の最適化と外部読みだしの関数化
	  ctbl0を廃止、最初のテーブルを記録し、それを返す関数を作り外部で利用可能にする

	＊表示関数を出来るだけprintf2に統一
	  ptintc/printsを排除
	　これによりプログラムサイズを縮小
	  本体だけでなく、VarDumpも修正。(VarDumpS)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
v2.5	1995/9/21〜9/29

	＊配列のアドレス(NADRS)を関数に与える前に絶対アドレス化する
	　これにより、それを使うそれぞれの関数内部で変換する必要がなくなり、
	　変換が少なくなるので高速化する（はず）。
	　また、従来どおりオフセットを与える識別子(TOADRS/TOSTR1)も用意した。
	  数値スタック内では従来どおりオフセットのままである。

	＊SCCOMT2廃止
	　固定文字列、数値の後ろにあったコメント(SCCOMT2)を廃止し、
	　前にSCCOMTを置くようにする。これにより中間コードの種類を減らして
	　処理を軽減して省メモリー＆高速化になる。

	＊エラー処理の大幅変更
	  (1)エラー関数を汎用化して外に出す(aerr.h)＋テーブル型にする
	  (2)エラー関数の統合
	　(3)エラーメッセージのミスを修正
	  (4)不要なエラーチェックの削除(stkfnce.c)
	　これにより大幅な省メモリーになる。

	＊中間ストア処理の改良とデバッグ
	  (1)EOS分の判定なくし、EOSストア時にも領域判定させる
	  (2)StoreCode2(stkcode.c)でlenが奇数の時の領域サイズ判定ミスを修正

	＊言語モジュールインターフェースの改良
	　(1)STKTextReadを独立化する(TextRead:afile.h)
	  (2)STK() -> STKmain()にする
	  (3)新しくSTK()を作り、前後処理・中間コードコンパイルを含めた処理を行う
	  (4)STKSYSを改良して、あらかじめそれに定数をセットしてからＳＴＫを起動するようにする
		-> 関数の引数の内初期化系引数を全廃
	  これにより、言語モジュールとしてのＳＴＫを外部から利用しやすくなった。

	＊最適化工夫による高速化と省メモリー
	  (1)*stksysのローカル変数割り付け
	  (2)stkx.cのオプション引数取り込みルーチンの集中化
	  (3)until/wendとnextのルーチンをまとめる（stkfnck.c）

	＊デバッグ
	  (1)最大ラベル数の指定が間違っていた(STKSemiCompile:VarOpen)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
v2.6	1995/10/03〜10/22

	＊変数処理方法の大幅変更
	　従来の毎回サーチから、中間コード時に全変数のテーブルを作りそのオフセットを格納し、
	  実行時は参照にする。これにより変数アクセスを高速化できる。
	　・・・はずであるが、speed?.stkのように変数アクセスが少ない場合にはまったく
	  変化がない。残念。bs.stkクラスだとかなり高速化されていることがわかる。
	
	　これに伴い、変数システムの内、実行時に使われる部分はすべてＳＴＫ本体内で処理
	  されることになった。（変数処理関数は中間コード時のみ利用。）
	
	　変化点
	　　実行時のメモリー確保・解放が動作が減る
		= ローカル変数処理が変わった
	　　中間コードが小さくなった
		= 変数名を記録しないから
	　　中間コード化処理が速くなった
		= SCSKIPが不要になった
	　　実行時スピードが速くなった
		= 変数名から毎回hashを計算する手間がなくなった
		= 変数処理が内包化されたので関数呼び出しの無駄がなくなった
		= SCSKIPがなくなった
	    大幅プログラムサイズ縮小

	＊CTRL-C(BREAK)が押されたときの処理の完全化
	　CTRL-Cを押しても予定どおりの中断処理が走らないのを修正
		- 基本的にはＯＳに任せる（CTRL-Cのベクターを乗っ取って処理）
	　BREAKチェックも軽くなり、大幅にスピードアップ
	　（speed2.stk 26sec -> 20sec ; いままでいかにChkCTRLC()が重かったのか・・・）
	  これと同時にCTRL-C処理周りを修正
		- エラーメッセージ変更
		- CTRL-Cのメッセージ（処理）を最優先化
		- BREAK/エラー関係ワークを内部構造体に入れる - stkfncb.cも修正
		- stkfnc3のキー入力内でのCTRL-Cチェックも不要になる＝COK2は廃止
	　BREAKチェックをアセンブラールーチンで記述するので移植性は低下

	＊コマンド実行直後にジャンプするもの(ret=LOK)はLStackを使わずに直接アドレス指定
	  いちいちスタックを通さない分高速化する
	　（speed2.stk 20sec -> 19sec）
	  ループ(LOK2)はいままで通り
	  ROKは存在しないので廃止

	＊配列をローカル変数に定義できなくする
	　ローカル変数に定義された配列は、そのローカルエリアが解放されると
	　アクセスできないゴミとなるので、これを防ぐため。
	  これにともない新エラー(ARYLOCAL)を作る。

	＊変数・ラベル名使用可能文字の変更
	　<=$2f,$3a-$3fの記号を使用不可とする

	＊文字列操作コマンド：長さは全てEOSサイズに統一
	　　配列領域サイズによるコマンドは一部を除いて削除
	　　デバッグ＆拡張（処理変更）
	
	＊デバッグ・変更
	　(1)STKEndingの終了処理がずれているのを修正
	  (2)CloseSTKが不要になったが、互換性のため#defineで残す
	  (3)OpenSTKをstkmain.c -> stk.cに移動
	  (4)NSTACKを引数に取る関数は全てアドレス渡しに変更（PushNStacl/strarray.c）
		-> 省メモリー/高速化？
	  (5)stkfncv.c:Slocal;VarLocalを内蔵化
		.typeフラグの初期化が重複していたから
	  (6)コマンドに与える引数の値チェック強化
	  (7)細かい改良
		グローバル変数アクセスのローカル変数による間接アクセス他

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
v2.7	1995/10/23〜11/30

	680*0Freak BBS正式公開第１版
	ドキュメント作成にともなう全機能チェックによる細部調整と大デバッグ。

	＊固定文字列をスタックに積むときにその長さを.pointに積む。
	　固定文字列はコード変換により\0も含めることが出来るが、
	　従来のstrlen()方式ではその途中の\0以降が無視されてしまう。

	＊ループ系コマンドで、２回目以降のループを高速化する
	　２回目以降はlstackを読まずにジャンプする。
	  next/wend/untilが２回目以降で高速化される。
	　これにともないLOK2を廃止。

	＊固定文字列対象処理の一部をEOSからlenに変更
		STRINGS他
	　また、len<=0の時は領域サイズを使えるようにする。
		MEMCMP/MEMCPY/FREAD/FWRITE/FGETSなど

	＊エラー/CTRL-C処理系コマンド強化＆変更(stkfncb)
		label ERESUME	エラー処理から戻る
		label BRESUME	BREAK処理から戻る
		label指定によって任意のコマンドに戻ることが出来る様にする。
		
		ERROR		エラーを発生させる
	　また、いったん設定した処理を無効にすることも可能にする。

	＊特殊ラベルコマンドを設定(stkfnci)
		LNULL	NULLラベル	飛ばないラベル
		LNEXT	NEXTラベル	このコマンドの次のトークンのアドレスを示すラベル
	　エラー処理指定等に利用

	＊トレースモードの改良
		(1)トークン表示を(0,0)から固定で強調＋黄色表示にするモードを付ける
		(2)callラベルのみ表示するモードを設定
	　これにともなって、トレースモードを扱う部分を全て変更。

	＊スタックチェックコマンドの追加(stkfncd)
		[? 〜 ]?

	＊終了時にキーボードバッファーをクリアする
	　そうしないと、ＳＴＫ内で入力されたキーがＯＳへ渡されることがあるため
	
	＊CTRL-C/エラートラップ中にEND(END.)した時には終了時(ComEnd)のエラーチェックを
	  しないようにする。
	　従来はCTRL-C/エラー中断時はチェックしない用にしていたが、これをトラップ中
	　もチェックしないようにする。トラップ終了は?RESUMEで認識される。
	
	＊ローカルエリアでグローバル変数を参照するコマンドの追加(stkfncv)
		%%	（Ｃ＋＋のスコープ解決からアイディアを頂く）
	
	＊FREWIND追加(stkfnc7)
	
	＊条件構文の追加(stkfnci)
	　IF./EL. : 直後の１トークンを実行
	
	＊BREAK/CONTINUEの改訂(stkfnck)
	  (1)条件付コマンドの廃止（IF*/EL*）
	     新コマンドIF./EL. + BREAK/CONTINUEで代用する。
	  (2)スタックdrop付きを作る
	     BREAK,/CONTINUE,
	     BREAK/CONTINUE前後にまたがるスタックを消すため。
	　  （今まで完全に見落としてた。）
	　これに対する記述をDB手法.DOCに追加。
	　今までの全てのサンプルプログラム/ドキュメントを修正。
	
	＊stkfncsの改良・変更
	  (1)スタック設定系コマンド名変更（動作は同じ）
		PUSH? -> ?TOP
		POP?  -> ?TOP=
	  (2)エラーを変更してstkertbl.cに移行
		?SETERR -> ?TOPERR
	  (3)( 〜 )/).をネスティング可能とする
		これに伴いエラーを変更
	
	＊stkfnc2の改良
	  (1)SRANDをRNDと一体化する（引数で動作を変える）
	  (2)CLOCKをtime()からclock()に変更する
		引数も変わった（mode=0で1/100秒単位,<>0で秒単位）

	＊変更
	  (1)外部関数の改良と小型関数への差し替え（大幅な省メモリー）
		改良：xspawnvp,curmode等
		差し替え：helpcom->helpcom0,fn_ext->fn_ext0
	  (2)ラベル確定中のエラー発生場所をわかりやすくする
		STKSetLabelAdrs
	  (3)一部コマンドの引数順変更
	　	実際のプログラム中での使用で一番良い順に変更する。
	  (4)KMEMCHAR -> MEMCHARに変更（バイト単位サーチにする）
	  (5)格納ワークエリアとなる配列のサイズチェック強化
		FILES
	  (6)使用頻度の低そうなコマンドの廃止
		SWAP(stkfnce)
		EI?/EJ?(stkfncr)
	  (7)一部コマンド名称変更(stkfncv)
		VARS.	->	VARS=
		SVARS.	->	SVARS=
	  (8)細かい改良

	＊デバッグ
	  (1)/* */コメント処理がおかしかった
	  (2)GOTO/RETURNの処理が間違っていた
		よく動いていたもんだ（ジャンプしていなかったはず・・・）
	  (3)STRCMP/MEMCMP系:比較結果のリターン値が間違っていた
		Ｃと同じにする
	  (4)配列
		@+/@-が増分を無視していた（常に+1/-1していた）
		->/->.が逆転していた
		符号付きBYTE読み出しが符号なしになっていた
		（GCCでchar=uncharのオプションを付けていたから。）
	  (5)PRINTS
		printf2()で表示させると、文字列中に"%〜"があると異常表示するので
		fputs(,stdout)に変更する。
	  (6)if/elif〜else〜endifのサーチ
		if&elseがネスティングした時にendifのサーチが異常になっていた。
		よく今まで気づかなかったもんだ・・・。
	  (7)INKEYコマンド
		getch()と同じになっていた。
		(CのINKEY()がgetch()と同じ動作をすることを忘れていた。）
	  (8)一番最後にリンクしたコマンドテーブルの初期化関数が呼び出されなかった
		ComInit(stkcom)のバグ。
		最後にリンクしていたコマンド(stkfncd)が初期化関数を持っていなかったので
		今まで気づかなかった。
	  (9)SWITCH〜SEND内から上のループのCONTINUEするときの処理
		SWITCHをBREAKしなければならないのを忘れていたのでlstackが異常になっていた
	  (10)特定の条件で定義したはずの変数が未定義になってしまった
		ハッシュの重複が３以上になった時に重複フラグが消えていた
		(pit.stkでWX/GMAX/fnameで発生）
		実は変数処理系VarDefineのバグ。
		これにともない、ハッシュがもっとばらつくような式に変更。(hash/hashi)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
v2.8	1995/12/12〜96/01/14

	＊ローカル変数で、上の段のローカル変数も参照可能とする。
	　変数サーチを現在の段から０＝グローバルまで遡って行くようにする。
	
	  でもこれによって変数サーチが遅くなった。下手すりゃ数倍遅くなる可能性もある。
	　使い勝手を上げるのが良いか、使い勝手が悪くても高速なのが良いか。
	　これは今後の課題になろう。

	＊グローバル変数をLvar[0]にコピーして使うことで実行時の変数アクセス法を統一する。
	　従来はグローバル(VAR1)とローカル(VAR0)で異なっていた。
	  ->処理の簡略化（高速化は？）。ただし実行時必要メモリーは増えた。

	＊スタック上で変数のグローバルとローカルの区別を完全になくした
	　（NLVADR/NLVADRNの廃止。）
	　グローバル・ローカル変数の区別はnstk.locで行うため、スタック上での
	　区別が不要になった。

	＊}.の追加(stkfncv.c)
	　対応するローカルエリアエンド}に飛ぶコマンド
	  ->ローカルエリアから脱出する（サブルーチンでよくある）のにGOTOを
	　　使わなくていいようにする

	＊使っていないエラーの削除
	　NOLOCAL	ローカル変数でない

	＊トレース機能無し版の作成
	　NOTRACE識別子を設定してコンパイルし直すことで作成できる。
	　省サイズと高速化出来る。デバッグ中と実際運用で分けてもいいだろう。
	　コンパイルはstkt.mをmakeにかければよいが、いくつかの.oが変更対象になるため、
	　トレース機能あり版(stk.m)と同じディレクトリ中には作成できない。
	　同じファイル構成で別のディレクトリを作り、*.oを全て消して、コンパイルし直すこと。

	＊Human68K V3.xのDOS call移動に対応
	　NEW KITのライブラリを持っていないので今までは全てHuman68K v2.xレベル
	　のDOS callを使っていたが、独自にCLIB.Aを変更することでV3.xに正式に対応。
	　（まあ、STKではスーパーバイザーモードは使わないから関係ないと言えばないのだが。）

	＊ドキュメントの不備を修正
	　（足りない点の追加とまちがいの修正。）

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
V2.9	96/07/07〜

	＊内部のトレースビット対応を変更
	　トレースモードの追加のため
	　（最初トレースモードを追加しようとしたが、問題が多いので中止した。）

	＊コマンドEXECで引数に配列を与えた時にエラーになるバグを修正
		"/?" arg STRINGS ,
		( arg ). "AS" EXEC , 
	  これがエラーになっていた。次のように書けば通っていた。
		( "/?" ). "AS" EXEC ,
		( 0 ). arg @ "AS" EXEC ,
	　EXEC自前の引数取り込みルーチンがおかしかった。
	  STKChgVarNum()を改良して可変長引数取り込みルーチンをシステム化。

	＊上記可変長引数取り込みルーチンを使い、配列の次元取り込みを変更。

	＊doslibm対応（DOSLIBを使うものを全て直接展開にする）

V2.91	98/10/11
	コンパイルが正常に通らなくなっていたのを修正(stkerr.h)
	<<,>>,<<<,>>>の結果がおかしかったのを修正。
		ＳＴＫ本体の問題ではなくライブラリの問題である。

-------------------------------------------------------------------------------
ＳＴＫの問題について
-------------------------------------------------------------------------------

Ｖ２のＳＴＫでは中間コードを採用した。このおかげでＶ１に比べ、実に３倍以上の
スピードを出すことが出来る。これによって、Ｖ１で問題になっていた実行速度の
遅さはかなり解消された。これで実用範囲も広がるだろう。
しかし、これですべての問題が解決された訳ではない。
現在のＳＴＫの持つ問題を挙げておく。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
中間コード化の問題
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

ＳＴＫ　Ｖ２では、すべてのトークンを中間コードで実行している。
このため、中間言語に置き換える為の時間が起動時にかかる。

ＳＴＫではトークンが自由に変更可能であるので中間コードは可変となる。
このため、中間コード化したテキストを記録するという方法はとれない。
（さらに、中間コード内に絶対アドレスを書き込んでいるという点からも、
実行直前に中間コードを作成するしかない。）

これはＸ−ＢＡＳＩＣでも同じである。ただ、Ｘ−ＢＡＳＩＣではプログラムロードと
実行が別々のため、実行直前には余り時間がかかったように思えないだけである。
（run"〜"は別。）

Ｖ１でも実行前にラベル定義があった。今回の中間コード化はこれも含めての処理で
あるが、処理の見直しによる高速化によって、Ｖ１に比べ特に実行前時間が長くなった
ということはない（と思う）。

中間コードはコード化・実行時のスピードを重視しているため、サイズ的に無駄も多い
（＝中間コード化してもサイズが小さくならない）。
特に、数値やジャンプアドレスに関する記録には無駄が多いと思っている。
（テキストサイズを６４Ｋ以内と限定すれば、ジャンプアドレスに関しては半分の
記録域ですむのだが・・・。）

Ｘ６８なら問題あるサイズではないが、もし中間コードレベルのサイズが問題になる
のなら、中間コードのサイズ縮小も必要であろう。
技術的には可能である。しかし、実行スピードの懸念があり採用していない。
（実験すればいいのだが、めんどう。）

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
ループの問題
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

一旦中間コードに直れば、トークンの種類認識が非常に簡単になるため、
ループや条件文が少ないソースではスピードが遅いと感じることはない（と思う）。

Ｖ２.２ではFORループやIF、BREAK/CONTINUEにおいて、２回目以降に来た時には、
１回目の処理によって定まったアドレスに直接飛ぶようになり、これらの構文が速くなった。
（１回目は記録の分、逆に遅くなったとは言え、影響が出るほどではない。）

Ｖ２.７では、さらにNEXT/UNTIL/WENDなど、それまでループスタックを毎回読んでいた
構文も２回目以降直接呼ぶようにして高速化した。
ＳＴＫはスタックによる動作をするが、使わなくてよいところは使わないように
なってきているのである。

ただ、飛び先が場合によって変化するswitch文だけはこのような手法は取れないので、
Ｖ１と相変わらずテキストをすべて読んで検索している。
Ｖ１の時に比べ、中間コードでコマンドのものだけを比較すればよいので検索の無駄は
少ないが、特に大きな区間を検索しなければならないときにはロスが大きい。

この部分も高速化が望まれるが、ここに関しては良いアイディアがない。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
配列の問題
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

配列はアクセスが遅い。Ｖ２.３ではその構造が一新され内部構造は簡単になったが、
インタープリター故に範囲チェックなどをしている分速度は速くない。
しかし、インタープリターである以上、この線は外せない。
その制約の中でいかに速くするか、これは今後の研究課題である。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
総合評価
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

なんにしても、現在レベルではＸ−ＢＡＳＩＣより、まだ１.２倍ほど遅い。
（それより四倍速いというぺけ−ＢＡＳＩＣにはとうていかなわない。）
もちろんインタープリターレベルで。しかも、ＳＴＫの方がちょいとでかい。

	X68000 Compact XVI 16MHz
	10M-Memory
	Human68K V3.02

	STK v2.7	speed2.stk	18sec
	X-BASIC V2.02	speed2.bas	15sec

/*********** speed2.bas
int a,i
print "start !!"
print time$
a=0
for i=0 to 20000
	if i>=18000 then {
		a=a+1
	}
next
print "time=";time$
end

もっとも、サイズはＳＴＫが実行ファイルレベルで外部コマンドをリンクしているためで、
実行時のメモリー利用状況から考えれば、ＳＴＫの方が小さい（と思う）。
実行スピードも、こんな小さなプログラムでは遅くても、bs.stk位にある程度大きく
なればそんなに違いがないかも。

まあ、ＳＴＫの最大の売りは他のプログラムに入れられることだし・・・
（と逃げてどうする。）

ということで、将来のバージョンではこのあたりも改良したい。

（追伸：Ｘ６８０３０でも思いの他速くならないように感じるのが悲しい。）

-------------------------------------------------------------------------------
現在までに解決された項目・対応した項目
-------------------------------------------------------------------------------

トレース時の文字列作成について
	RemakeTokenを廃止の方向で
	元のソースが残っているので、これを有効利用する。
	もしくは逆変換に必要な部分はコメントで埋め込む
	-> ok

文字列変数に配列のアドレスを記録出来ないか
	もしくは配列アドレスを記録する変数の追加
	-> 現在の変数システムでは不可能

エラー時にスタック内容を表示する
	-> ONERRORを使ってトラップする

外部コマンドのX-BASIC型リンク
	-> いろいろな問題があるので止め。
	（プログラム内部への組み込みが難しくなるし、メモリー効率が悪くなるので。）

上の段のローカル変数の参照
	-> 内部構造の変更による解決

-------------------------------------------------------------------------------
ＳＴＫ　将来への展望
-------------------------------------------------------------------------------

現在のＳＴＫでもある程度のプログラムは記述できますが、いくつかの制約もあります。
将来的に改良したい点には次のようなものがあります。

＊中間コードの改良
	現在の中間コードは絶対アドレスを書き込んでいるため速いが、
	その反面アドレスをずらせない。
	中間コード化から実行まで一貫している現在は良いが、
	分離した場合には問題になる。
	ＳＴＫの中間コードオブジェクトを６４Ｋ以内に抑えれば相対アドレスに
	出来ていいのだが。（６４Ｋを越えるようなプログラムをＳＴＫで作成する
	ことはないと思うが。）

＊コマンドライン
	stkx.xに与えられるものはstkx.xに対するものなので、
	内部プログラムに使うのは難しい
		->	内部プログラムに渡すインターフェース（stk.c内）
			もしくは引数を取るためのトークンの設置

＊デバッグ機能の強化
＊トレースモードの改良
	もっと見やすくする
	トレース結果をファイルに書き出せるようにする

＊ローカル配列の実現

＊高速化
	配列の高速化（今はとくかく遅い）
	SWITCHの高速化
	スタックキャッシュによる連続アクセスの負荷軽減

＊減算FOR〜NEXTの追加
	必要かどうかを見きわめてから。

＊ラベル・ループスタックの補正を楽にする
＊ENDIF対策（IFとの対応のチェック）
＊同一固定文字列のまとめによる中間コード領域の縮小
＊ローカル変数エリアの無駄部分の改良
＊フルコンパイラーの作成
	もしくはＣトランスレーターの作成

でも、いつまでに出来るという保証はしませんので、気長にお待ちください。

-------------------------------------------------------------------------------
