現在、制作中です。暫くお待ち下さい m(_ _)m 。
当初、2000年春を First α Version の登場時期とする予定でしたが、ずれ込んで、初夏から、夏頃になりそうです。御免ね〜。取り敢えず、バイナリコードをもう少し煮詰めないと、後々困るかな…。
・ 現在の、作業状況
最近は、ソフトウェア開発の方が忙しくて、余り手が回って無いのですが、少しずつは前進しています。
コンパイラの、展開理論を構築中です。ほぼ理論自体は、構築完了しましたが、効率の良いインプリメント方法が結構難しくて、悩んでいる所です。あれだけ無茶な記述をしても通ってしまう上に、激しい最適化が行われる C/C++ 処理系コンパイラの作者さんは凄いと思います。最初から、完全なものを目指すのは難しそうなので、入れ子を許さない融通の利かないベースを作ってから、拡張して行く予定です (^^;; 。
えと、実行速度の低下防止と、コンパイラの作成を容易にする為に、中間バイナリコードを、柔軟な仕様に改良しています。出来るだけシンプルな構造で、柔軟さを持たせる事が出来れば理想的ですが、中々難しい様です (^^ゞ 。デバグ時に、行番号をきちんと表示出来る様にする為、デバグコードを埋め込める様に、仕様を拡張したりとかもしています。
pass 1 で、基本的な置換えと、構文チェックを行い、pass 2 で、高度命令の展開と、変数名の置換えを行い、pass 3 でオブジェクトコードへ展開すると言う考え方なのですが、安全性を考慮して、中間ファイルをばかすか生成する予定です。ただ、最終的には、2 pass に収める予定ではあります。
・ 基本的に、フリーソフトです。
・ 言語仕様は、C 言語のサブセットライクです。但し、細かい所は、C 言語とは異なる仕様を持っています。当然ですが、大文字と小文字を区別します。
・ 非リアルタイム系ゲームと、小物ユーティリティ向けに設計しています。この為、システムメニュー、タスクトレイアイコン、ポップアップメニューはシステムでサポートします (初期ヴァージョンでは未実装になる可能性が高いと思います)。
・ 実行エンジン (インタプリタ) は、かなりシンプルな構造になっています (内部には、ループ命令などは、一切持っていなかったりします (^^; )。基本的に、コンパイラがスクリプトを単純な構造へ展開した後に、中間言語へ変換します。インタプリタなので、多少速度的には不利かも知れませんが、最近の CPU は十分高速ですので、問題無いと思われます。
・ C 言語ライクなため、エラーチェックは、かなり弛くなっています (実行時に、エラーを検出出来ない為です)。また、実装上の都合により、文字列の取扱いに、多少の制限が有ります。インタプリタエンジンはゆるゆるの仕様ですが、コンパイラ自体は、かなりストイックに、構文を解析する予定ですので、きっちり書かないと駄目だとは思います。Ｃ言語ライクと言うのを見事に引きずって、パラメータの省略を許しません。
・ Windows 9x カーネルと、NT カーネルによる実行速度差を出来るだけ解消するため、タイマ管理機能を充実させます。
・ 外部 dll, Susie Plug-in, unlha32.dll に標準で対応します (初期ヴァージョンでは、未実装になる可能性があります)。
・ 基本的な機能は基本システムに実装されますが、頻繁に使われないと思われる機能は、Plug-in (拡張子 alp) による実装になります (Plug-in は dll です)。
・ Plug-in が使用可能になるのは、少し遅れると思いますが、将来的な問題を回避する為、『出来る限りウィンドゥのサブクラス化は行わない』様に推奨する予定です。Ash の System 側では、サブクラス化の対策として、終了時に、ウィンドゥプロシージャを強制的に元に戻します。この為、変なインプリメントをしていると、終了時に必ず問題を起こします。また、一部の命令を実行すると、内部でサブクラス化されているかを調査する様にする予定です。もし２重にサブクラス化が行われている事を検知すると、強制終了しますので、注意して下さい。この仕様は、場合によると大きな制限ですが、予期せぬ不具合をある程度回避出来るので、緩和する事は有りません。
・ NT4.0 で動かない汎用用途の Plug-in を一般 Ash ユーザが使える形で公開する事は禁止する予定です (『特殊』用途の場合は、明記する事により可能 / 限定用途では無い事に注意)。Windows 9x カーネルにしか無いエントリを使ったり、16bits dll を使ったり、I/O アクセスを行うと、Windows NT 4.0 では動きません。サークル内部や、個人的な Plug-in に関しては、制限は有りません。
・ 言語仕様は、根幹が完全にＣ言語なので、変換フィルタと、ライブラリを整備すれば、Inprise Borland C++ Builder や Microsoft Visual C++ でコンパイル可能な筈です。ただ、手間が掛かるので、作るかどうかは謎です (作ってもシェアウェア)。
・ 実際、インタプリタエンジンが、余りにもシンプルなので、コンパイラは、マシン語一歩手前程度迄、展開を行います。この為、コードの品質さえ考えなければ、x86 (IA32) ネイティブコードへの変換も比較的単純に実現可能だろうとは思います。作業自体は、大変なので、やる気は有りませんが (^^;; 。
Parent.