AB開発日記

CheckDifferentType関数を新たに設けました。この関数、コンパイラ内部で、以下のようなタイミングで呼ばれる便利な関数です。

・変数にデータを格納するとき

・関数にパラメータを引き渡すとき

呼び出されると、双方（右辺、左辺）の型の整合性を判断します。型が異なると判断された場合は、「強制変換されますよ〜、キャストしてください」みたいな警告を発します。更に、Char型変数にLong型データを代入したときなど、自身の型が持ち合わせるデータ領域よりも大きな領域を持ち合わせる型の代入に遭遇すると、「データが失われちゃいますよ〜」という親切な警告も発するようになっています。

我ながら、迅速行動でした。最初は久々に触るコンパイラの中枢部にタジタジだったのですが、プログラミングのカンを取り戻せたような一日でした。こういう、プログラミングに関するちょっとした壁を乗り越えたときの満足感は何者にも変えがたいものですね。

中枢部を改良したということで、色々と不具合がでるかもしれません。まとまり次第、Ver4.1β1としてリリースしようと思います。そうだっ、ヘルプを書かねばっっっ（式の中で “As 〜” が使えるのよ〜ん♪）

もうすぐお盆になりそうな今日この頃…ジョニー先輩とのどうでもいい会話です。

ジョニー先輩「山ちゃん、大学４年の夏ってのは、過ぎるのがめちゃくちゃ早いよ。ホントにあっという間だよ。”あっ” て言ってみろよ」

おいら「あっ」

ジョニー先輩「クリスマスになったら、”という間だったろ！” って言ってやるよ」

もう暑いのだけはマジ勘弁なのですが、こんな時期もすぐに過ぎてしまうものだと思うと、ちょっとシンミリとしてしまいます。ウチの店にも秋物が本格的に投入され、そのスピードは加速されたようにも感じます。

レゲエを思いっきり楽しめるのもあと一ヶ月ちょっとといったとこでしょうか。音楽のほうも秋物を仕入れにゃなませんね。2005年秋は大人っぽく、ジャズでせめたいところ。ジャズといっても、クラシックジャズ、サックスジャズ、ジャズボーカルなどがあるのですが、最近のポップスに近い、入り易そうなSMOOTH JAZZの領域に踏み込んでいきたいと思っています。

今から従兄弟とCDショップ行ってくるんで、今のウチにゲトります(^^

今日は夕方から家業の配達の手伝いがあるので、それまでは開発を進めます。

まずは、問題にあがっているキャストの問題。すぐにキャスト可能な仕様に改良することはできないので、ことはじめとしてコンパイラの演算コード生成部をすべての型に対応させるところから始めます。今まではコード軽量のため、一定の型（Double/Single/Int64/QWord/DWord/Long）のみに制御を絞っていたのですが、今後はInteger/Word/Char/Byte及びその他ポインタ型の識別も可能にしていかなければなりません。

中核部分をいじるのは数ヶ月ぶりなので、ちょっと不安なんですよ(–;;;。コンパイラを製作したことがある方ならわかると思うのですが、コンパイラを記述しているプログラムコードっていうのは、対象となる言語仕様が複雑になればなるほど難解になっていくんです。ABは、仕様を追加しまくる方向できているので、例外事例にムリヤリ対処するためのコードが目立つんですよね（汗）。

まぁ、そういうこともありまして、マイペースに作業を進めているところです。お昼の段階で、演算コード抽出ルーチンで対応できる型を基本型すべてに拡張したところです。今後は型識別コードでは表現しきれない付加識別コードに対応させていきます。

型識別コードとは？

・Char/Byte/Integer/Word/Long/DWord/Int64/QWord/Single/Double

・文字列型

・オブジェクト型

・列挙型

・基本型のポインタ型

・オブジェクトポインタ型

・関数ポインタ型

これらの型を識別すめためのID番号。コンパイラ内部で使用されるため、一般のプログラマーは意識する必要はないっす。

付加識別コード

オブジェクト型、列挙型、オブジェクトポインタ型、関数ポインタ型など、1つの型識別コードだけでは表現できない識別情報を持ち合わせます。

例えば、オブジェクト型、オブジェクトポインタ型の付加識別コードには、クラスを指し示すID番号が振り分けられます。

この文章、読み返してみたら、暗号のようなものになっていますね。コンパイラを作る過程での悩みが相談できる人（かなり特殊なケース！？）ってのは幸せです。おいらはいつも一人ぼっちですから…。

キャストの問題が出てきてから色々と考えているのですが、ABの演算部分がかなり簡略化された構造になっとることを再確認させられました。こいつはおいらが1人でABを開発することから、コードの軽量化とその内容のわかりやすさを重視した上でのことであり、言語仕様としては劣る部分でもあります。そこらへんの甘さが、キャストの甘さに繋がっているんですね。

コンパイラの内部構造の話になってしまいますが、ABコンパイラを製作する上で、与えられたBasicの式コードをもとにアセンブラの演算コードを抽出するルーチンがあります。このルーチン、字句解析はもちろんのこと、すべての演算子とすべての型を熟知したものでなければなりません。構造自体はスタックを活用したシンプルなものではあるのですが、扱う演算及び型の種類は日々、多くなっています。この演算と型、掛け算方式で肥大化していくのです。

いわれてもれば、一つの演算をアセンブラコードに変換するためには、右辺、左辺がどのような型なのか、双方の型が違う場合は、どちらの型を優先して演算を行うべきか。足し算だけを見ても、実数演算と整数演算で使用する機械語コードは違うんですね。実数演算ではDouble型とSingle型があるので、2通りに対応するものを作る必要がありますし、整数演算では符号有り無しの考慮、Integer、Word、Char、Byteなど、ビット数が少ないものも考慮しなければなりません。

まだ基本型ならばいいのですが、ポインタ型になるとまたちょっとややこしくなります。ややこしくなる原因はオブジェクトポインタを扱ったときです。AB内部で型を識別するための型コードだけでは、オブジェクトポインタの種類を見分けることはできないからです（オブジェクトポインタはクラスの数だけ存在することになりますから…）。となると、「オブジェクトポインタ」という一つの型コードと、別途クラスコードを管理する必要がでてくるというわけです。

この演算抽出のルーチン、コンパイラ内部のあちらこちらから呼び出されるので、オブジェクトポインタを考慮したものに書き換えるというと大きな作業になってしまうんですね。

こういう問題を抱えつつですが、近日中にキャストの問題をクリアしてより繊細な演算ができるような仕様に拡張していきたいと思います。ウーン、「次回のバージョンアップで…」というのはちと難しいかもしれません。少なくとも、Ver4.1あたりで対応させたいところです(><)

旅慣れしていない山本家を8月末に襲うのは、軽井沢貸し別荘（3日間だけ）移住計画です。こういうのをやったことがないんで、下見が必要だろうということで、従兄弟とその子供を引き連れて下見に行ってきましよ。

片道250km程度、「どうでしょうサイコロの旅」並みのこの計画…時間どおりにことが進むか、ちょっと心配です。出発地は静岡市、駿府公園付近。目的地は中軽井沢駅のすぐ近くのパークコテージになります。

行きは、富士山を見ながらR139号を北上します。←こいつはいつものお決まりルートといったところでしょうか…、牧場あり、公園ありの超定番観光道路ですね☆

精進湖を抜けて中央道へ。せっかくなので、諏訪南I.C.で降りて八ヶ岳で昼食をとることにします。本日のレストランはおいらが過去に一度だけ行ったことのある、超オシャレなところなんです。

その名も、廃材王国「カナディアンファーム」。森の中に外国風チックな木造の建物があり、木々に囲まれながらステーキを食べるというメチャクチャ贅沢なセッティングがたまらないんです(><)。おいらは2回目ながら、カナディアンファームのとりこになってしまいました。もうリピーターと言わせていただくしかないですf(^^;;;

カナディアンファーム:

http://canadianfarm.hp.infoseek.co.jp/

昼食で金と時間を使いすぎてしまったので、あとは軽井沢へ向けてドライブ×ドライブです。R152号を北上後、R141号へ出て軽井沢へと近づきます。

2時間後、なんとか中軽井沢駅周辺に辿り着いたのはいいんですけどねぇ〜、渋滞がですねぇ〜、発生しているんですねぇ〜

中軽井沢駅周辺。アウトレットとか、巨大ショッピングセンターがあるのもここらです。多分、都心から「夏は軽井沢で…」とはしゃぐ連中（まぁ、おいらの家族もそうなんですけど）が列を連ねているんだろうと思います。

山本家が予約しているパークコテージの看板を探しますが、なかなか見つかりません。ついに発見できぬまま、軽井沢を過ぎて群馬県へと突入してしまいました。また渋滞へ戻るのもイヤなんで、R18バイパスを駆使してパークコテージ周辺道路へ戻ります。←ナビに頼らない、我ながらいい判断です（方向感覚×自信過剰）。この後結局、周辺道路を歩いていた見ず知らずのオッサンに場所を聞いたのでしたf(^^;;;

パークコテージへの道順を押さえるという最大の目的が達成できたところで帰り道へと進みます。後はひたすら静岡へ向かって走るだけ。後部座席のお2人は熟睡モード全開だったので、おいらは寂しく、1人ドライブを楽しみながらっつー感じでした。

今年初めてのバーベキューをやってしまいました(*^o^*)。集まったのはバイト仲間、総勢16人！ウチの裏庭の草を刈りまくって、バーベキュースペースを確保するところから始まったこの企画。昼間から若い男連中の協力を集います。

これはメチャクチャ暑〜い中、汗水たらしながら草刈をした後の様子です。大の字になっとるのはお決まりのジョニー先輩。このお方はこの直後全裸になったかと思えば、風呂へ入っていったのでした…。

庭がキレイになったところで、昼酒をやってからバーベキューの下準備を始めます。今回のバーベキューは七輪を使うとのことで、準備はとっても簡単。七輪をセッティング後、スミに火をおこすだけです。あとは定期的にスミを追加していくだけ。これで一日中バーベキューができてしまうというワケです。昼間組（草刈＆準備組）は5人だけだったので、さっそく昼酒バーベキューを始めますf(^^;;;

これは、もう日が落ちてからの様子。室内の明りを全開にして庭を照らしています。ウチに来てくれたお客全員にはバーベキュー＆室内飲み会を楽しんでもらったのですが、クライマックスはなんといってもは花火でしょう。

最初は手持ち花火から始まったのですが、行為はどんどんエスカレート。噴射花火から打ち上げ花火へと…、花火男や花火の上にジャンプしちゃうのまで、とにかく盛り上がりました。最後は線香花火、誰が一番持続できるか大会などなど、「夏」そのものを見れたので、おいら的にはもう大満足です☆

まだまだ夏は長いです。こういうの、もう一発くらいやりたいっすわ

型チェックの甘さが問題になっていることについて、考えをまとめてみます。

元々、Basic言語というヤツはタイプチェックしてないっぽいですよね(–;;;。あったとしても、数値型と文字列型の判別くらいでしょうか…。

10 a=”1″

20 b=2

30 c=a+b

40 Print c ‘3と表示される

元祖Basicでは、上記のようなプログラムが平気で実行できてしまいます。インタプリタBasicでは変数管理がどのようになされていたのか、わからない部分ではありますが、ネイティブコンパイラのそれと比べて柔軟な自動タイプキャストがなされていたことは事実なようです。

で、そういう風潮を受けつつ開発を進めたABなんで、型チェックの甘さがあって当然なんですね〜。元々の言語仕様に「タイプキャスト」という概念が無いんですから。

さてさて、コミュニティフォーラムのほうで話題になったのは、「Long型変数へBytePtr型データを代入するとエラーになるが、パラメータ引き渡し時にはエラーにならない」という問題です。

実はこいつ、結構厄介な問題なんです。一見すると、Long型にポインタ型を強制的に代入しようとしているんだから、ネイティブコンパイラとしてのABではエラーになって当然なのですが、Win32APIとの連携・柔軟性を考えると100%そうともいえないのです。SetWindowLong関数を例にあげて説明してみましょうか…

Declare Function SetWindowLong Lib “user32” Alias “SetWindowLongA” _

(hWnd As HWND, _

nIndex As Long, _

NewLong As Long) As Long

Win32APIの一つであるSetWindowLong関数、第3パラメータ、NewLongというパラメータに注目してみてください。こいつはLong型であることがわかるのですが、ヘルプでは「32 ビット整数値」と記されているんです。32ビット整数値…Win32上で作動するWindows環境では、これに当てはまる値は沢山あるはずです。Long型、DWord型はもちろんのこと、ハンドル、ポインタ、RGB値と、色々挙げることができます。

• GWL_EXSTYLE 拡張ウィンドウスタイルを変更します。
• GWL_STYLE ウィンドウスタイルを変更します。
• GWL_WNDPROC ウィンドウプロシージャのアドレス、またはウィンドウプロシージャのアドレスを示すハンドルを変更します。
• GWL_HINSTANCE アプリケーションのインスタンスハンドルを変更します。
• GWL_ID ウィンドウの ID を変更します。
• GWL_USERDATA ウィンドウに関連付けられたアプリケーション定義の 32 ビット値を変更します。

こういう具合にNewLongには、ウィンドウスタイル（Long型）、ハンドル（DWord型）、プロシージャアドレス（ポインタ型）を指定することになるのですが、肝心のAB Ver4.0にはタイプキャストをユーザーが任意で行える環境が備わっていないんです。となると、ある程度のタイプキャストは自動的に行ってユーザーの負担を減らすというのが自然な流れになり、Win32API呼び出し（関数呼び出し）に限り、タイプキャスト（特にLong型へポインタを…）が甘くなってくるんです。

しかしABには、C/C++、Delphiなどの高級コンパイラ言語に対抗するだけの仕様を持たせたいって願いもあるんですよね。長いことABユーザーをやられている方、またはABウォッチャーの方は私がそういう姿勢でコンパイラ製作に取り組んでいることは薄々感ずいていることと思います。

仕様がなければ、追加すればいい。これにつきます。

しかし、過去のプログラム資産（Ver3.x、Ver4.04.00までに製作されたソースコード）を無効にしてしまうような仕様変更はできないので、注意して取り組まなければなりません。

原案として、#strictディレクティブを再出現させようか検討中です。これを導入したら、CDbl、CSng、CIntなどのタイプキャスト関数をコンパイラに組み込んで演算過程で評価していかなくちゃなりません。

実は、#strictってVer2.xのときにあったんです。覚えてる方、いますでしょうか？？当時は暗黙の宣言を禁止する目的で指定するディレクティブだったのですが、Ver3.0から消え去ったので、型チェックを厳密に行うための識別子として利用しようってことです。←またまたC/C++みたいって言われちゃいそうですけど(^^;;;

今日は、実家静岡で色々とすることがあるんで、そいつをこなして、午後は大掃除タイムに入ります。というのも、明日はバイト仲間で七輪バーベキューをやる日。当然、おいらのウチが会場となるワケです。人数が意外と多いため、おいらの部屋と庭と、掃除をしなくちゃあなりません。

山ちゃんちでパソコンやらせてよ、という（？）な要望も出ているんで、今日はディスプレイ裏の埃取りなど、普段は手をつけないようなところもやってやろうと思います。掃除は苦手なんすよ…しぁーねぇー（￣Д￣）

今朝、DiscoversoftのWebサイトに接続してみると、「サーバーがみつかりません」エラーが(*д*)

アクセスログを見てみると、どうやら午前3時〜午前9時までの5〜6時間、サーバーが停止していたようです。深夜、早朝というアクセスが低い時間帯ではありますが、長時間に渡っての停止状態はちと痛いです(><)。

こういう場合は、XREAのサーバー障害掲示板にでも書き込んでやったほうがよさそうですね。暑い日でダウンするのは、サーバーも同じだったり…

しっかりとした発表をしていないんで、この場で皆さんに報告しておきます。実は以前から、ひっそりと未踏ユースへの応募をしておりましたが、このたび採択されることが決定しました。

未踏ユース公募結果:

http://www.ipa.go.jp/jinzai/esp/2005youth/koubokekka.html

題目は、統合開発環境「ActiveBasic」の開発及びサポート。64ビットコンパイラの開発がメインになり、同時処理としてVer4.0の環境充実を行うのが当面の目標になります。将来を見据えた開発と共に、今現在必要となるユーザーサポートを積極的に行うといったところでしょうか…。

てなことで、ActiveBasic Ver5.0へ向けた予定を公式発表したわけですが、本当にことがうまく運ぶのか、少し心配です。まずは64ビットコンパイラの製作。大まかな開発スケジュールは、下のようになりそうです。

・64ビットCPUを積んだPCを購入

↓

・EXEのヘッダ部分を解析

↓

・シンプルな64ビット対応機械語プログラムの実行テストを行う

↓

・関数呼び出し、変数処理、演算処理などの基本コードを64ビットに対応させる

↓

・64ビットコード生成に完全対応するコンパイラを製作する

↓

・Win64に対応するライブラリを提供する

ライブラリ製作の部分は、是非とも探究心のあるユーザーさんと共に行いたいものです。興味のある方、コンタクト願います。←とはいっても、まだまだ先の話になりますけど（焦