┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃		ＡＳＫ３/codeA対応　アクセサリシリーズ８		      ┃
┃			「ＡＳＫＤｅｎ」				      ┃
┃		 Copyright (C) 1998-99 by AIG-Soft			      ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃	歴史								      ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

１９９８／０９／１１
	満開ネットにてＡＳＫに必要な機能の提案がされる。
	（ってな堅苦しいものではなくて、単に有ったら便利な機能の話があっただけ。）
	仮名→英字変換と電卓があれば良いようである。

	仮名→英字変換はＡＳＫＡｃｃの方に実装する。
	電卓は大きくなりそうなので別プログラムにする。
	命名「ＡＳＫＤｅｎ」。安直。

１９９８／１０／０２
	ＡＳＫＤｅｎをいわゆる電卓ではなく式評価にすることに決定。
	その理由は、
		電卓では元々あるもの(OPT.1+OPT.2)に対して優位点をつけにくい
		画面レイアウトが面倒
		式評価なら昔作ったルーチンがある
	である。
	手抜きと言えば手抜きな決定であるが、式評価の方が何かと便利なのは確か。

１９９８／１０／０６
	仮名→英字変換完成。
	ＡＳＫＡｃｃ　Ｖ１.５

１９９８／１０／１０
	ＡＳＫＤｅｎの本格開発開始
	
	元々の変数処理ルーチンでは漢字・仮名名変数やローカル変数も処理出来たが、
	ＡＳＫＤｅｎでは不要なので削除。
	その他細かいところをいろいろと削除したり最適化したけど、それでもでかい。
	自由名変数まで対応させているからなぁ。

１９９８／１０／１１
	とりあえず動くものが出来る。
	ファイル読み込みを入れる

１９９８／１０／１２
	起動前ファイル読み込みも入れる。
	これでＶ１の機能は全部入れた。
	アセンブラー化の開始。

１９９８／１０／１３
	今までもＣのソースを元にしたことはあるが、難しいものは少なかったし、
	数値演算はなかったのでアセンブラとのリンクは簡単だった。
	ところがどっこい、今回はGnuLibの呼びだし数値演算が多く有るので、
	それをFPACKに直す必要がある。引数も多いしワークエリアの確保はあるし、
	大変である。

１９９８／１０／１５
	動かない。
	巨大＋常駐物なのでデバッグが大変。
	メインルーチンと汎用関数をハンドコンパイルしてそれぞれテスト。
	あっ、.dataが残ってる。バグの原因の１つはこれだな。
	でも動かない。

１９９８／１０／１６
	ＧＣＣの出す数値演算の呼び出しを置き換えた関数がおかしかったので修正。
	一応動くようになる。式ファイルも大丈夫そう。
	でも、変数処理が駄目。

	そう言えば、式ファイルの指定方法は、Ｃｏｍｐａｃｔのキーボードでは
	'．'が入れにくいからやりにくいかなぁ（拡張子じゃないよ）。
	ということで'？'に変更する。

	変数名が大文字小文字の区別があると、変換ラインからの入力では
	意外と面倒なので（ＣＡＰＳ状態が変わるから）区別をなくす。

	まだ完成していないのに、変数ダンプ機能を追加。
	いや，デバッグのためには必要だったと言う方が正解か。

	変数処理が動いたり動かなかったりしている。
	いろいろ見てみると、どうもワークエリアの初期化が怪しい。
	あっ、ワークエリアの初期化が通らないことがあるぞ。
	これを修正したらどうだ？

	・・・おいおい、これだけの開発どこでやってたんだ？
	(ｶｲｼｬﾃﾞﾔｯﾃﾀﾄﾊ､ｸﾁｶﾞｻｹﾃﾓｲｴﾅｲ?｡ｶｲｼｬﾉﾋﾄﾆﾐﾗﾚﾀﾄｷ､ｱｾﾝﾌﾞﾗｰﾃﾞﾌﾟﾛｸﾞﾗﾑﾂｸｯﾃﾏｽﾄｲｯﾃﾆｹﾞﾀ｡
	ﾏﾜﾘﾊﾎﾄﾝﾄﾞﾊｰﾄﾞﾔｻﾝﾅﾉﾃﾞｺﾚﾃﾞｲｹﾙﾉﾃﾞｱﾙ｡)
	以下は家での開発。

	まだだめ。結局初期化ルーチンをすべてハンドコンパイルに変更。
	細かいバグを修正したら動くようになった。
	たぶん、ワークエリアアドレスの設定がおかしくて飛んでたんだと思う。

	ドキュメント作成しながら機能チェック。
	あっ、負数が駄目だ。これはアセンブラー版だけだ。
		・・・除算の符号あり/なしを間違ってただけ。
	エラーが出た時に、その行内容も表示しないとわからんので変更。
	式ファイルのサンプルも作る。
	やはりサンプルがないとわからないかも知れないから。

	変換ラインを無条件に半角化するのを、先頭が全角文字の時だけに変更。
	これで文字コード指定に全角文字が使える。
	セパレーターに'、'を使えるようにする処理が不十分なので入れる。

１９９８／１０／１７	Ｖ１.０
	ふ〜長かった。
	最後の最後にＬＨＡのファイル名の制約に引っかかってしまった。
	＠から始まるファイル名は駄目なわけね。

	今気が付いたけど、ひょっとすると符号付き数字での演算が怪しいかも知れない。
	内部では、普通の演算は符号あり、ビット演算は符号なしにしてるんだけど。
	いや、内部演算が符号付きなのに結果表示のデフォルトが符号なしなのがいけないか。
	もし問題になるようなら、次バージョンで修正しよう（いいのかそれで？）。

	・・・と書いたけど、やっぱり―寸何なので、組込み時オプションで
	デフォルト符号、表示進数を設定出来るようにした。
	演算の怪しさについては.docに書くことで逃げる(ｵｲ)。

１９９８／１０／１９
	・・・整数版・・・
	あれ？アセンブル中に見慣れぬWarningが出てるな。
	レジスターリストの表記がおかしいとな。
	movemでのレジスターリストの表記は必ずd?が先でa?が後でなくてはいけないのか。
	Warningが出るだけで、実際のオブジェクトはちゃんと出ているようだから一安心。

	Enzan()の代入処理で、リターン値と代入した値がリターン値で共有されていたので、
	これを分離する。次期バージョンへの対策のためである。

	・・・実数版・・・
	６４ビット演算に向けて調査・研究開始。
	演算関係のルーチンは集めてくることが出来るが、
	変数処理を６４ビットにすること、表示が６４桁以上になることが問題ではある。

	ちょっと面倒なので、息抜きにふと浮動小数点演算を見る。
	floatは３２ビットなのか。これなら今の処理に入れこむことが簡単そうだ。
	今の３２ビット整数版と大きく違うのは演算そのものと表示、数値の読み取り位か。
	もしやるならいきなり単精度実数演算化だな。

	とりあえず実数演算（だけ）版を作る。
	何とか動く。変数処理も完璧。
	
	ところが、意外な問題があった。
	整数部分の演算は良いが、小数部分には２進小数では絶対に避けられない誤差があり、
	表示時に有効桁数を決めて処理しないと、それがもろに見えて良くない。
	（累積演算誤差ではない。それを生むもっと前段階。）
	floatは３２ビットあるからといって、それを全部見せたらまともな数字にはならないのだ。
	まさかこれほどひどいとは思わなかった。
	
	実数演算をＡＳＫＤｅｎに正式に入れる上での問題は３つ。
	１つはその誤差の問題。
	１つは整数と実数で共用問題。共用出来る部分と出来ない部分があるが、一番中心となる
	入出力（数字文字列の読み取りと表示）と演算そのものが大きくことなるので、
	同時演算は不可能になること。実数モードと整数モードを切り替える必要がある。
	大きな問題ではないだろうが、せめて整数値だけでもモード間でのやりとりはさせたい。

	あと１つの問題は、現在の式評価ルーチンでは関数を実装しにくいこと。
	実数を扱う以上、やはり平方根、三角関数、自然対数、常用対数、円周率くらいは
	必要だろう。それらをどう入れるかが問題である。

	ちょっと問題が多いし、私自身は小数演算に必要性がないので今回はこれまでとする。
	また時間があれば続きをしよう。

１９９８／１０／２０	Ｖ１.１
	・・・整数版・・・
	・仮名長音をマイナス（演算子）とみなす。Compactキーボード対応
	　でも'。'→'．'は難しいのでやめ。
	・ルーチン改良・不要処理削除による省メモリー
	　Yusen():書き直し,Enzan():改良,var_num_write()/var_dump():再代入不可なし
	　Ｃレベルでもまだまだ改良の余地はあるということ。
	・単精度実数実装のための準備（だけ）

	・・・実数版・・・
	ということで、時間があるので関数実装を考える。
	関数でy=func(x)という単一引数（複数引数を持たない）ものなら単項演算子として
	処理出来る。括弧は単なる演算順位を変えるだけとなる。もっと言うなら無くても良い。
	複数引数を持つ場合は括弧の扱いが全く異なってくる。いや、引数取り込みというものが
	必要になる。
	FLOAT?.Xでサポートしている関数ならべき乗power()だけが２引数だ。あっ、これだけなら
	２項演算子にすれば良いのか？
	
	実は、ＳＴＫがスタック型になったのはこの式評価ルーチンでは複数引数が処理出来ないから
	である。スタック型なら問題ない。当時引っかかった問題にまたここで出食わすとは。
	ＡＳＫＤｅｎもスタック型計算に変えようか(^_^;)

	関数を実装する。
	単一引数ものだけを、単項演算子と同じように実装している。
	関数は内部コードをFLOAT?.Xのファンクションコールそのもの($fexx)にした。
	これにより、プログラムの自己書き替えはあるが、処理は非常に簡潔になった
	（実体はほとんど存在しない）。
	我ながらうまい方法である。

	２引数ものは・・・次回回し。

１９９８／１０／２１
	・・・実数版・・・
	実数版がCompactXVIで未登録の割り込みエラーが発生する。
	関数実装ではプログラム内部を書き替えるためにキャッシュの制御をしている。
	それにはIOCS SYS_STATを使っていたが、これは３０より前の機種には存在しない。
	機種を判定して通らないようにしていたはずなのだが、それが効いていないようだ。
	・・・機種判定の条件分岐が間違ってただけ。ということは、３０でもキャッシュを
	制御せずに自己書き替えで動いてたわけか？（たぶんキャッシュの少ない３０だから
	いけるのであって、４０以降ではだめだろう。）

	剰余が通ってなかったのを修正。
	あれ、でもじゃあ、今まで何の処理をしてたんだ？（一応答えが表示されてた。）
	相変わらず誤差が一杯なのであっている答えかどうかが解らないこともあるが。

	比較がおかしかった（ような）ので修正。
	問題は２つ。スタックを不要に取り出していたのと、１が２５５になっていたこと。
	たぶん使ったら暴走してただろう。そう、今まで使わなかったのだ。
	使う前にソースの問題を見つけて修正したわけである。

	２引数関数power（べき乗）の実装。結局演算子'!'とした。
	これで予定の関数は全て実装出来た。

	誤差の問題。
	X-BASICや手持ちのプログラム電卓、WindowsのAccess95(VB)まで出してきて結果を調べる。
	SIN/COS/TAN/PIで調べる限り、どうも小数点以下８桁以降は駄目なようである
	（__FTOSでの表示ではもっと下の桁まで出ている）。
	それなら８桁までで切れば無くなるかと思ったが、だめ。
	関数はなんとかなったが、普通の小数点演算がまだ使いものにならない。
	FLOAT?.Xがだめなら自前で計算するか、64bit-doubleで計算させるか。
	でもそうなったら完全な作り直しになるのでここまでの研究はパー。
	そもそも、何でこんなに精度が低いんだ？単精度ってこんなものか？

	表示を__FGCVTに変えて、表示桁数を色々と変えて有効桁数を調べる。
	どうやら６桁までで切れば大丈夫のようである。
	（７桁では関数の誤差はなくなるが、普通の小数演算でまだ誤差が出る。）
	思い切った精度下げが必要だったわけだ。
	
	結局のところ、まともに実数演算をしたかったら倍精度を使え、ということだ。
	Ｘ６８（というかＩＥＥＥ）の単精度は４バイト＝３２ビットしかない。
	ＳＨＡＲＰフォーマット（Ｘ１など）では５バイト＝４０ビットだ。
	この１バイトの差はかなり大きい。
	
	・・・という事実がわかっただけでも、今回の研究は成果があったと思う。
	
	まあ、ＡＳＫＤｅｎでの実数演算はおまけみたいなものなので、
	とりあえずここで止めておきたい。これ以上の精度が必要なら倍精度＝６４ビット
	必要となり、システムの大幅改良が必要となる。その時には整数演算も６４ビットに
	したい。

	・・・整数版・・・
	.docで演算子の説明が今一良くないので修正。
	Ｃとの違いを明記する。
	元々数値表現が違うからいいとは思うけど、一番引っかかるのが剰余の
	違いかも知れない（自分でもよく間違える）。

１９９８／１０／２２	Ｖ１.２
	・・・整数版・・・
	今まで計算出来たのが仮入力時だったのを、仮確定時も可能にする。
	これにより、平仮名で打ち込んでSHIFT+XF5で英字に直して計算させることが
	可能になり、入力が楽になる。
	因みにこの変更にともなうサイズ変更は全くない。
	それもそのはず、単にアクセサリ構造体中の呼び出せるポイントの指示を変えるだけだから。

	Enzan()をアセンブラーで書き下ろす。
	理由は省メモリーのため、というのは結果の話で、実際には実数演算を
	組み入れる時に一番変更されるのがここだからである。
	解りやすいルーチンにしておこう、というわけだ。

	仮名長音（ー）をマイナスとみなす処理をなくす。
	理由は、仮確定時にも計算出来るようになったことで，ＡＳＫレベルで
	長音→マイナス変換が出来るようになったことと、今までは単項演算子と
	２項演算子のマイナスのみ処理していたが、実は単項演算子ーーや、
	今後実数が入ってくるとＥーの処理も出てきて、対処が増えるからである。

	・・・実数版・・・
	整数版と実数版の共通化を始める。
	変化点がかなり多いので手間はかかる。

	実は実数版は整数アセンブラー版を元に全部アセンブラーレベルで開発したので、
	Ｃ版は存在しない。アセンブラーから逆にＣを作ってもいいが、手間なのでやめておく。
	アセンブラーレベルでは整数も単精度実数も３２ビットなので区別は少ないが、
	Ｃでは型の違いが大きく引っかかり、勝手に型変換されるのでよくないのだ。
	まあ、変更すべき点は書けるので、コメントでも入れておくか？

	１０進以外での表示は無くそうと思ったが、内部表現を表示するというのが
	意味があるかも知れないのでそうすることにした。
	即ち、整数化はせずに３２ビットのまま表示するのである。
	こうすると、FLOAT?.xの呼びだし時に便利な気がする。
	でも整数化表示も必要か？

	モード切り替えで実装するつもりだが、起動時＝計算時に切り替わらないと意味がない
	ので、結局は２つの起動キーを持たなければならないかも。
	変数を両モードでどう扱うか。その時定義した変数はモードに従えば良いが、
	問題は式ファイルである。整数用／実数用と分けるか？

１９９８／１０／２３
	今後は実数版のみにする。要するにＶ２として完成をめざす。

	・演算
	・式評価
	・数値読み取り
	・式ファイルは整数・実数の２つに分ける
	・起動キーを２つにする
	・表示（内部表現／整数化）
	　起動後の両モード移行は不要。ただし実数の結果表示にのみ整数化表示を付ける

	小さなルーチンは全てハンドコンパイルで直す。
	これでだいぶ見た目にすっきりしてデバッグしやすくなった。
	なにせ実数版はＣのソースがないから、アセンブラーレベルでのメンテナンス性を
	上げないといかん。

	一応動くものが出来たが、どうも不安定。実数計算を何度かすると暴走する。

１９９８／１０／２４
	・・・実数版・・・
	・０除算対策
	　今までそれに対する処理は入れてなかったが、FLOAT?.Xでは１扱いになるようだ。
	　ＳＴＫではちゃんと判定されてエラーを出している。
	
	・式ファイルの実装を変更
	　オプション形式にする。これでないと２つの式ファイルの指定が出来ないから。
	　Ｖ１と非互換の部分が出てしまった。
	
	・変数の別定義モードは使っていないので削除
	　var.mode&BIT15
	
	・ハンドコンパイルを進める
	
	デバッグの途中に、動いてた実数版のソースを見ようと思って気が付いた。
	「いつのまにか古いソースになってる！」
	動作が完全だった実数版の最後のソースがどこにもない！
	Ｃの途中まで変更したものもない。
	あぁぁ、ソースが消えてる(T_T)。
	いつ消してしまったんだ！！
	
	古いソース＋思い出しで作業を続ける。
	お蔭でデバッグがぜんぜん進まない・・・。
	取っても取ってもバグが出る。おまけにまったく謎の「未登録割り込みエラー」も出る。
	ハンドコンパイルでかき直したルーチンのバグもあるから、どこが問題やら
	さっぱりわからなくなりつつある。はたして完成するか？

１９９８／１０／２４〜２５	Ｖ１.３
	本当はいきなり実数版を作りたかったが、それがあまりに暴走しまくるので
	その中で出来たルーチンを整数版に組み込んで動作を確認することにした。
	一応省メモリー＆機能アップも出来ている。

	・・・整数版・・・
	実数化のため作成中のルーチンを組み込む
	　・ハンドコンパイルで最適化したもの
	　・var_dump:現在の表示進数に従って表示するように変更

	変数エリアが添付の_1でいっぱいになっていて、変数の追加が出来ないことが判明。
	デフォルトを１０２４バイトに増やすとともに最小値を２５６に減らした。

	式ファイルの指定方法を実数版に併せて変更。
	（引数形式からオプション形式にする。）

	場合によってメモリーを破壊していたのを修正。
	（演算子スタックとハッシュ表が重なってた。ワークエリアアドレス計算の間違い。）
	謎の暴走はこれが原因？

１９９８／１０／２５
	・・・実数版・・・
	ひたすらデバッグ
	
	組み込み時指定の式ファイルが読み込まれないバグが取れない。
	正確には、コマンドラインの最初の２引数位までが読めてない。
	いろいろとやっている内にアクセサリの削除が出来てないことも解った。
	
	式ファイルが読み込まれないのは，オプションそのものが取り込めてないからだと判明。
	なぜかオプションを記憶している領域が破壊されている。
	潰しているのはAttachAccである、というところまで解った。

	変数は毎回クリアされると思ってたら、１回定義したら消えないことが判明。
	これはクリアする機能が必要だな。','で始めたら変数クリア。

１９９８／１０／２６
	・・・実数版・・・
	夜中に原因が解る。
	AttachAccでAChへの記録がおかしい。AChでなくオプションのエリアに入っていたようだ。
	このためオプションが破壊され、式ファイルが読み込めてなかった。
	アクセサリの削除が出来ないのものこの理由。
	記憶されてないAChを参照しているのだから。
	
	今まで出ていた、ASKDen2を解除して、再アセンブルしてもう一度常駐して起動すると
	暴走するバグもたぶんこれのせい。
	
	ということで、ほとんどのバグがこれで直ったはず。

	実数に合わせてドキュメント作成開始。
	大幅改訂。整数では嘘も有ったので修正も入れる(^_^;)。

	・各種チェック＆テストを実行
		変数
		Ｅ表現同士の計算
		６８０００マシン

	６８０００機で関数が呼び出せなかったのを修正
	（キャッシュクリアルーチン内に関数の書き込みがあって、
		６８０００機ではそこが飛ばされていたため。）

	再代入不可変数処理を復活。
	起動時に/i,/fで指定した式ファイルで設定された変数は再代入不可＝定数として
	扱わせるようにした。？で読み込んだ時は通常変数になる。

	変数の交互参照を追加。これで整数・実数両変数を交互のモードで読めるようになった。
	ここでは内部表現は対応しない（整数化のみ）。

１９９８／１０／２７
	・・・実数版・・・
	var_dumpを１行１変数から１行複数変数表示に変更。
	たくさん変数を定義しても出来るだけ１画面に収まるようにした。
	・・・としたかったが、うまく表示出来ないのでやめ。変数名長が長い時に
	表示がずれてしまうのだ。画面表示座標を細かく制御すれば出来るのだが。

	hashのリターン値を.w=.l保証に変更。
	これにより一部のルーチンがちょっとだけ小さくなる。

	ハンドコンパイルの追加
		var_define/var_search
	たぶんこれ以上はしない（後は大型ルーチンしか残ってないから）。
	・・・でも動かない。う〜ん。

	会社で頼んだ栗が来た。
	味は・・・なかなかおいしかった。６００ｇ￥１０００なり。
	６００割る１０００の余りじゃないぞ。
	そういえば、この栗の価格でおかしいのは、１１５０ｇで￥２５００だったということ。
	ほとんどの人は６００ｇ＊２＝￥２０００で買ってましたとさ。
	（そりゃそうだ。）

	var_searchは何とか動いた。move.lとleaの間違いだったとは。
	var_defineはだめ。原因不明。
	
	￥（剰余）が動いてないことが判明。
	整数時は計算ミス、実数時は「整数のみ」のエラーが出る。
	おかしい。

１９９８／１０／２８
	・・・実数版・・・
	早起きしてデバッグ。var_defineはmoveとaddの間違いだった。
	やはり眠い時のデバッグは駄目か。今も眠いけど。
	常駐物のデバッグには表示ルーチン組み込みが一番。

	剰余が効かないのは英大文字小文字変換のミス。
	\($5c)が小文字化or.b #$20で|($7c)になっていた。
	だから結果がおかしいし、実数では使えなかった。

	Enzanで代入ルーチンは結局１つしかなく引数にする必要もないので直呼び出しにする

	各種チェック＆テストを実行
		オーバーフロー
		アンダーフロー
		引数不良

	オーバーフロー／アンダーフローのエラーチェックが全く行われていなかったので
	追加する。また、一部関数の引数エラーのチェックも追加。
	これに伴いエラーメッセージも追加。
	エラー処理を楽に行うためにリターン値（と言うよりその返し方）を変更。
		・・・と、したけれど・・・
	３２ビット整数の加減算と乗算ではオーバーフローはチェックしないようにする。
	なにかと無い方がよさそうだから。除算は元々無い。
	結局フローチェックが入るのは実数演算のみとなる。

	演算子を考え直す。
	・二乗はあまり使いそうになりので廃止。**はべき乗にする。
	　考えてみればFORTRANはそうなってたよな。
	　あれ？べき乗の優先順位が入ってないぞ->設定。
	・演算子 &&,||,!追加
	  比較演算子があるのに、これらがないというのはちょっと成ってないような気がしたので。
	  あれ？論理とビットの意味を間違ってるぞ。.doc書き直し。

	とりあえずここまでで必要機能の実装・エラーチェック・デバッグが済んだので
	変数が増えた時に演算が急に遅くなる原因を調査開始。
	アセンブラー化の時のエンバグなら良いが、根本的アルゴリズムのバグだと恐い。

	Ｃ言語版で実験。遅くない。
	やはりエンバグか？
	ハッシュ当たりが怪しいが。

	とりあえず他の部分でも高速化可能な部分を改良。
		EnzanRead	文字限定で高速化

	ふとしたことで遅い原因がわかった。
	/i,/fで読み込む式ファイルである。これを毎回ファイルから読んでるので
	遅くなっていたのだ。FGETSsはその作り上遅い。１バイトづつ読んでるから。
	（これは$1a関係の判定のため。くわしくはDicBushuのソースを参照のこと。）
	そういう作りだから仕方無いが、何とかしなくてはいけない。
	その式ファイルはほとんど定数定義だから、クリアされない限り最初だけ読めば良いのだ。
	ということで改良。
	これによって、起動時式ファイルが評価される時とされない時が出るので、
	そのあたりを説明しておく。起動時式ファイルは定数定義専用とする。

	ところがどっこい、式ファイル読み込み直後（起動時／？とも）の
	式評価でエラーが出る。いつからだ？
	Ｃ版では出てないのでアセンブラー版だけの問題。

１９９８／１０／２９
	・・・実数版・・・
	考えてみれば、ほとんど３週間、朝から晩までこれにかかりっきりなような。
	家ではもちろん、会社でも仕事の合間をぬってやってるもんなぁ。
	いかんいかん。
	そろそろ完成させねば。

	ハンドコンパイルの追加
		FGETSs
	本当にこれ以上はしないぞ。たぶん(^_^;)

	vsiki_readF
	式ファイル後の演算がエラーになるのは、Ｃのソースがおかしかった。
	それを直すことでエラーはなくなったが、式ファイル評価後の演算が続かない。
	なぜ評価の継続が切れる？
	
	vsiki_readF
	継続が切れるバグはアセンブラーレベルの修正ミスだったが、それを修正したら
	またエラーが出るようになった。なぜだ？？
	
	そこらじゅうに表示ルーチンを入れて追う。
	どうやらvsiki_readFではなくEnzanに問題があるようだ。
	・・・あぁ、なんてこったい。.w→.lだけの間違いだったとは。
	これで直った。

	別のバグ発見。変数への代入確定前にエラーが出た時に変数が未確定のまま残り、
	そこに再代入しようとするとエラーになってしまう。
	変数を出てきた時に即０（整数/実数）で確定してしまうことで解消。
	ＡＳＫＤｅｎは言語じゃないからこれでいい。

	式ファイルが修正された時に自動判定して読み込むルーチンの追加。
	DicBushuと同じルーチンを入れれば良いはず。

	あら、またバグ？
	演算結果が全く駄目。式ファイルの修正チェックを入れてからだ。
	でも、どこがおかしい？
	ほんまに、どこまでやったらバグがなくなるんじゃい。

１９９８／１０／３０
	演算結果がおかしかったのは、演算ループを１回も通らずにいたため。
	ループ条件をwhile(ret<=0)からwhile(ret<0)に変えたのにretの初期値が0のままだった。
	でもなんでＣでは動いたんかいな？

	var_dumpで変数の整数・実数を表示させるようにする。
	実数の場合、整数桁のみでも有効桁数以内なら後ろに.が付くが、以上になると付かないので、
	見た目の区別が出来なくなるため。

	ソースの整形。オフセット表を作り記述することにした。
	少しは見やすくなったかな？ただし、Ｃで作っている部分には無効だし、
	即値で書いている部分も残っているだろうから、構造体の構造を変えてはいけない。

	現在の変数設定内容を表示するツールを外部に用意する(Den2Var.x)。
	やっぱりあった方がよさそうなので。
	ほとんどvar_dumpのルーチンを抜き出して独立させただけ。
	makeファイルも書き替え。２つの実行ファイルを更新させるようにするのに手間取る。

	これで出来た！・・・と思ったら、実数→整数化の時に、オーバーフローする時が
	あるのに気が付いた。整数化出来ない時はエラーを出すか整数化しない。
	あれ、エラーチェックを入れているのにうまく動かないぞ？
	・・・うまく動いていないように感じてしまっていただけか？
	実数の普通表現・内部表現のどの時に整数化が行われるかが難しい。表を書いておくか。

	いんや、表示系は勘違いだったが、変数の交互変換はエラーは出しているのに、
	それエラーとして処理出来てなかった。Ｃ版からのバグ。
	他のエラーもあるのに無視されてた。修正。

	これで大丈夫だ！！・・・(T_T)
	いつの間にやら結果がキー入力で返せなくなっているではないか！！
	cbufが更新されていないのだ。
	いったいいつになったらバグがなくなる・・・。

	極めて力技的に修正。
	これで表面上のバグはなくなった・・・無くなったよね？

	あかん、実数の&&と||が異常だ。
	実数→整数化のオーバーフロー処理対策で処理を変更したのがいけないようだ。
	でも、元のルーチンにも問題がある。どうしたものか。
	あっ、良い方法思い付いたぞ。修正。

１９９８／１０／３１	Ｖ２.０
	やっと完成。結局１０月は丸ごとこれの開発に費やしたようなもの。
	サイズも.xレベルで＋約１.７Ｋ（ソースは＋１９Ｋ）。
	アセンブラーレベルの改良としては大型だな。
	しかもサイズの縮小化対策も行いつつだから。
	
	バグが出ない限り、しばらく改良はしないぞ。
	６４ビット演算化も当面見送り。

１９９８／１１／０６	Ｖ２.０１
	あっ、ソースの先頭に'q'が入っている。
	いつ入ったんだ？

	演算子とエラーメッセージのテーブル構造に無駄が有ったので改良。
	かなり省サイズ。
	エラーメッセージの表示が少し遅くなったと思うけど、あまりないことだからいいだろう。
	演算子も少しスピードダウンしたかも。
	まあ、ＡＳＫＤｅｎはそんなにスピードを要求しないから良いだろう。

１９９９／３／末
	Ｓ社ゲーム機Ｓの「サクラ大戦（１）」をやり終える。
	３回目。今回は神崎すみれ。
	それはそうと、おまけゲームの花札が良い（実は花札好き）。
	しかし、いちいちＳを立ち上げるのが面倒。
	Ｘ６８上に「まとも」な花札はないか（強烈に求む！）。
	そういえば、サクラ大戦２のおまけで大富豪は出来ないのか？

１９９９／４／５	Ｖ２.０２
	２０３８年問題を計算する時に問題発覚。
	次の計算式を入れた時の結果がおかしい。
		65536*32768/60/60/24/365
		~~~~~~~~~~~ここまでは大丈夫
	どうやらオーバーフローを起こす近辺での計算でおかしくなるようである。
	・・・と思ったら、オーバーフローを起こしてただけ。
	式も間違ってる。
		(65536*32768-1)/60/60/24/365
	オーバーフローが解りにくいので表示のデフォルトを符号付きにする。
	これにともない-Mオプションを無効化して-Pオプションを追加。
	しかし、根本的解決には整数演算を内部だけでも６４ビット化する必要があるのかも知れない。
	そのあたりが次回バージョンの鍵となるであろう。

	ＥＸ６８チェックを入れる。
	その意味などはDicBushu V2.0の.hisを参照のこと。

	変換ラインの表記をわかりやすく変更
		電卓というのは解るから、整数／実数を直接表示

	メッセージの修正と変更

	アーカイブのファイル名が８文字を越えているので変更
		ASKDen*.Lzh → Den*.Lzh

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃	技術的な話	（プログラム内部に興味の無い人は飛ばそう！）	      ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

このＡＳＫＤｅｎの持っている式評価と変数処理ルーチン。
この程度のプログラムに使うにはあまりにしっかり（？）していると
思われる人もいるかも知れない。

それもそのはず、このルーチンは元々ちゃんとした言語の作成の途中で出来たものであり、
逆に言えば、言語の中枢とも言えるそれらを抜き出したものなので、
ここでの必要以上に作りこまれているのである。

ＡＳＫＤｅｎに合わせて若干の機能縮小はしているものの（漢字変数・ローカル変数の削除など）、
基本的にはフルセットである。不要部分をもっと細かく洗い出して小さくしても良かったが、
エンバグするといけないので最小限の変更にしてある。

だから、ＡＳＫＤｅｎから抜き出して、他の言語に使うことだって出来る。
使っていただいてけっこうである。
（もちろん、それをシェアウエアを含め、売りものにするのは反則である。）
仕様説明書がないから無理か？要望があればそれも発表するけど。

変数管理・式評価の方法については、くわしく書くと（たぶん）１冊の本が書けるほど奥が深いので
割愛するが（希望があれば次のバージョンででも書くかも知れない）、
基本的にはスタックによって逆ポーランド記法に変換して処理している。
その変換結果というものは、ＳＴＫにおけるスタック上に詰まれるそれと同じである。
そう、スタック型言語というものは、すべからく逆ポーランド記法をするのである。

ついでに言うと、ＳＴＫ　Ｖ２.９には演算結果にバグがあった。ＡＳＫＤｅｎ開発中に気が付いた。
ＳＴＫの問題と言うより、私が使っている汎用ライブラリのバグであった。
気が向いたら差分を発表することもあろう。

式評価どころか、ＳＴＫそのものを入れたらよかったのかな？
でもそうすると、使いにくくなるからね。

	・・・Ｃの落とし穴・・・

>>演算子は、符号ありなしで最上位ビットの扱いが変わる。

	0b10...00 >>1	あり	0b11..00
			なし	0b01..00

実はこれではまったのであった。「結果が違う！」って。
要注意である。ＳＴＫのバグの１つもこれである。

	・・・アセンブラーの落とし穴・・・

.data,.bssが付いていると、ソースの書いてある場所ではなく、
後ろにまとめられ、.textの後ろに配置される。常駐プログラムでは
当然常駐エリア外に出てしまう。このため暴走はしないが動作異常を起こす。
特にＧＣＣでソースを作るとよく出てくるので注意である。

	・・・LHAの落とし穴・・・

LHAではファイル名の先頭が'@'のファイルは特別の意味がある。
それを知らずにそういうファイル名を付けたもんだから、LHAでアーカイブ出来ずにはまった。
結局_に変更したのであった。

	・・・単精度実数演算時の誤差について・・・

単精度実数演算における誤差については上の履歴に書いたのでその通りなのだが、
やはり３２ビットでは桁が足りないようであり、ＳＨＡＲＰフォーマットでの
単精度５バイト＝４０ビットと言うのは実に的を得た桁であるといえる。
（もちろん、実験で決めたのだろうが。）たしか８桁の有効桁数があったと思うが。

もう少しで自分で１０進演算（ＢＣＤ）ルーチンを作るところであった。
もちろんそうなれば、開発は非常に遅れることとなっただろうし、
場合によっては完成しなかったかも知れない。
向学のため、いつかは作るかも知れないが。

６４ビット版？
これは本当に、それを求める声がなければ作りません。
３２ビット単精度実数は声が出る前に作っちゃったけど。

	・・・有効桁数について・・・

有効桁数は小数点以下の桁数ではなく、数字として実際に表現される桁数で、
これは実数の仮数部のビット数による。

有効桁数６桁の場合、以下の表現は全てその範疇になる。
	0.1234565
	123.456
	123456
	123456E2
	1.23456E-2

Ｘ６８のというかＩＥＥＥの単精度は３２ビットで、この内仮数部が２３ビット、
指数部が８ビット、符号１ビットである。
仮数部が２３ビットなので、それで表現出来る数の範囲は、

	＋４１９４３０３〜−４１９４３０４

となる。これが有効桁数６桁保証の正体である。
０〜９まで現わせている桁が６桁＋最上位桁は０〜４までなので不十分と言うことである。
・・・って、解ってるんなら最初から実験する必要はなかったんだけど、これは後で解ったこと。

因みに３１ビットの仮数部があるＳＨＡＲＰ単精度なら、仮数として表せるのは

	＋１０７３７２５４４０〜−１０７３７２５４４１

なので、有効桁数は９＋１桁となる。

ここで気づいた人は気づいただろうが、実は実数時には整数時に比べ有効桁数は減る。
表すことが出来る数の範囲は広くなるにもかかわらずである。
ここん所はしっかり押さえなくてはならない。
整数でいける範囲は整数で処理しないと、有効桁が少なくなり、
整数桁の範囲でも誤差が出てしまうのだ。要注意である。

そうそう、単精度実数に意味があるのか？という意見がありそうなので答えておこう。
実は、陰照系石の３Ｄ Ｎｏｗ！や、あのＤｒｅａｍＣａｓｔのＣＰＵのＳＨ４の
ジオメトリエンジンの計算も３２ビット単精度である。ということは、世の中これが
はやりということかも知れない。だから、覚えておいても損はないぞ。

・・・等と言い訳しておく(^_^;;)。

	・・・変数の格納方について・・・

	len mode num name[00]
	1   1    4   len+1		size
	0   1    2   6        6+len+1	offset

lenは1byte。従って、文字列長は最大255byteまで。
00は予約で、1〜255までが有効。

modeは変数モード。現在定義済みは次の状態。
	VKAKU	0=確定,1=未確定
	VDAI	0=普通,1=再代入不可（定数）
	VTYPE	0〜31
		0=数値(V_INT)
		1=実数(V_FLOAT)

num:数値は32bit(long)数値のみ。
それを数値（整数・実数）とみなすかポインターとみなすかは利用システムによる。

エリアサイズはlongサイズ。
ハッシュは変数エリアの1/16の大きさで、longサイズ。
ただし、その要素数はmin 1024,max unsint=64Kで、各要素はlong。

	・・・覚え書き・・・

bclr.b/.l
	ビットが０かどうか調べＺフラグを変更した後クリアする
bset	同bit=1
bchg	同bit^1

div? y,x	x.l.w=x.l/y.w ... x.h.w
mul? y,x	x.l=x.w*y.w

add/sub	C=1:アンダーフロー , V=1:オーバーフロー
	C=1でアンダーフローなところはZ80からの頭では―寸違和感がありますな。

IOCS	_B_PUTC		２バイトコード表示可能
DOS	_PUTCHAR	不可（１バイトコード専用）

０	整数でも実数でも０の表現は０。

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃	あとがき							      ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

キーの配置などは私の趣味です。変更出来ません(^_^;)。
（私は普段ENV3.ASKをちょっとだけ変えたものを使っています。）
どうしてもしたい人は、ソースを直して下さい。

かなり複雑なので、まだどこかにバグが潜んでいるかも知れません。
可能性は非常に大です。
何か見つけた人はご連絡を。
でも、お約束だけど、何があっても「責任取って！」はなしね。

	「フリーソフトは使う側の責任で。」

	・・・他の開発は？・・・

２つ程開発しようかな？と思っているのがあるけど、
１つは気力が涌かない、１つは難しく基礎技術開発も出来てない、
ということで進んでません。

当面新規物はないかな？
	「会社の仕事をせい！！」
おぉっ！？

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃	作成環境							      ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

ＡＳＫＤｅｎは次の環境で作成・動作チェックされました。（敬称略）

	X68030 (25MHz/12M-Memory/FPU)
	X68000 CompactXVI(16MHz/10M-Memory)	... 自宅のマシン
	X68000 CompactXVI(16MHz/ 4M-Memory)	... 会社に持っていってるマシン
						    今回はこれが非常に役に立ちました(^_^;)
	
	Human68K	V3.02		SHARP/Hudson
	COMMAND.x	v3.00		SHARP/Hudson
	ASK68K.SYS	V3.02		SHARP/ACCESS Co.LTD.
	codeA.SYS	V0.08		FDS/SHARP/ACCESS Co.LTD.
	
	HIOCS-plus	V16.11		SHARP/Y.Nakamura/立花えり子
	TwentyOne.sys	v1.36c14+p5 	Ｅｘｔ/GORRY/立花えり子
	
	HAS060		v3.09+79	Y.Nakamura/M.Kamada
	HLK evolution	v3.01+11	SALT/立花えり子
	
	ＷＳ		V0.90		Fuchi
	SuperED		v1.18		T.Nishikawa
	
	STK		v2.91		AIG-Soft
	
	その他多くのソフトたち。

特に、ASKはV3.02で、codeAはV0.08でしか確認していません。
ASKのV3.00,3.01では動作するかどうかは未確認です。

各ソフトの開発者に感謝致します。

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃	参考文献							      ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

	ＭＺ−８０活用研究、工学社、１９８２
		逆ポーランド記法について（ｐ９５〜）
		これを元に最初に実際に式評価を実装したのがＳＴＫ。

	Ｏｈ！Ｘ １９８８／８、ソフトバンク
		数値の内部表現について（ｐ２８〜３３）。

	ｉｎｓｉｄｅＸ６８０００、ソフトバンク、１９９２
		単精度実数の有効範囲について（ｐ１１０）。

	復活Ｏｈ！Ｘ　第１巻、ソフトバンク、１９９８
		３２ビット単精度について（ｐ１３）

	ぷにぐらま〜ずまにゅある 第六版  第一刷,立花えり子
		ＸＣのマニュアルが使えない場所(ｶｲｼｬ?)で重宝します。
		今回はfefuncの項が非常に役に立ってます。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
