Sponsored Link

« 2007年02月 | メイン | 2007年11月 »

2007年10月31日

MMX 0.03a 正式リリース間近

MMX "THE BASIC" 0.03a の正式リリース前の最終チェックで、同一行番号による、プログラムバッファーの書き換えが出来なくなっていた問題、および、同一行番号空打ちによるプログラムバッファーからの行の削除が機能しなくなっていた問題は、単にエラーチェックの為に挿入したコードにミスがあっただけだった。現時点で上記二つの機能はほぼ正常に機能しているが、マイナーなバグが一件ある。マイナーと言っても MMX がフリーズしてしまうので、現象としては深刻なのであるが、恐らくつまらないバグだ。本日中に MMX "THE BASIC" Version 0.03a の正式リリースを目指したい。マイナーバグが取れ次第、次のバージョン、Versoin 0.03b のコーディングに入るつもりだ。Version 0.03b で実装される機能は以下の機能を予定している。

  1. プログラム命令 "GOTO" および "REM" の実装。
  2. Version 0.03a では、プログラム実行中にエラーが起きてもエラーメッセージを返すだけで、実行を停止しない。これを実行停止にし、エラーメッセージにはエラーが起きた行番号を表示する。

……。MMX "THE BASIC" がフリーズしてしまう原因は僕の書いたプログラムコードではなく、どうやら Microsof Windows XP SP2 の致命的バグの様だ。事実、コマンドプロンプトから edie.exe を実行し、全く同じ手順でプログラムのコーディングをし、RUN して、全く問題ないときと、手順が全く同じにもかかわらずフリーズしてしまうことがある。なんて、滅茶苦茶な OS なんだ。Mircosoft のプログラム作成技術は世界最低水準である。まして、OS を作ろうなんて、おこがましいにも程がある!(怒) おのれの浅はかさを知れ! アフォ共!!(激)

さて、後一押しである。まだ、マイナーバグがあり、プログラムバッファーの先頭行を書き換えようとすると、プログラムバッファーが空になる現象がある。これをクリアすれば、Version 0.03a の正式リリースが可能になるだろう。

Version 0.03a の正式リリースに向け最終段階である。現時点で判っている、既知の問題点は:

  1. Mirosoft Windows XP SP2 の不具合により、edit.exe がフリーズすることがある。
  2. Microsoft Windows XP SP2 の不具合により、edit.exe は全く問題がないにかかわらず、"Flotion exception: Inexact" エラーで edit.exe が強制終了することがある。
  3. Microsoft Windows XP SP2 の不具合により fgets の文字列制限機能が正常機能しない。これは、回避策として、edit.c の中で対策版 my_fgets を作ってコードは完璧にもかかわらず、正常動作しなかった。明らかに Microsoft Widows の致命的バグである。
  4. Microsoft Windows SP2 の不具合により、プログラムバッファーの先頭行の書き換えが出来ない。具体的には先頭行の書き換えを行うとプログラムバッファーが空になる。edit.c では、論理的にいかなる行の書き換えを行ってもプログラムバッファーの行数は変わらないので、明らかに Microsoft Windows の致命的バグである。この対策として、繰り上げて "REM" 命令文の実装を行った。使用するにあたってプログラムコードの最初の行を "REM" 命令文にしておくことを推奨する。
  5. 行番号空打ちによるプログラムバッファーからの行の削除は最終行でしか機能しない。edit.c のプログラムコード上は何の問題もないにもかかわらず、途中行の削除をしようとすると、edit.exe がフリーズする。これも Microsoft Windows XP SP2 の致命的バグの可能性が高い。現時点で断定する訳ではないが、論理的につじつまが合わなく、OS 側の不具合によるものと考える。このままでは正式リリース出来ないので、途中行の空打ちをすると "Internal Error" とエラーを返し、コマンドプロンプトに戻る仕様にした。この苦肉の策の結果、存在しない途中行の空打ちも同じエラーでコマンドプロンプトに戻る仕様になってしまう。行の削除を行うのにあたっては、最終行番号を正確に入力する様、注意を喚起する。

では、正式な MMX "THE BASIC" Version 0.03a のバイナリリリースを行う:

MMX "THE BASIC" Version 0.03a
http://rose7.s143.xrea.com/mmx/edit003a.zip

2007年10月28日

MMX "THE BASIC" Version 0.3a

MMX "THE BASIC" Version 0.03a のリリースのめどが立った。

最後のバグであった「プログラムの最終行番号より小さい値のプログラム中に存在しない行番号を空打ちした場合、プログラムバッファーの状態がおかしくなる」と言う Version 0.03a のリリースにあたっての事実上の最後のバグがフィックスされたのだ。現在、MMX Version 0.3a は機能的には何も問題がないが、マイナーなバグを1件抱えている、それは上に挙げたプログラムコードの間の存在しない行番号を空打ちした場合、環境命令「LIST」でバグフィックス用のビープ音が鳴ってしまうのだ。これのマイナーバグがフィックスされれば今日中にも MMX "THE BASIC" Version 0.03a がリリースされる予定である。なお、Version 0.04a からは、実行ファイル名は "mmx1.exe" とする予定である。

……煮詰まっているついでに、Version 0.03a に「PRINT」命令の引数として "HELLO" の様な文字列を受け付ける様にした。現状では:


10 PRINT "HELLO"
20 LET A = 3.141592
30 PRINT A
40 END

とすると:

OK
RUN
HELLO"
3.14159
OK

と「"」が付いてしまう不具合があるが、Version 0.03a で予定を繰り上げて PRINT "A = "; と言った「;」により改行をしない PRINT 命令まで実装する予定にする。

……取りあえず、PRINT 命令で "HELLO" と言った文字列を「HELLO」と出力するコーディングは終わった。「;」の機能はまだである。また、これは MMX "THE BASIC" の仕様にしようと思うのだが、数値演算は LET 命令の中だけで行われることにしようと思う。つまり "PRINT 1 + 2" と言ったコーディングは認めない、と言うことだ。しかし、実使用上は何の不具合もないはずである。仕様としてほとんど決定である。

さてさて、PRINT 命令の文字列出力の「;」機能も終わった。ただし、まだ変数の出力に「;」機能はなく、また、文字列の場合であっても「"」、「"」で括られる部分に空白、Tab は存在してはならない。これは構文解析に sscanf を使っている現状から来る物である。

……例の、マイナーバグであるが、気がついてみれば何でもない。存在しない途中行番号の空打ちをすると、プログラムバッファーの最後のプログラム行の次のバッファーに "\0" を書き込んでしまい、それがバグとして誤解されていた。本来正常動作である。まだ、細かな点のエラー防止措置を執る必要があるが、今日中の Version 0.03a のリリースは確定的である。

……リリースかと最終チェックをしていたら、同一行番号のプログラムコードの書き換えが出来なくなっていた。最低である。そこの周りのコードはいじっていないし、正常に機能することは確認出来ていたのだが。摩訶不思議である。

でも、「仕方ないだろう?!」。だって、だって、fgets にバグありの LSI C-86 に「メモ帳」だけでコーディングしているのだから。こんなプアな開発環境でコーディングしている奴そんなに多くは居ないぞ?! ま、リリース前に Version 0.03a の注意事項を上げておく:

  1. 入力行は改行('\n')、終端文字('\0')を含めて80文字以下でないと正常動作を保証しない。
  2. 環境コマンド、プログラムコマンド共に大文字でないと受け付けない。
  3. PRINT 命令で使用する「"」、「"」で括られた文字列は、いかなる空白(Tab を含む。)、ダブルクォーテーション(「"」。構文解析に sscanf を使用している現状では、エラーにならず、そのまま出力されるが、本来、エラーである。)も含んではならない。また、改行を無効にする「;」は「"」、「"」で括られた文字列の直後にいかなる文字も置いてはならない。文字列終端の「"」の直ぐ直後に「;」が来なくてはならない。また、変数のプリントに置いては「;」は使用出来ない。
  4. 現時点での実行ファイルのサイズは約 17.4KB である。MMX "THE BASIC" のフルインプリメンテーション(デュアルモードなし)は 32KB 以下にするつもりである。

しかし、僕が企業で CD-ROM ドライブのファームウェアの開発をしたとき今の体調があれば、アセンブラーで書かれた、つまり隠れたバグが必然的につきまとったファームウェアを CD-R チームが C 言語で書いた無駄に贅沢な太り肥えたファームウェアではなく、非常に軽いコーディングで、マスク・ロム化に耐える非常に軽くてエレガントな C 言語のファームウェアに置き換えられた物を。CPU は HITACHI H8 を使っていて、日立から派遣出来たアフォなエンジニアが「C 言語で 32KB 以下なんて無理ですよ!」なんて馬鹿なこと言っていたが、何が「派遣の品格」だ! お前、本当に馬鹿だったなあ! HITACHI はメカ屋や電気屋は凄いんだけれどねえ。でも、基本的に鈍くさいぞ、日立。CD-ROM ドライブが過当競争になった後から市場に参入してきて凄いメカの CD-ROM ドライブ作ってきたけれど、あれじゃあ、かなりの赤字だったはずだ。もったいない。

しかし、まだ午後の十時をまわったばかりなのに嫌に眠たいぞ?! 目が眠たいときののび太の目をしている(笑)。「私には行かなければならない所があるのです! お前達! 失礼ではありませんか! お父様! お父様にだって私を自由にする権利はないわ! 私には、私の道を選ぶ権利があります!!」、「いっかーん!!!(バチッ!!)」、ってガルマ・ザビの愛人、イゼリナ・フォン・ローエンバッファか!(爆)

……ところで、僕はカフェスタのホームページに「N - Mobilis In Mobili」と書いてある通り、ジューヌ・ベルヌ著「海底二万海里」(ここで言う「海里」とは現在の "Sea Mile" とは違い、古いフランスの航海単位である「リュー」である。"Sea Mile" の約2倍。)を愛読し、潜水艦が大好きなのであるが、実際に好きなのは第二次世界大戦の大日本帝国海軍の零式水艇を積んだ伊号潜水艦である。次点でナチス・ドイツのU−ボート。基本的に「潜水艦」と言うより「可潜艇」であり、船団や、敵軍艦を攻撃するときには夜の闇に置いて浮上し、伊号潜水艦の場合は零式水艇を飛ばし敵軍艦の位置を索敵し、九五式酸素魚雷でこれを撃沈する。

……目を覚ますために「機動戦士ガンダム III 特別版」でも観るか。更新はその後で。じゃ、また。

って、「機動戦士ガンダム III 特別版」を観るだけにとどまらず、NINTENDO DS Lite で色々なゲームをやったり、挙げ句の果てはショートムービーまで作った。ショートムービーのテーマは「エロス」であって、監督兼脚本兼主演女優兼撮影監督を一人でこなした(爆)。俳優が僕一人のそして僕は主演女優(男言葉を使っているが俺の本当の性別が「女」であること位知っているだろう?(苦笑))を演じ、艶っぽい声出しながらあんなことやこんなことをしている「エロス」のショートムービーだ(爆)。撮った後で自分で観てあまりのエロスさに鼻血ブー! 高木ブー!!(爆笑) いやいや、面目ないねえ。でも、事実上のAV女優(あれ観れば誰だって本物の女が性行為をしながら淫らな喘ぎ声出しまくっていると思うさ(苦笑))。俳優が一人、主演女優の僕しか居ないのに後二人ぐらい男優がいる様に見える典型的なアダルトビデオだよ、あれは完璧に。いやいやいや、すまん、すまん、こんなことやあんなことしている暇ではなかったよねえ?! でも、「私女だもん! H好きだよ! 女なんだから当然でしょう?!」と、ここではきっぱりと言い切っておく(爆)。

罪滅ぼしに僕の肉声を公開しよう。……ただし、ヴォーカル上のあるテクニックを発見し、女性の声に聞こえるメッセージである(爆)。もっと音程を上げられるのだが、英語で発声しているため地声が低い欧米の女性水準のピッチに合わせてある:

"Hello! Nice to meet you. My name is Ayase Kiyokawa."

本場米国のハッカー達が聴けば完全に女の声に聞こえるだろう? ハックするのはプログラムのコードだけではないのだよ。ファック("FAQ")するのもプログラムのコードなのだよ!!(冷や汗) ちなみに本来の地声は1オクターブは低いぞ?!

2007年10月25日

ギタリストの夜

3rd Guitar Black Magic

3rd Guitar "Black Magic"

さて、珍しく、「謎のギター弾き」らしいことをしている。

ギターで遊んでいるのであるが、使用しているギターは僕の三本目のギター「Black Magic」である。これは、フェルナンデスの ZO-3 のブラックをフルゴールドアッセンブリー化した物だ。ピックアップはギブソンの物を使用している。本来、ストリート向けに開発された。

遊んでいて、「エリーゼのために」を弾き損なったのが切っ掛けで、某アーティストの曲のイントロのフレーズのフィンガリングが判った。いや〜、某アーティストは僕の中でも一つの重要な位置を占めているが、実に巧いフィンガリングのリフだねえ。

DEAD_LINK_http://rose7.s143.xrea.com/s/rs001.mp3

次は、リッチー・ブラックモアによるロック史上に永遠に残る Deep Purple の Smoke On The Water のリフである。このリフはバレーの F が弾けない超初心者でも形だけは弾けるが、このリフの肝はブリッジミュートである。僕自身完全にマスターしたとは言えないがそこそこのクオリティーの物がレコーディング出来たので参考までにアップしておく:

DEAD_LINK_http://rose7.s143.xrea.com/s/dp_sw001.mp3

このホームページの容量は少ないのでサンプルをギリギリまで削ったら、うっかり第一音のアタックが入ってなく、第一音の途中から始まるのでご了承をお願いする。

しかし、ドラムも叩きたくなったなあ。ドラマーでの僕のヒーローはジェフ・ポーカロである。パールのドラムスティックでジェフ・ポーカロのシグネーチャーモデルがまだ売ってないかなあ? ドラムを叩くのは別に(外の)スタジオでも良いのだけれど、やっぱり自分で欲しい。取りあえずは、ハイハットとハイハットスタンドか。使うのはジルジャンのハイハットだなあ。こればっかりはライン録りでレコーディングは無理なので SHURE のマイクとマイクスタンドもいるなあ。でも、是非欲しいぞ!!

さて、今夜の出演はジョニー・B・グッドでした:

DEAD_LINK_http://rose7.s143.xrea.com/s/cb_jbg001.mp3

2007年10月24日

オブジェクト指向言語に関する雑記

今現在、オブジェクト指向言語と言えば C++ や Java と言った風潮があるが、僕はこれには異を唱えたい。

C++ は、オブジェクト指向の非常にまずい実装形式を取った言語であって実使用に耐えないし、言語単体ではオブジェクト指向環境とは全く呼べない。Java も同然である。その証拠に、Java 自信、Java 1 でオブジェクト指向環境(「環境」とは正確には呼べないが。)のデザインに失敗し、Java 2 を新たに作らなくてはならなかった胡散臭さである。Java 2 だってどれほど実使用に耐える物かは限りなく疑問だ。

僕が知る限り一番堅そうなオブジェクト指向言語は Common LISP だ。これが、正式に標準化された初のオブジェクト指向言語&環境と言うから、C++ の言語設計者や、JAVA の設計者は何馬鹿なことをやっていたのかと思う。

僕は GNU Emacs LISP しかいじったことがないから断定出来ないが、その経験から Common LISP はボトムアップでオブジェクト指向プログラムを作れる可能性のある言語だ。

ただし、"LISP" と言うと括弧の嵐だ。少なくとも「メモ帳」でコーディングするのはきついかも知れない。

比較的 C に近くて使い物になりそうな言語は Objective-C だ。僕は全く言語仕様に目を通してなかったが、ウィキペディアを見る限りじゃ、使えそうな言語だ。うんうん、参考に載っているソースコードを観たが、良い意味でのオブジェクト指向の匂いがぷんぷんしてくる。

そもそも、Objective-C があるのに、C++ なんて言う全く使えない言語がスタンダードになってしまったのは何かの間違いなのだ。C++ の言語設計者のデザインセンスの犯罪的な悪さはマイクロソフトに次ぐ勢いである。こんな言語、とっととなくなれ! C++!!

……さて、話は、Common LISP と Objective-C に絞るとする。

それぞれの特徴、利点、欠点は:

Common LISP
  1. 僕自身が GNU Emacs LISP を通して LISP の特性をそれなりに知っている。
  2. 括弧("(", ")")で囲まれた物ならどんな小単位でも直ちに実行可能である。C 言語の派生である Objective-C は C 言語でそうである様に printf("Hello, world.\n"); とだけ書かれたソースファイルを実行出来ない。
  3. 括弧を多用するためそれなりのプログラム馬鹿でないとコーディング出来ない。

Objective-C

  1. 僕自身が C 言語の達人であって、オブジェクト指向拡張部分さえマスターすれば直ぐにでも使いこなせる。
  2. 上と重なるが、C 言語の中級以上のマスターには一番入門しやすいオブジェクト指向言語である。
  3. ターゲットプラットフォームの API をハンドリング出来れば、C で直接書くより、手間数が少なく、それだけ大きなプログラムを容易に作成可能である。個人的には GNUWin から gcc が出れば、直ぐにでも Windows 向けのグラフィックを多用したアプリケーションを作りたい気分である。

まあ、ここまで書くと、僕が自ら「ボトムアップ式オブジェクト指向言語&環境」を作るなら BASIC を元にするだろう。Visual BASIC .NET などオブジェクト指向言語でもないし、使うものにバグと苦役のみ与える開発ソフトである。何千人のプログラマーが Visual BASIC .NET に泣かされ、無意味なエンジニア生活を送っているかと思うと気の毒でならない。

僕が、BASIC をオブジェクト指向に拡張するなら、呼称に "MMX" は使えない。少なくとも今のところは。使うとしたら Objective-BASIC と言う呼称になるだろう。

オブジェクト指向言語を作るときに、「クラス("class")」、「メソッド("method")」、「インスタンス("instance")」と言う概念は必ず必要になってくる。「クラス("class")」と「メソッド("method")」を僕流に厳密に定義すれば、「クラス("class")」とは「インスタンス("instance"。実行時オブジェクト。)」の「定義」であり、「メソッド("method")」とは、それが所属するクラスの直系の「インスタンス("instance")」に対するメッセージパッシングによって呼び出される「関数」の「定義」である。短く言えば「メソッド("method")」と偉そうに言っているが、所詮「関数」の定義に過ぎない。

ウィキペディアをあたったが、いわゆる一般にオブジェクト指向を語るときの「メソッド("method")」とは、厳密に言うと、「インスタンスメソッド("instance method")」と言う。僕に言わせれば、「メソッド("method")」と略するのは、ゲイツが作った BASIC が "LET" 文を必要としないようにしてしまったという程のアホさ加減である。「インスタンスメソッド("instance method")」と略さないで呼ぶ方がオブジェクト指向の学習にどれだけメリットがあるか計り知れない。ちなみに対義語として「クラスメソッド("class method")」があるが、これは、インスタンスが内部的に使う単なる関数である。

Ovjective-C のクラスの定義法を観たが、さすが SmallTalk を参考にしただけあって、C++ とは別次元の判りやすさである。

一般的に、クラスは次の様に定義する:

// class difinition
@interface MyObject : NSObject {
  int val;
  :id obj;
}
+ (void)classMethod: (id) arg;    // class method
- (id)method:(NSObject*)arg1 with: (int) arg2;    // instance method
@end

ちょっと、Movable Type の表示領域の問題で、コメントの "// instance method" がオーバーラップし、あたかも "method" と言うのがクラスの定義に関係していると勘違いしそうになるから注意して。

いや、実に美しいクラスの定義だねえ。誰が読んだって "NSObject" と言うのは、今回定義するクラス "MyObject" の「親クラス("parent class")」。"int val" は、"val" が "int" 型の「インスタンス変数("instance variable")」と言う定義。"id obj" は、お初だが、"id" は、インスタンス自身を一意に識別する "IDentification" の略の筈。つまり、"obj" にインスタンスを一意に識別する符号が入る。間違いないでしょう?
次はメソッドの定義だ。"+" と "-" の違いはさすがに仕様書を読まないと判らない。最初のクラスメソッドの定義は、露骨に "classMethod" と書いてあるから誰にでも判る。返値の型は "void"。このクラスメソッドを呼び出す形式として、"(id)"、つまりインスタンスの一意識別子が来て、"arg" はクラスメソッド名の筈。コードを読む限り、インスタンスメソッドや内部関数(クラスメソッド)への引数は "with:" で指定していると見た方が良いだろう。つまり、最初のクラスメソッドは引数を取らず、返値も返さない。恐らく、インスタンス変数等の初期化関数(後付注釈: 初期化関数ではなかった。単に引数を取らず、返値も返さない内部関数だった。)。次に来るインスタンスメソッドの定義。"(id)method:と言うことは、返値の型は "id"。これはインスタンス自身の一意識別子。ここまで来れば、それがインスタンスへのポインタであると予想出来る。次の "(NSObject *)arg1" も至って簡単、この項へはインスタンスへのポインタが入るはずだから、"(NSObject *)" で親のクラスにキャストして、"MyObject" 内でこのインスタンスメソッドを親クラスのインスタンスメソッドにオーバーライドする。とすると、"+" は、定義したクラス固有のクラスメソッド、インスタンスメソッドを表し、"-" は、親クラスのクラスメソッド、インスタンスメソッドのオーバーライドを表す。で、このインスタンスメソッドの引数は "with: (int) arg2" だから、引数の型は "int"。最後の "@end" でクラスの定義を終了している。実に判りやすい。

本当に良くできたプログラム言語は仕様書無しでも分かる奴なら直ぐ分かる。そして、こんな良い物は Objective-BASIC に利用すべきだ。Objective-BASIC でのクラス定義は以下の様な物を想定する:

REM CLASS DIFINITION
@INTERFACE MYOBJECT : NSOBJECT [
  INT VAL
  ID OBJ
]
REM CLASS METHOD
+ (VOID)CLASSMETHOD: (ID) ARG
REM INSTANCE METHOD
- (ID)METHOD: (NSOBJECT)ARG1 WITH: (INT)ARG2
@END

そして、クラスメソッド、インスタンスメソッドの定義は以下の様に行う:

@IMPLEMENTATION MYOBJECT
+ (VOID)CLASSMETHOD: (ID) ARG [
REM SOME OPERATION
]

- (ID)METHOD: (NSOBJECT)ARG1 WITH: (INT)ARG2 [
REM
  RETURN OBJ
]

REM
- (ID)INIT [
  LET SELF = [SUPER INIT]
  IF (SELF <> NIL) THEN
    LET VAL = 0
    LET OBJ = NIL
  ENDIF
  RETURN SELF
]
@END

いやはや、一瞬で Objective-BASIC の仕様の中核が決まったじゃないか。よしよしと。
なかなかの収穫日であった。

追記:
Objective-BASIC は、もちろんコンパイラーとしても実装出来るが、インタープリタとしても実装出来る。オブジェクト指向のインタープリタとして RUBY が知られているが、仕様書を見てひっくり返った。なんて醜い仕様だ!! 作った奴は単なるオタクだ。オタクとハッカーの違いを見せてやる。ザコとは違うのだよ、ザコとは!!(ランバ・ラル調で(爆))

2007年10月23日

MMX "THE BASIC" の実装

MMX "THE BASIC" の実装を行っている。

しかし、MovableType のバグかこの記事は何回も文字化けして消失している。

現時点でバージョン 0.03a を作成中。バージョン 0.02c で以下の機能が働いている:

  1. コマンドラインから、環境命令 LIST、即時実行命令の LET と PRINT (引数は変数名一文字のみ、LET に関して言えばさらに演算子 "=" および右辺値数値のみ)、の実行。
  2. 行番号から始まるプログラムコードの入力および、コマンドラインから、環境命令 RUN による、LET、PRINT、END、のみで構成されるプログラムの実行。(LET、PRINT のコマンド仕様は(1)と同等である。)
  3. すでにプログラムコードにある物と同一の行番号から始まる行の置換(作成中の 0.03a で実装済み。)、プログラムコードにある物と同一の行番号空打ちによる行の削除(作成中の 0.03a で「見せかけ上」上手くいっている。)、はバージョン 0.02c では出来ない。
  4. 環境コマンド、命令文、変数名はすべて大文字でなければならず、また、変数、演算子、数値、のすべての間に一文字以上の空白か Tab が必要である。これは、構文解析を現状では sscanf に頼っているからである。

MMX "THE BASIC" のプログラムコードは C の模範的な無駄が一切ない美しいコーディングと言っていいだろう。だが、残念なことにオープンソースにするつもりは微塵もない。MMX "THE BASIC" とは、ハードウェアを含んでの総称なのだから。と言う訳で現時点で動くのはゲイツ君ご自慢のウィンドウズ環境のみとなる。うわっはっはっは! こいつは笑えるぜ、ジーザス!(笑) 古き良き頃のアップルの精神 "NIH" ("Not Invented Here") の精神である。また、MMX "THE BASIC" では、インデントを自動的に潰す。インデントを利用出来た方が、確かにループのネスト等の見通しが良くなるが、これを認めないことにより、アセンブラーへの移行が楽になる。ちなみに僕が会社に勤めていたときに、アセンブラーなのにインデントを付けてコーディングしてしまう先輩が居て困った。一年上の仲の良い先輩が C のコーディングでそのインデントを潰してみるプログラムを作ってきたので、僕は一行で書けるインデントを潰して表示するシェルスクリプト "nih" ("Not Indent Here") を作ったことがある(苦笑)。さてさて、好奇心旺盛なハッカーの諸君にバイナリだけ配布する:

MMX "THE BASIC" Version 0.02c
DEAD_LINK_http://rose7.s143.xrea.com/mmx/edit002c.zip

今までの作成過程での MMX "THE BASIC" の実動作スクリーンショット集:

MMX "THE BASIC" Version 0.02a


MMX "THE BASIC" Version 0.02b


MMX "THE BASIC" Version 0.02b2


MMX "THE BASIC" Version 0.02c


現在もバージョン 0.3a の作成中であるが多少進歩があった。テストに用いる BASIC のコードは以下の様である:
10 LET A = 3.141592
20 LET B = 2007
30 PRINT A
40 PRINT B
50 END

現時点で 20 と空打ちして 20 行を消そうとするが、バグがあって最終行である 50 行が消されてしまう。しかし、まあ、MMX "THE BASIC" では、プログラムが END 命令によらないで終了すると "Unexpected End Of File" エラーを返す様になっており、この場合も実際に 50 行が削除されてしまった後で RUN すると "Unexpected End Of File" エラーが返って来るので、前進と言えば前進だ。あと、問題なかったと思っていた、同一行番号から始まるプログラムコードの置換機能は見た目だけで実はバグがある。取りあえず、行番号空打ちによる行の削除のバグを取ってから、そちらにまわるとするか。

……さてさて、行番号空打ちによる行の削除は完璧だ。後は、同一行番号から始まるプログラムコードへの置換であるが、行の削除とほんのちょっとしか違わないアルゴリズムなので、問題ない。ちょっと一服するか。

ちなみに、MMX "THE BASIC" の実装の基本方針は、実行速度の速さではなく、プログラムサイズをコンパクトにする事を追求する。プログラムバッファーのソートにバブルソートを利用したのが良い例だ。また、実行時に中間言語層を設けるつもりも全くない。BASIC の特徴から、コマンドラインから即時実行可能な命令文の実行コードが、そのまま RUN したときの実行コードに使い回しが効き、プログラムサイズがコンパクトになるからだ。

そうそう、ここで「プログラミングモデル」について語っておこう。僕が取っている「プログラミングモデル」のスタイルは「ボトムアップ」だ。素人には難しいボトムアップだが、達人がするのなら、確実に綺麗なソースコードを書ける。かつ、細部のバグを取れば、まずセキュリティーホールが出来ない。「ボトムアップ」の対義語である「トップダウン」は素人向け。トップダウンでプログラムをデザインすると、最初のデザインが良ければ綺麗なソースコードになるが、逆に言うと最初のデザインがまずければとんでもなく醜いソースコードになり、当然の様に隠れたバグが山程出来る。そして、最初に行ったデザインが良いか悪いかはプログラムが完成してからでないと判らないと来ている。究極のトップダウン・ソースコーディング手法であるオブジェクト指向は、文字通り「ど素人」向けである。確かにクラスライブラリーとは一面便利に感じるが、あくまでクラスライブラリーにバグがないことが前提だ。そして、そんな甘ったるい幻想は直ぐに打ち砕かれる。赤の他人が作ったクラスライブラリーの質など当てにならない。あくまで "NIH" ("Not Invented Here") と言うことを忘れてはならないのだ。

今すぐには思いつかないが、「ボトムアップ式オブジェクト指向言語」をデザインしてみるのも悪くない考えだ。

現時点でのバージョン 0.3a の進捗だが、同一行番号から始まるプログラムコードへの置換は後少しである。現状だと、置換しようとした行がプログラムバッファーに2回出現してしまい、上に挙げたサンプルプログラムだと、50 行の END 命令がバッファーから削除され、結果としてプログラムは END 命令無しでの終了、つまり、"Unexpected End Of File" エラーで終わってしまう。これを何とかするのと、存在しない行番号を空打ちすると 100 OK と言った行になり、まだバグがある。これは行削除の処理のバグではない。この無駄な行に対して 100 と入力すればまた消せる。

さてさて、最後の大きなバグだった、同一行から始まるプログラムコードへの置換機能は完璧だ。後は最後の存在しない行番号を空打ちすると変な行が出来てしまうと言う問題を潰すだけ。……この最後のバグは、二ヶ所に分散していた。一ヶ所は簡単にバグフィックス出来た。もう一方がちょっと懸案だ。

「8080/Z-80 アセンブリ言語」

ZILOG Z80

ZILOG Z80


Amazon.co.jp に頼んでおいた、アラン・ミラー著「8080/Z-80 アセンブリ言語」(近代科学社)が到着した。この本は厳密に言うと僕が過去持っていた Z-80 (正式名称が "Z80" であるのは知らなかった。一般では "Z-80" で知られていたはずである。)の仕様書ではないが、Amazon.co.jp で一番良さそうな本としてチョイスした。「8080」と、うたっている通り、中身のコードはザイログ式ではなく、インテル式だ。まあ、x86 アーキテクチャとの兼ね合いからインテル形式も学んでおくことに損はない。

今、ふと思ったのだが、8086 の Small プログラミングモデルは、CS (Code Segment)、DS (Data Segment)、それぞれ 64KB で合計 128KB のプログラミングモデルであるが、Z-80 の場合 BC レジスタを使って、I/O 空間を 64KB 取ることが出来、つまり、合計で 128KB のプログラミングモデルが使用出来た。シャープの X-1 シリーズはこの特性をよく利用していた。

また、初期の MINIX は、8086 の CS、DS を利用して、本格的マルチプロセッシングオペレーションシステムに仕上がっていた。実装形式は知らないが、カーネルもまた CS、DS を利用して、128KB 以下だったはずである。この時代の MINIX で 10 個のプロセスを並列に実行すると、カーネル 128KB + 1プロセス 128KB × 10 = 約 1.4MB で非常に軽い。1プロセスで使用出来るプログラミングモデルが 128KB でも、UNIX のパイプラインを使えば、実質、もっと大きなプログラムが作成可能であることは言うまでもない。僕は ZILOG Z80 派で、その後は Motorola 68000 派であったが、今思うと Intel 8086 を作ったエンジニアもある意味まんざらではないと思っている。事実、コンピューターの歴史は、68000 でも RISC プロセッサでもなく、8086 の後継 x86 アーキテクチャがデファクトスタンダードだ。

ついでに Intel 8086 の書籍をあたったが、和書では良書と思われる物が無く、洋書で James W. Coffron 著 "Programming the 8086/8088" を購入した。届くのが楽しみである。Leo J Scanlon の "8086/ 8088 Assembly Language Programming" とどちらにしようか迷ったのだが、それぞれが他に書いている著作を比較して、 James W. Coffron の方にした。当たりだと良いのだが。

僕の中で IBM と言うとかなりの技術の実力がある会社だが、IBM PC-AT の設計を行ったとき、マルチプロセスが可能な Intel 8086 を採用したにもかかわらず、CP/M 86 の違法コピーである、ビル・ゲイツの MS-DOS を PC-DOS として採用したのか理解に苦しむ。Co-current CP/M と言うマルチプロセスの OS はいじったことはないし観たこともないが、8086 版で恐らく出ていたはずで、それを採用しておけばパーソナルコンピューターの歴史は 10 年早かっただろう。Macintosh は対抗上、真のマルチタスキングの OS を採用せざるを得ず、その結果 Mac OS X と言う、ビジュアルのみ派手で、中身が何もない OS では無く、白黒のクラシック GUI + Chicago フォントと言う僕にとって最高に麗しいインターフェイスが、真のマルチタスクで実現したのであろうから。(「漢字 Talk」に相当するオリジナルの名称が "System" だったのは初めて知った。実にクールなネーミングである。)

話は、8086 または x86 アーキテクチャに戻るが、僕が現在保有している、C の開発環境は LSI C-86 Ver. 3.30c 試食版だけである。試食版と言っても、プログラミングモデルがスモールモデルであれば何を作って公開しても良く、僕にとって都合が良い。Ver. 3.30c には、現時点で判っている範囲で、fgets のバッファ文字列制限機能に致命的なバグがある(オーバランする。)。

MMX の機械としての仕様に、使用する CPU に Intel 8086 またはそのクローンでも良いかも知れないと思っている。現在では組み込みマイコン用として流通しているはずである。ZILOG Z80 だって流通しているのであるから。8086 だと、少なくとも、確実にヒートシンクを使わずに済む。スクリーンはモノクロ液晶で VGA サイズ(640 × 480 pixels)でも構わないかも知れない。欲を言えば 800 × 600 pixels 位は欲しいが。まあ、モノクロだから、800 × 600 = 約 469KB で済むのだが。使用するフォントは Courier の Nomal と Bold だけで十分すぎる。

まあ、IBM が PC-AT を設計したときに Intel 8086 を採用したのは、「8080/Z80 に慣れたプログラマーがプログラムを(アセンブラーで)書きやすいこと」が第一目的で、それは確実に成功した。MS-DOS を PC-DOS としたのは先見の明が全くなかったが、IBM はハードウェア専業の(と言い切るのは失礼かも知れないが。)会社なのだから仕方なかったかも知れない。また、8086 に「セグメント」という壁があるのを承知で採用したのは、プログラマーに出来るだけ軽いプログラムを作ってもらう、と言う IBM からのある種の縛りだったのかも知れない。今のプログラマーはとても贅沢になっているが、僕の時代、少なくとも僕自身は「1バイトでも短く、1クロックでも早く」が標語だったのだから。

2007年10月20日

MMX "THE BASIC" 演算子・組み込み関数

今日は、MMX "THE BASIC" の演算子と組み込み関数の定義をしておきたい。QBASIC の仕様を参考にどこまで採用するか、と言うことである。

まず、算術演算子。"+"、"-"、"*"、"/"、"^"、"MOD" は最低限必要だ。"\" (「\」。バックスラッシュ)=「整数の除算」をどう定義するか。左辺値、右辺値(共に浮動小数数値)をまず、整数化し、除算の後の結果も整数化すると、取りあえず定義しておこう。

論理演算子は一切採用しない。

数学関数は、"ABS"、"ATN"、"COS"、"EXP"、"LOG"、"SGN"、"SIN"、"SQR"、"TAN"、を採用する。"RND"、"RANDOMIZE" (乱数の初期化)は採用の見送りの可能性が高い。所詮、「疑似乱数」であって、それなのなら、恐らく複数あるであろう「疑似乱数」をユーザー自身がプログラム中で実装した方がより数学的だ。

数値変換(型)であるが、MMX "THE BASIC" では、すべての値は C 言語での "double" であって、採用する価値があるのは、"FIX" と "INT" なのだが、「小数を切り捨てた値を返す(マイナス時 FIX と INT と違う処理)」となっていてユーザーの混乱を招く。定義があいまいだ。99BASIC で試した所、"FIX" は、例えば -3.6 と言う引数に対して、-3 を返し、"INT" は -4 を返す。この事は混乱を招くだけである。であるので、"INT" は「整数型」と言う「型」の意味も含まれるのを嫌い、浮動小数値の整数部分を取り出す関数は "FIX" のみとしよう。

実は、MMX "THE BASIC" に、従来には恐らく無かったであろう概念を導入することが決定している。「マルチプロセスインタープリタ」である。MMX "THE BASIC" 上の呼称では「デュアルモード」。画面を上下に分割し、それぞれ並列して RUN 出来る様にする、と言うことである。画面の上下の切り替えはスタライスペンで行う。この機能を実装することにより、例えば「行番号の振り直し」と言った行為が、「エディター」と言った概念を使用せずに可能になる。他の用途としては片方の画面で桁数の多い素因数分解のプログラムを実行している間に、別の画面で他のプログラムのコーディングをすると言った使用方法がある。この概念は大変ユニークで気に入っている。この「デュアルモード」に移行する命令は "DUAL"、「シングルモード」に戻る命令を "SINGLE" とする。

追記:

疑似乱数についてウィキペディアを参照し、「混合合同法(mixed congruential method)」を、MMX "THE BASIC" でコーディングした。実に簡単だ。やはり、安易に機能を足すのではなく、「数学への好奇心」をユーザーに芽生えさせるのが僕の目的だ。

2007年10月16日

MMX Mobile - 理想のコンピューターへ

携帯電話の「予測変換機能」を思い出して、MMX (「THE BASIC」)を、物理的なキーボード無しで、結構行けそうだと思いついた。

行番号を、画面上のソフトウエア・キーボードから入力するのはさほど難しいことではない。そして、次には必ず命令文が来る。MMX では、命令文の予約語は"LET" "PRINT" "GOTO" "END" "IF" "THEN" "ELSE" "FOR" "TO" "STEP" "NEXT" "REM" のわずか 12個だ。そのうち、行番号の直後に来る物は:
"LET" ("L")、"PRINT" ("P")、"GOTO" ("G")、"END" ("E")、"IF" ("I")、"FOR" ("F")、"NEXT" ("N")、
"REM" ("R")、の8個で、頭文字が一つも重ならない。ソフトウエア・キーボードからアルファベット一文字を打つだけで命令文が確定出来る。変数は特殊演算子名、組み込み関数名に重ならない物はアルファベット一文字で確定出来る。重なった物も「予測変換」を使えば容易に入力が可能だ。

これで、今まで "Dynabook X" と呼んでいた「理想のコンピューター」を、僕オリジナルの呼称「MMX」(「MMX Mobile」)に、自信を持って置き換えられる。

今日はとても良い収穫日であった。

2007年10月15日

やっぱり、クラシック BASIC は良いぜよ!

MZ-2000

Sharp MZ-2000

いま、99BASIC であそんでいる。もう、めっちゃ、楽しいぜよ!

やっぱり、あの時代(小学5年から中1)に戻った様で夢があるよなあ。今、Visual C++ .NET でまともなプログラム作ろうとしても多分楽しめないしなぁ。やっぱり、コーディング環境と実行環境がシームレスなのが良いな!! CP/M に MACRO80 が動く環境ないかなあ? 僕が、X-1 turbo III で CP/M と MACRO80 を使っていたときは RAM ドライブだったからかなり快適だった。シャープさん、MZ-2000 Legend 作ってくれないかなあ〜? ディスプレイは液晶で良いし、記憶媒体は SD メモリカードで良い。US 配列、と言いたい所だが、JIS 配列でもウェルカムだよ! X-1 turbo III も良かったけれど MZ-2000 は憧れだったからなぁ。今、下の様なプログラムであそんでいた。

10 LET X = RND(80)
20 LET Y = RND(20)
30 CLS
40 LOCATE X, Y
50 PRINT "*** HELLO! ***"
60 FOR Z = 0 TO 99999
70 NEXT Z
80 GOTO 10

8行で書けるスクリーンセーバーだ。GNU Emacs LISP でこれを俺が作ったのと同じ時間で作れる奴がいるか?(いるかも知れないけれど……。居たとしたら変人だ!) 素晴らしいぞ! BASIC!! やっぱり、プログラミング入門は簡単に楽しめなきゃ駄目だよ!

う〜ん、別のフリーの BASIC もどき UBASIC (DOS で動く)を使ったが "LET" を理解しないぞ!(怒) 99BASIC 本当に良くできている。UBASIC をできれば HP200LX でと思ったんだが、勝手に小文字に変換するし(昔は勝手に大文字に変換された。)、"LET" を理解しないし、やーめた!! こりゃ、やっぱり、「THE BASIC」を HP200LX 向けに作るしかないか? まるで、大昔のビル・ゲイツである(苦笑)。

……今日も徹夜だ(笑)。

「THE BASIC」言語仕様の範疇内で、BASIC で用いられる標準的な演算子と関数を使うことで、2から任意の数の間に存在する、「素数」を求めることができる。これはコーディング済みだが、演習としてやってみる価値はある。「素数」が求められたら、今度は「素因数分解」ができることになる。

……さて、取りあえずの素因数分解のコーディングが済んだ。ケチっているので結果が例えば:

RUN
1534 = 2 ^ 1 * 13 ^ 1 * 59 ^ 1 * 1
OK

となってしまうが(爆)。

……、やっぱり、僕の BASIC、「THE BASIC」を実装したくなってきた。今使える C コンパイラは LSI C-86 試食版のみ。JAVA でアプレットを作ってっていうのもありか? でも、JAVA のマニュアルとか全部古本に出してしまったし。

取りあえず、「THE BASIC」が動く(ヴァーチャル)マシンを「MMX ("My Machine X")」とコードネームを付けておくか。しかし、肝心の HP200LX 用の RS232C のケーブルどこ行ったのかなあ?

LSI C-86 を試してみたが、GNUWin の bison と全く連携が取れないぞ! まあ、DLL とか付いてくるのかも知れないから、取りあえずのターゲットマシンである HP200LX では、所詮叶わぬ夢だが。よいよ、「頑張れ! ゲイツ君!!」だ!(爆)

追記:

「THE BASIC」言語仕様に置いて、「同一の変数に対する FOR のネストを認めない。」と規定したが、この条件は緩和する必要がありそうだ。例えば次のコード:

10 FOR N = 2 TO 100
20 FOR M = 2 TO N
30 LET X = N / M
40 IF X = 1 THEN GOTO 80
50 IF INT(X) - X = 0 THEN GOTO 90
60 NEXT M
70 GOTO 90
80 PRINT "PRIME NUMBER = ";N
90 NEXT N
100 END

に置いて、50行で条件を満たせば、変数 M に対する FOR ループのネストから GOTO 文により、離脱する。このコードは 100 行の END 命令で終わっているから良いが、100 行以降に、変数 M に対する FOR が、改定前の規定だと、使用出来なくなる。これはゆゆしき問題であり、また、この様な問題は深いネストからの離脱につきものなので、新しい規定を以下の様にする。

「同一の変数に対する FOR 命令文が出た場合、その変数に対する NEXT 命令文のループをより新しく実行された方の FOR ループに適応させるものとする。」

これで、今回発生した欠陥を修復出来る。いや、本気で言語(のインタープリタ)を作ろうとすると、昔は考えもしなかったことに気がつくんだなあ〜!

……。素因数分解のコードの出力をちょっとだけましにした。今のところ:

4525 = 5 ^ 2 * 181 * 1

……。最後の "* 1" を消せれば表示上の問題はお終い。しかし、公開鍵暗号の暗号化鍵に使われるだけあって、数字が大きくなると極端に演算時間が長くなる。

このコードを書いていて、FOR 命令文のもっと厳密な定義が必要なことに気がついた。

現在の仕様上は、

10 LET A = 100
20 LET B = -1
30 FOR C = 0 TO A STEP B
(snip)
50 NEXT C
60 END

と書いた場合、変数、A、B、C は整数でないと行けないと定義している。これは今のところ間違ってないと思う。

C言語の場合は、

for (a = 0; a <= 100; a += 0.3);
for (a = 100; a >= 0; a -= 0.3);

の様に記述出来、変数 a の変化値が少数であっても、「より小さい」、「より大きい」でループの存続条件を決められるが、BASIC では

10 FOR A = 0 TO 100 STEP +1
(snip)
30 NEXT A
40 FOR A = 100 TO 0 STEP -1
(snip)
60 NEXT A
70 END

の様に、ループの存続条件を「より大きい」とも「より小さい」とも規定出来ず、「等しい」と言う条件である必要がある。この事から、引数は「整数」である方が合理的と考えられる。もちろん、引数として与えた式の結果が整数であればよいのであって、演算式の内部は別に浮動小数点数値でも構わない。ただ、評価時に整数値になっていなかったらエラーを返すべきである。

99BASIC で、FOR 文の引数に浮動小数値を入れてループを回したが、エラーにはならなかった。しかし、終了条件は、TO の後に書かれた値の、整数部分が合致した場合であった。厳密に、終了条件として与えた浮動小数点値ではなかったことは言うまでもない。これは、ゲイツが作ったバグに違いない(怒)!

……。きっと、作者は、"very near *the gates*!!" って言う所でプログラミングしていたんだね。

と言っている内に素因数分解のコードが麗しく:

RUN
525 = 3 * 5 ^ 2 * 7
OK

と、表示するバージョンを作れた。後は行番号の振り直し(笑)。

……今終わった。行番号の振り直し。NOTEPAD にコードを書いてから、99BASIC で入力したから、「シームレスな開発環境」としては、ちょっと悔しい気がする。コメント付きの Ver. 0.9 として置いたが永遠の Ver. 0.9 だろう(笑)。FORTRAN なんかも古くさい言語だけれど未だに過去の蓄積の計算コード使われているから、あながち JAVA とか新しい言語知っているのが偉い訳じゃない。

2007年10月14日

THE BASIC 言語仕様検討

プログラミング入門として、ダートマス系 BASIC の有効性ははっきりしている。だが、現在、存在する BASIC は複雑極まりない。MS-DOS に付属していた QBASIC でも入門には複雑に感じる。

まず、プログラミング環境としては、コーディングと実行環境がシームレスである仕様にしようと思う。つまり、プログラムのコードは行番号から始まらなければならない。そして、行番号の後には、必ず命令文が来る。「10 X = X + 1」の様な MS 系の書き方は認めない。「10 LET X = X + 1」とダートマス式に書く。プログラムが変数を扱う以上、"LET" と言う命令文が真っ先に必要になる。行番号を付けず、「LET X = X + 1」と入力すればその場で解釈され、「PRINT X」で変数 X の内容が表示される。「20 PRINT X」と書き、「RUN」と入力すれば、プログラムが実行され、結果として変数 X の内容が表示される。"PRINT" は次に必要な命令だ。

そして、次に必要な命令文は、もっとも単純な制御命令である "GOTO" だろう。「30 GOTO 10」と書いて RUN で実行すれば、X の内容が +1 ずつ足された内容が永遠に画面に出力される。なお、良くある BASIC では "GOTO" 命令を "GO TO" と分けて書くことを認めるが、僕の BASIC では認めない。

今までに挙げた、"LET"、"PRINT"、"GOTO" はすべて英語の動詞である("GOTO" に関しては "GO" が動詞であるのが厳密だが。)。

この次に必要な命令文は、"IF"。動詞ではないが、これがないとお話しにならない。「25 IF X > 100 THEN GOTO 40」、「40 END」の様に書くべきだろう。ダートマス系 BASIC でプログラムを終了するために必ず「END」命令文が必要だったかどうかは知らないが、僕の BASIC ではプログラムを停止させるために "END" 命令は必須とする。"IF" 命令文の "THEN" +命令文の次にオプションで、 "ELSE" +命令文、を認めることにする。

この後に思いつく命令は "FOR"、"NEXT" だ。実は BASIC の "FOR" 命令文の構文をすっかり忘れていて調べ直した。上に書いたプログラムは忘れてしまって、最初から書く。

10 FOR X = 1 TO 100
20 PRINT X
30 NEXT X
40 END

これを "RUN" すれば、1から 100までの数字がプリントアウトされる。"FOR" 命令文には "TO"+整数値、の後に、オプションで "STEP"+整数値、を認めることにする。ここで、ネストの問題が発生する。まずは、"GOTO" 命令との問題。

10 FOR X = 1 TO 100
20 IF X = 50 THEN GOTO 60
30 PRINT X
40 NEXT X
50 END
60 PRINT "HELLO"
70 GOTO 30

単純化したが、"FOR" "NEXT" 命令の間に "IF" 命令で条件を満たした場合、"GOTO" 命令でサブルーチンを呼ぶ様なことができる。しかし、次の様なことも考えられる。

10 FOR X = 1 TO 100
20 IF X = 50 THEN GOTO
30 PRINT X
40 NEXT X
50 END
60 FOR Y = 1 TO 100
70 PRINT Y
80 NEXT Y
90 END

この場合、変数 X に対するループは X が 50 になった段階で実行されなくなってしまう。インタープリタの作業内容としては、"FOR" 命令文で変数 X に対してループを構成し "NEXT X" でプログラムの 10 行へ戻る様スタックに情報をプッシュしてしまう。このプログラムは 90 行で終わり、変数 X に対する "FOR" 命令文のスタック情報がスタックに残ったままになる。まあ、"END" 命令の処理で "FOR" 文のスタックを空にすれば良いだけだが。後は仕様として、同一のプログラム中で、同じ変数に対する "FOR" 命令文がネストした場合エラーを返さないと大変なことになる。僕の BASIC では、"FOR" 命令文は一つの変数に付き、スタック情報が開放されない限り、一度しか記述出来ないこととする。次の様なことは可能だ。

10 FOR X = 1 TO 100
20 PRINT X
30 NEXT X
40 FOR X = 100 TO 1 STEP -1
50 PRINT X
60 NEXT X
70 END

後は "CALL" 命令文の様なサブルーチンを呼ぶ命令であるが、"CALL" 命令文の構文は "CALL サブルーチン名 [引数]" であるが、僕は僕の BASIC で「ラベル(行番号の代わりに付けるプログラム中の位置の指定形式)」を使うつもりはないので採用しない。また、"WHILE" "WEND" と言った制御命令も僕が定義した命令で代用出来るので採用しない。

変数に関してであるが、僕の BASIC ではアルファベット一文字、A から Z までの 26個のみ。型式は浮動小数点の数値のみ。変数で文字列を扱えないとプログラムが数値演算に特化するが、僕の BASIC は「プログラミングの入門専用」なのだから、それで良い。この様な仕様にすると "INPUT" 命令文を不採用とするしかない。プログラムを実行したユーザーが数値のみ入力してくれるとは限らず、数値以外の物を入力した場合、エラーを返す訳にはいかないからだ。

また、画面の制御には "CLS" 命令の様な画面をクリアする命令も採用しない。僕の BASIC では、プログラムを使うものは、プログラムの最初の方で "LET" 命令で定義される数値パラメーターを "LET" 命令を書き換えることで変更し、数値演算結果を "PRINT" 命令で、出力することさえできればいい。残る命令は "REM" 命令。プログラム中に入れる注釈を入れる命令だ。

ここまでで、予約語は、"LET" "PRINT" "GOTO" "END" "IF" "THEN" "ELSE" "FOR" "TO" "STEP" "NEXT" "REM" のわずか 12個だ。後二つプログラミング環境命令の "RUN" "LIST" が予約されるがプログラム中では使えなくエラーになる。

"LIST" の使い方は、単に "LIST" と入力すれば、プログラムすべてを画面上に出力。"LIST 50-" で行番号 50 から出力、"LIST -50" で行番号 50 まで出力、"LIST 50-100" で行番号 50 から 100 まで出力、と言った使い方だ。ある行番号の命令を消したい場合、その行番号を入力して "ENTER" を押すだけ、例えば "50"+"ENTER" とすれば、50 行は消される。

あと、"PRINT" 命令について補足すると、

10 PRINT "3 + 5 = ";
20 PRINT 3 + 5

の 10 行の様に最後に ";" を付けると改行しない。

ずいぶんと古い仕様の BASIC となったが、プログラムのコーディングと実行環境がシームレスなのは、GNU Emacs が *scratch* バッファーで、GNU Emacs LISP を即実行可能で「環境」として非常に良くできている様になかなか便利な物だ。

追記:

自分で BASIC インタープリタを作らなければならないかと思っていたが、ちょうど思った様なフリーウエアの BASIC があった。その名も "99 BASIC"。以下のサイトで DOS 窓風な実行環境な物がダウンロード出来る。

99BASIC
http://www.sagami.ne.jp/tadaka/99Basic/

ちなみにネスト対策にバグがあるらしく、

10 FOR X = 0 TO 100
20 IF X >= 50 THEN GOTO 60
30 PRINT "X = ";X
40 NEXT X
50 END
60 FOR X = 100 TO 0 STEP -1
70 PRINT "X = ";X
80 NEXT X
90 END

とコーディングし、RUN しても何のエラーも返さない。とはいえ、gcc がインストール出来ていない現状で、プログラミングの薫りを味わえるのは、子供の頃に帰った様で楽しいよ。

Dynabook X への道

HP200LX

Dynabook X とは、アラン・ケイの「Dynabook」から概念と名前を借りた僕流の理想のコンピューターのコードネームである。Dynabook X のサイズは DVD のジャケットを横にした大きさを今は想定している。

僕は、大学院では結果的に音声情報処理を専攻したが、会社では携帯型端末の開発に従事したかった(この願いもむなしく、CD-ROM ドライブのファームウエア作成という日陰部署にまわされた。)。

僕が現在保有している携帯端末は DS Lite を除けば大学院時代から使っている HP200LX (写真上)である。写真は僕の使っているものの実物で、僕が ZCLV を発案したとき、HP200LX 内蔵の Lotus 123 で導かれたグラフが写真の画面に映っている。現在入手出来るかどうか判らないが、僕が持っている携帯端末の中では、HP200LX が唯一開発環境がある携帯端末になる。

僕は Dynabook X に、ドローソフト、表計算ソフト、プログラムの開発環境、と言ったクリエイティブな作業をするコンピューターであって欲しいと思っている。

しかし、表計算ソフトなら、液晶上のソフトウエアキーボードでも使用に耐えるが、デバイス単体でのプログラムの開発となると物理的なキーボードがいると考えた方が良いだろう。

僕は小学5年の時から、当時「マイコン」と呼ばれた、PC-8001 や MZ-2000、X-1 と言った物の上で、MS 系 BASIC でプログラミングを覚えた。MS 系でなく、ダートマス系である初期の True BASIC (今は機能が増えすぎて煩雑になっている様だ。)はプログラミングを覚えるのに一番良い環境だと思う。基本的に BASIC と言うインタープリタは、プログラミングの作成環境と実行環境がシームレス(プログラムのコードを書くときは、先頭に行番号を付け、実行は「run」で行えばよい。)なのが利点であり特徴だ。僕の場合、MS 系 BASIC の次に覚えたのが Z-80 のマシン語だ。少なくとも Z-80 レベルのマシン語を覚えるのは非常に有益だと思う。例えば、C 言語における、ポインタの理解が早くなる。

今、肥大化した BASIC を昔なじみの美しい姿にしようかな?、と考えている。だが、どの程度軽量化するかが問題だ。僕が、BASIC でプログラミングを始めたのは「(コンピューター)ゲームが作りたい」と言った動機が強かった。だが、初めて次の様な、プログラムを書いて実行して興奮した物だ。

10 PRINT "HELLO"
20 GOTO 10

このプログラムは当時のマイコンにあった BREAK キーがないと RUN すると終わらない。が、凄く懐かしい。この項目は稿を改めて、書こう。

プレステ版「Tomb Raiders」発掘

プレステ版 Tomb Raiders
ついに、プレステ版の初代 Tomb Raider、「Tomb Raiders」を発掘した(写真上)。久々の対面。しばし、感涙に浸った。

で、である。プレステの性能は、CPU:MIPS R3000A (動作周波数:33.8688MHz)、 ポリゴン表示能力:最大36万ポリゴン/秒である。それに対して DS Lite は、CPU:ARM946E-S 67MHz(メイン) + ARM7TDMI 33MHz(サブ)、120,000ポリゴン/秒である。ポリゴン表示能力がプレステの約1/3だが、「BIOHAZARD」がほとんどそのまま動いている所を観ると、DS Lite の画面の小ささから言えば、十分に初代 Tomb Raider を移植出来るはずだ。

米国版であるが DS 用に「Tomb Raider: Legend for DS」が出ているのに何をムキになっているというと、次の YouTube の映像をご覧頂きたい。

なんと、ララ・クロフトが画面を横切って移動している!(怒) 本来、Tomb Raider では、ララ(日本名「レイラ」)・クロフトのちょっと後ろ側の上から、ララの視野を見ることに醍醐味がある(シチュエーション上やむを得ない場合はララが横を向いて表示されることもあるが。)。俺は悲しいぞ! 「Tomb Raider: Legend for DS」は、Tomb Radier シリーズとしては偽物である!!(怒)

CORE Design! DS 向けに本物の Tomb Raider を作れ! 命令だぞ!!

「アスファルトアーバンGT DS」をプレイした

アスファルトアーバンGT DS
先日注文しておいた「アスファルトアーバンGT DS」が届いたので、早速プレイしてみた。ゲームとしてはリアル系レーシングゲームで、今、日本でこの系統の DS ソフトがないから、定価 2,800円の所を新品のストリートプライスで 4,000円だしたかいはあったと思った。希少性が非常に高いと思う。なかなか楽しめそうなソフトだ。

唯一注文があるとしたらプレイが終わったときのリプレイムービーをもっと迫力のあるものにして欲しいと言うことだ。「JetImpulse」の興奮と爽快感を覚える様なリプレイムービーを観た後ではどうしても見劣りする。超名作映画「栄光のルマン」の様にカメラワークを考えて欲しい。

RIDGE RACER DS

ネットで調べていたら米国では「RIDGE RACER DS」(写真上)が出ているそうだ。ただ、グラフィックが旧世代なので日本で発売はないんじゃないかという感想もあった。まあ、「アスファルトアーバンGT DS」で十分満足出来るから、レーシングゲームも買い足す必然性はないのだが「RIDGE RACER」と言えば一つのブランドだ。3Dのレンダリングエンジンを DS 向けにギリギリまでチューンして、プレステ2の「RIDGE RACER V」くらいの領域のソフトは出せないのだろうか。出たら、買うことにやぶさかではないのだが。

2007年10月13日

NINTENDO DS Lite クリムゾン/ブラックを買った

NINTENDO DS Lite クリムゾン/ブラック
今日は、NINTENDO DS Lite の新色、「クリムゾン/ブラック」(写真上)を買った。今まで持っていた「ジェットブラック」のものは指紋が付きやすく、「クリムゾン/ブラック」だと本体下部のブラックの部分にはシボ(指紋や傷を付きにくくするための、プラスチックに施された極小の凹凸)が入っているのでその点が気に入った。また、「クリムゾン("crimson"、『深紅』)」と言うのが相川七瀬のアルバム名であり、赤や深紅は彼女のイメージカラーなのでその点も気に入った。

僕が持っていた「ジェットブラック」の DS Lite は、中古に売りに出し、8,300円だったからまずまずだった。

DS Lite BIOHAZARD

DS Lite を中古に出して得た金額の一部で、懐かしの「BIOHAZARD」(写真上)を買った。出だし以外はほとんど忘れているので、「クラシックモード」でプレイ中。キャラクターが画面の奥に言ってしまうと DS Lite の画面ではやはり小さい様に感じるが取りあえずプレイには支障が出ていない。僕は昔は RPG をしたが、今はそんな悠長なものをする気にならず、リアルタイムアクションアドベンチャーが好きだ。僕が「Tomb Raider」を好きなのは知る人なら知っているか。DS で出ないかなあ? 初代「Tomb Raider」(初代は指定ポイントでしかセーブができず、シリーズを通して一番難度が高いと思う。)を「Tomb Raider DS」として売りに出して欲しい。出たら絶対買うなあ。せっかくだからララ・クロフトのポニーテールがなびく様にして(初代「Tomb Raider」ではポニーテールは全く動かなかった。)、オリジナルのシナリオ通りの「クラシックモード」とオリジナルの筋を大胆に変えた「リメイクモード」があれば完璧だ。

後は「JetImpulse」は操縦モードが「ノーマル」(現実とは異なり、単に「左旋回」、「右旋回」を行うだけである。)より、当然のことであるが、「アドバンスド」(十字キーにより、左右でエルロン(ロール)、上下でエレベーター(ピッチ)、Yボタン+十字キー左右でラダー(ヨー)を制御する。)の方が面白いと気が付いた。ラダーはできれば、Lボタン、Rボタンに割り当てて欲しかったが、Rボタンが加速とアフターバーナーに割り当てられていて、Lボタンは減速とエアブレーキに割り当てられているから仕方がない。まあ、ラダーを使うのはよっぽど細かい作業だから、ゲームプレイとしては旋回は左右どちらかにロールしピッチを上げることで行うのが普通だと思う。このゲーム、プレイした結果をムービーで再現してくれてカメラワークが良く非常に興奮し爽快感すら覚える。実に良くできたゲームだ。気分はもう「エリア88」!!

実はプレステ2用に「THE 零戦」と言うのが出ていて羨ましいのだが(メーカーさん、DS 向けに作ってください!)、期待した空母からの手動による発艦、着艦ができないのが玉に瑕だ。

久しぶりに、弟の PSone で Tomb Raider でもしようかと CD-ROM を探したが Tomb Raider II しか出てこない。で、プレイしてみた訳であるが、初代 Tomb Raider では、L1+十字キーで視点の切り替え、R1+十字キーでゆっくりと歩行、L2とR2で左右に平行移動だったんだなあ。どれも外せない。DS Lite にはLボタンとRボタンしかないから、Lボタン+十字キーで視点の切り替え、Rボタン+十字キーでゆっくり歩行、Lボタン+Rボタン+十字キーの左右で横方向に平行移動するのが良いと思う。ちなみに Tomb Raider II ではR2+十字キーの左右で平行移動。L2はトーチだからL2をずいぶん無駄に使っている(オプションで Tomb Raider I と同じにできいるが。)。アイテムの使用で済むはずなのに。

あんなに大事にしていた初代 Tomb Raider はどこに行ったのかしら? と探していたら Tomb Raider IV が出てきた。僕は Tomb Raider I、II、III、IV と所有しているが、IV は途中で飽きてクリアしなかった。でも、さすが画像は綺麗だね。で、Tomb Raider IV で、平行移動はR1+十字キーの左右。つまり、R1+十字キーを「歩く」と「平行移動」にしたのだ。「L2」はしゃがむ、「R1」はダッシュに割り当てられているが、「Tomb Raider I DS」を作るにあたって、LボタンとRボタンだけで良いことがはっきりした。是非是非作りなさい、コア・デザイン。

……って、「Tomb Raider: Legend for DS」って、出ているのか。少なくともアメリカでは。

Tomb Raider Legend for DS

DS JetImpulse をプレイした

DS JetImpulse
かなり以前に購入した DS Lite 向け空戦シミュレーター「JetImpulse」(写真上)をプレイしてみた。買ったときにはフリープレーでバルーンを打ち抜くミッションで、「面白くない」と思って止めてしまった。

今回はストーリーモードで、これがなかなか面白い。最初の2ステージはクリアし、今、3番目のミッション「紅蓮への道」ではまっている。敵戦闘機を落とすことは雑作もないのであるが、自国の石油コンビナートに突っ込んでくるテロリストに支配されたタンカーのスクリューのみ破壊すると言うことがなかなか難しい。片方のスクリューだけなら破壊出来るのであるが。……でも、楽しみが増えた。

ちなみに「THE 歩兵」では LEVEL 4 で一人で三台の敵戦車を破壊するミッションではまっている。これも、一台だけなら破壊出来るのであるが。

DS アスファルトアーバンGT

それから、比較的リアルな DS 向けレーシングゲームを見つけた。「アスファルトアーバンGT」(写真上)である。が、もう生産中止らしく、ネットのストリートプライスで本来 2,800円の所を新品で 4,000円出した。どんな感じなのか楽しみである。

2007年10月10日

DS ゲーム「THE 歩兵」を買った

DS THE 歩兵

マリーンズ(海兵隊)で、「生き残る方法」。絶対的に資料が乏しい。マリーンズの分隊の人数(9人から12人だとは思うが。)、装備、戦術、どれを取ってもまともに情報がない。

東京マルイの電動ガン M16A2 (これが、現在、マリーンズで実際に使用されているアサルトライフルかどうかも判らない。)にしたって、連射速度は実銃近くまであるが、初速や射程距離なんてお話しにならないし、弾倉に 68発も BB 弾が入る。まあ、弾倉に関しては故意に 30 〜 32 発 BB 弾を装填して、オプションで弾倉を複数買い足すことも考えたが、弾倉自体、本物に比べてはるかに軽いそうである。これじゃ、お話しにならない。300発の弾倉もあるから、あくまでもお遊びの域を出ない。

そんなこんなで、電動ガンはあきらめて、Porsche に乗ったことが刺激になっていたので、近くのテレビゲーム店に PS2 か、NINTENDO DS Lite 向けのレーシングシミュレーターは無いかと思って行った。ウチには弟の PSone しかなく、PS2 だと新たに買わなくてはならない。ちょっとした出費だ。DS だと、「スーパーマリオカート」だけしかなくて、これじゃ、本物のカーレースとはほど遠い。

そんなこんなで目に入ったのが、DS 向けサバイバルゲーム「THE 歩兵」(写真上)。気に入ったので早速買って帰ってあそんでみた。

いやいや、なかなか面白い。はまってしまった。このゲームは自分の名前を入力すると怖い上官が理不尽で勝手なあだ名をプレーヤーに付けて、それがゲーム上の名前になるのだが、僕のあだ名は「恩知らずのハルマゲドン」(爆)。

面白いことは間違い無しなのだが、所詮ゲーム。実戦だと実弾を1発、多くても3発、敵の銃弾を受ければ行動不能になるか死んでしまう筈なのに、結構な数の銃弾を撃ち込まれてもなかなか死なない。まあ、敵の射撃精度がかなり高いから、ゲームとしての面白さの追求だろう。

今、初級者向けミッションを3つクリアして伍長になったが、3つ目の市街地に敵が儲けたバリケード2つを破壊するというミッションでは手榴弾の使い方を誤って5回程自爆して死亡した(笑)。死亡すると上官が「許可なく死亡することなど許されているのか、このウジ虫! 出直してこい!(怒)」と言われ、「Sir, Yes, Sir!!」と行ってミッションを繰り返すことになる。まあ、「Sir, No, Sir!!」と言ってミッションを終わらせることもできるが、こっちにも意地がある(苦笑)。

DS 向けに「THE 海兵隊」を作ってくれると嬉しかったりする。

補足:

「THE 歩兵」は、今、LEVEL 3 で上級曹長である。いや、大変な道のりであった。LEVEL 2 のミッションで敵の勢力下にある市街地の通信用アンテナをぶっ壊してこい!、と言うミッションには泣いたぞ!(泣) だって、狙撃兵がわんさといるのに、こっちはたった一人。実戦なら 100回やって 100回死ぬミッションである(爆)。体力補給剤やレーションがもう、ほとんどなくて、これからが思いやられる。簡単なレベルの低いミッションをやって敵から回収すればいいのだが、それをしないのが「男らしいプレイ」であろう。まいった、まいった。

2007年10月09日

BEHRINGER NR100 を買った

BEHRINGER NR100

ノイズレデューサー BEHRINGER NR100 を買った(写真上)。

理由は FLIP HELL MONSTER + BOSS RV-5 のみでライン録りすると、弾いていないときに HELL MONSTER が発生させるノイズが大変うるさかったからだ。昨日、行きつけの山野楽器の顔なじみのリペアマン、Kさんに電話をかけたら「アンプシミュレーターを買えば直るかも」と言ったが、色々調べた結果、あまり効果が期待出来ないことが推測された。

あらかじめ、安手のアンプシミュレーターとして、BEHRINGER と言うブランドを知ったが、山野楽器で取り扱いがなく、今日、新星堂 ROCK INN に電話をかけて相談したら、BEHRINGER からでているノイズレデューサー NR100 がかなり効果的ではないかという話になって、早速お店に行き試弾。HELL MONSTER + NR100 + RV-5 と言う組み合わせで試弾した。

店員が NR100 の取り扱いになれていないせいで、ノイズリダクション効果はある物のアタック感のないサウンドになってしまった。とはいえ、値段が手頃で気に入ったしノイズリダクションの必要を感じていたので購入し、帰投。

帰って、実際にいじってみたら、NR100 に付いている "THRESH" (閾値)、"DECAY" (減衰量)で、"DECAY" を MAX にして減衰量を最大にし、"THRESH" で弾いているときに "DECAY" が掛からず、弾いてないときに "DECAY" が掛かる様に設定したら、アタック感を保持したままノイズリダクション効果を得ることができた。

とても良い買い物だった。

2007年10月08日

BOSS RV-5 を買った

BOSS RV-5

ライン録りのために、BOSS のリバーブ、RV-5 (写真上)を購入した。BOSS のホームページでスプリングリバーブをシミュレートできるのが気に入り、早速行きつけの山野楽器で試弾。アンプは型番は控えていないがスプリングリバーブの付いたフェンダーのアンプで行った。

いやいや、実に良くて来ているエフェクターだ。フェンダーのアンプ内蔵のスプリングリバーブと音を比べてみたがほとんど同じ効果を出すことができる様だ。とても気に入り即購入。

FLIP HELL MONSTER

歪み系を担当するのは、かなり昔購入したミニチューブを使ったデストーション、FLIP HELL MONTER (写真上)。デストーションは幾つかもっているがこれが一番お気に入り。

実はお恥ずかしいことなのだが、以前、Steve Johnson Studio "Steve Plays Phoenix: Improvisation No. 1" をレコーディングしたときは PC で起動している SONNAR 3 のデストーションとリバーブのオーディオエフェクトをかけた結果をモニタリングしていて、当然の様に音が遅れて聞こえた。今思えば当たり前のことである(汗)。

使用している USB オーディオインターフェイス、EDIROL UA-20 にはインプットモニターがあるので、それをオンにして、HELL MONSTER と RV-5 を使用すればリアルタイムにモニタリング出来る。

試しに「エリーゼのために」を弾いたが、HELL MONSTER と RV-5 の相性はとても良い様だ。とても嬉しい。

現在、ギターの練習量はほとんどゼロな上に、左手人差し指が原因不明で腱鞘炎になっているので、新曲がいつレコーディング出来るかはまだ判らない。

ともあれ環境は整った。楽しみである。

2007年10月06日

Porsche 911 試乗感想

Porsche 911

ついに試乗してしまった! Porsche 911 に。今、まさに夢の中にいる様である。

昨日 Porsche のディーラーのセールスに、試乗車が左ハンドルなのを心配していることを言うと「運転しなくても隣に座っているだけですごさが判りますよ」と言われたが、「まさかあ〜!」と思っていた。が、その先入観は完璧に粉々にされた。

試乗車は左ハンドルのオートマだったが、都内故、試乗コースに制限があったにもかかわらず、スキンヘッドのセールス(レックス・ルーサーか!(笑))の運転で横に座って試乗してひっくり返った。「凄い」とか「速い」といったレベルではない。死ぬかと思った(爆)。

今、無事に家に帰投して、その恐怖と戦慄が喜びとなって体中を突き抜ける。……って、お前はミッキー・サイモンか!(笑) いや、本気だ。

大戦中の米国に生まれていたらマリーンズ(海兵隊)に志願したい気分だ。以前はスナイパーに憧れていたが、今の気分はマリーンズの一員となり、強襲上陸艇で接岸し、マシンガンを乱射しながら海面を駆け抜け、伏せることなく橋頭堡が確保されるまで戦い抜きたい気分だ。陸軍のお坊ちゃん達が来た頃にはコーラで一服して、鼻歌歌っている筈(笑)。イラク戦争に置いて米国は完全に悪だが、マリーンズの諸君とは友達になれる。少なくとも君たちは卑怯者じゃない。

今日は大変有意義な日であった。

最後に付け加えれば、本日以降、スポーツカーの評価基準は Porsche 911 が物差しとなる。

補足:

マリーンズに関しては完全にノリで書いていたので、「マシンガン」と書いたが現実には「アサルトライフル」だよな? 多分。M16 で弾倉は最大で 30発。900発/分だから、連射すると2秒で弾倉が空になる。まあ、実戦ではそんな乱暴な事しないのだろうが、こりゃ、きちんと考察しないといけないなあ〜。「生き延びる方法」。だって簡単に死んだら戦力にならないだろう? う〜ん、気になってしようがない。稿を改めよう。

2007年10月05日

Lexus ISF vs. NISSAN GT-R?!

今日の朝刊でトヨタ系列では唯一で国内最高値のスポーツカー Lexus ISF が発表になった。また、NISSAN も NISSAN GT-R で情報を小出しにしてメディア戦術に出ている。

さて、上の写真であるが、Lexus ISF でも NISSAN GT-R でもない。NISMO の NISMO R34GT-R Z-tune である。……美しい! ブラックメタリックだったら惚れてしまいそうだ。乗ってみてえ〜! ……が、とっくの昔に生産終了である(涙)。保存車2台を含めて19台の生産だったそうである。あ、NISUMO の偉い人、保存車の内1台を俺にくれない? 一生乗るよ? アメリカの超高い宝くじに当たって NISMO ごと買収か? NISSAN の 100% の子会社な様な気がするが。

さてさて、後ろ髪を引かれる気がするが、Lexus ISF と NISSAN GT-R に話を振らなければなるまい。涙の決断である。

とりあえず、Lexus のホームページが込んでいたので、最寄りの Lexus 代理店に電話してセールスが言った言葉にひっくり返った。「サーキット場でも走れるスペックです」。おいおい、気は確かか? こいつが実際に走るのは「サーキット場」か?、「公道」か? 猿でも分かる話だよな。どうせ、180Km/h でリミッター切ってあるんだろう?(後で確認したら、180Km/h でリミッター切っている事が判った。まるで馬鹿。)。 そんなとろい車でサーキット場走ってもちっとも面白くないだろう。お前、馬鹿だろう?! いや、社長が。写真に写っていた副社長も。

さてさて、カルロス・ゴーン。お前には経営について語る資格はあっても、スポーツカーについて語る資格なんて全くないって。おいおい。あんな滅茶苦茶なサイドビューのスポーツカーが美しいはずないだろう? だいたい、現行 Z のフロントマスクの醜さだって日産史上に残るだろう。リアから観れば観れなくはないが。

心ある日産の偉い人たち、大株主の皆さん、ゴーンと差し違えてでも良いから "NISSAN GT-R" と言う一度使ったら使い回しが効かないとっておきの名前を付けるな!

取りあえず、どっちも試乗する予定である。覚悟しておけ!(怒)