AB開発日記

いつもどおりにフロアでウロチョロしていると、女の子スタッフ、ハラちゃんがおいらのところへ来ます。

ハラちゃん「やまちゃ〜ん、あちらのお客様のジーンズ選んであげてくれない？」

おいら「ＯＫ〜まかせとけぃ」

お客というのは、おばちゃんとおじちゃん。おじちゃんのほうは、ちょっとデップリとしています。

おいら「今日はどんな感じでお探しですか？」

おじさん「・・・・・ウーン」

おじさん「ペ・ヨンジュンが穿いてるやつってどれ？？？」

おいら「・・・・・ってーと・・・・・」

おじさん「ほら、よく穿いてるじゃん。ストレートで、ゆったりめのやつ」

おいら（んーなんわかるわけゃねーだろ！ヨン様効果ってのは、おっさんにも影響するもんなのか）

おいら「ゆったりめでしたら、エドウィンの503z辺りがいいと思いますよ。色はどんな感じがよろしいでしょうか？」

おじさん「そーそー、こういうのだよ。おにいちゃん、わかってるじゃないの」

おいら（なんだ、コレでいいのか。ちょっと拍子抜け）

っとまぁ、こんな感じで接客は続き、結局はスタンダードジーンズを買っていってくれたあのお客。今日もどこかで冬ソナの再放送でも見ているんでしょうか。

話はそれますが、今日は、店の売り上げがキリが良くない数字で閉店したんです。あと2万円でキリが良かったのに…。と、バイトのおいらには何ら関係のない話。売り上げ金額のキリの悪さなんてのは、ハッキリ言ってどーでもいいんすよ。バイト代さえ貰えれば。

しかし、そのことで一人ヤキヤキしている人物が一人。店長です。

店長「やまちゃぁーん」

おいら「はーい」

店長「ちょっとさぁー、今日の金額、キリ悪いんだよねー。あと2万円で売り上げ○○まで取れるからさー」

おいら「・・・・・」

店長「なんか買ってってちょ」

おいら「はぁー？マジっすかぁ」

閉店間際、レジ締め直前に頼んでくるんですよ。直訳すると、あと2〜3分で1万円以上の気に入った商品を選んで、購入しろよってことになるんですが、こういうことは早めに言ってほしいっすな。商品整理もまだろくにできていない店内で、すぐになんて気に入った商品は選べません。

とは言いましても、約一名、どうでもいいキリの良さで悩まれておられる人がいるので、ここはひとつ、ちょっと気になっていたアディダスのジャージでも買ってやりますかぃ。と・・・・・考えてみれば久々のトップス購入になりました。

それにしても、アディダスの商品はスポーツブランドの王様だけあって、質感がいいっす。なんだかんだ、買ってよかったかも。

午前1時。やっと、バイトから帰宅です。ひぇー

今日は遅番、明日は早番。

オソ・ハヤに挟まれた夜ってのは、強制的に早寝をしないとマズいことになります。なんか書きたいのですが、今夜はとにかく、、、

寝ます！！！

64コンパイラは、ネイティブコードを構成する各オペコードをAMD64の規格へと変更しながら作られていくのですが、x86の機械語をAMD64の機械語にただ単に挿げ替えればいいということではありません。

先日、話題に出したように、レジスタは16個に増えるし、実数演算はSSE2を使うようにしなきゃならないですし、、、そんでもって本日の議題となるのですが、スタックフレームの扱い方についても、大きな変更点が生じるのです。

現状のABコンパイラ（Ver4.0 – 32ビット版）は、「最適化」という側面においては頭の悪い子だということはご承知のとおりですね。pushとpopしかしらないような、おこちゃまです。x86が持っている汎用レジスタはeax,ecx,edx,ebx,esp,ebp,esi,ebiの8本。esp,ebpはスタックフレームの制御に使ってるんで、実質上、項として扱えるレジスタはそれ以外の6本ということになります。うーん、これじゃ、ちょっと複雑な計算をコンパイルさせると、すぐに頭打ちしちゃいますな。

レジスタ数が足りないと、その足りない分をメモリで補うのがコンパイラのお約束です（っつか、そうしないと物理的に演算ができないんです）。

具体的に言うと、足りない分の値をpushし、スタックへと退避させることで演算中の値を保持します。そして、うまい具合に退避した値をレジスタに取り出しつつ、すべての演算をこなすというわけなんですね。

AMD64だって、レジスタ数は増えましたが、やはり複雑な演算式をコンパイラに通すと、たちまちレジスタは足りなくなります。となると、AMD64にアップグレードさせたところで、退避率は減っても、完全解消することはできないんです（完全解消させるとなると、.NETのCLRの話とかになっちゃうんでやめておきます）。

まぁ、CPUがどんなにたくさんのレジスタを積もうとも、理論的に限界が生じることは確かなようです。少なくとも、汎用レジスタが16本とかいっているウチは限界みえみえです。どっちにしても、スタックフレームにはお世話になるわけです。pushとpopには甘えなくちゃならんのです。

しかぁーし（｀△´）、この工程、ちょっとだけ疑って考えてみましょう。

pushをするっつーことは、それだけで下記の通り、二つの動作をCPUにさせるということになります。※ここでは、AMD64の規格を例にお話します

1. レジスタの値をrspが示すメモリにコピー
2. rspに8を加算

「メモリに退避」を行うことが目的なんで、1番目の「レジスタの値をスタックポインタが示すメモリにコピー」はいいんですよ。しかしですよ、2番目のスタックポインタへの加算行為が許しがたい行為なんですよ。「退避」が目的なんで、アクセスの対象となるのはレジスタとメモリだけというのが理想的なんですが、それと同時にrspも書き換えられてしまうんですよね。

※誤解を招くといけないんで、断っておきます。pushに必要なクロックサイクルは1です。キャッシュミスなどの状況によって増えることがあるのかわからないっすけど、おおよそケースにおいて、pushは最小タイムで完了します。

rspが変動的であると、rspをベース値にしたオフセットを自由に扱えなくなる恐れがでてきます。AB4コンパイラでは、区間内でespが変動的なので、ebpをスタックフレームのベース値（ローカル変数フレームのベース値）として採用することで、この問題を回避しています。

ここから、x64の規格のお話に突入していきます。

もしも、もしもです。区間内で必要なスタックフレームのサイズがわかったとしたら、どのような利点が生まれるのでしょうか。ちなみに、ここで言う区間とは、ひとつの関数だと考えてもらって結構です。

スタックフレームのサイズがあらかじめわかっていれば、その区間の始めと終わりに下記のような命令を入れてしまえば、rspを変動させずに済みます。

sub rsp,(スタックフレームサイズ)

...処理

add rsp,(スタックフレームサイズ)
ret

区間内ではあらかじめフリーなスタックフレーム領域が確保されるので、いちいち、rspを変化させてしまうようなpush/popを使わなくてもよいことになります。

push/popの代わりに何を使うかというと、そいつはズバリ、mov命令なんです。rspをベース値にしてスタックフレーム内のオフセット値を指定してやればいいんですよ。

push rax   ;退避
...処理
pop rax   ;復元

raxを保持したい場合には上記のような書き方をしていましたが、今後は下記のようなrspが変化しない書き方に変わります。

mov qword ptr[rsp+オフセット], rax   ;退避
...処理
mov rax, qword ptr[rsp+オフセット]   ;復元

この話は、演算中に不足したレジスタ値を退避するだけにとどまりません。実は、関数の呼び出し規約に深くかかわってくるのです。

x86の環境では、標準の呼び出し規約（_cdeclや_stdcall）はパラメータの引渡しをすべてpushしていましたが、AMD64の環境では、第4パラメータまでは汎用レジスタ、以降のパラメータはスタックフレームにmovすることで実現しているんです。新しい呼び出し規約にスムーズに対応するためには、スタックフレームの先立った確保は必須になります。

なんだかんだで、こういう部分のケアが64コンパイラの製作では必要だってことです。アーキテクチャが変わると、根底から覆されてしまいますな。今回は、x86→AMD64という、互換性がかなり重視された環境化での移行作業ですが、もし仮にまったく別物のCPUに対応させようともなると、考えるだけで恐ろしいものがあります。

Itaniumあたりにはお願いしたいところです。おこちゃまにもわかりやすいアーキテクチャであってくれと・・・・・

さてさて、自分で読み返すのが大変になってきたんで、今日はここらでやめときます。

ともかく、AMD64の新規格に対抗しながらのAB5×64コンパイラは、最適化の問題を最低限クリアしたものになりそうなことは確かなようです。この技術、追々は32コンパイラでも生かしたいものです。

最近、どうしても解決できない悩みに直面しているんです。それは、言語仕様設計に関することでも、64ビットネイティブコードに関することでもありません。

そう、それは、作業量。

どんなに賢く、どんなに努力して時間を有効活用して開発に取り組んでも、おいらが一日辺り、入力できるコードの量には上限があります。ABはその規模からすると、冗談でも一人で作るような代物ではありません。ソースコードを見返すと、今まで無事にやってこれた自分が不思議でしょうがないのですが、今後はこの不思議な現実に甘えていてはダメです。というか、おいらの役不足が原因でABは廃れることでしょう。

それじゃ、オープンソース化しちゃえばいいじゃん。ライセンスとか取り決めてさ、誰もが自由に改良できて、素晴らしい環境に皆で仕立てていけばいいじゃないのよ！

それはもっとも筋が通った、最近の流行をも意識させるご意見ではあるんですが・・・・・

おいらはそこまで人間ができていないので、どうしてもそこへ踏み込むつもりになれません。個人で作ったにしちゃぁ、でかいソフトかもしれません。しかし、実際の市場へリリースしていこうとなると、こんなのは吹けばなくなるようなチッポケなものです。そこを打破するには、おいら一人じゃ無理なことはわかってるんです。わかってるんですが・・・・・

こうやってですね、このオープンソース化計画は闇に消えていくんですよ。翌日はケロッとしながら64コンパイラの製作に精を出してしまい、そんなこと忘れてしまったりするんです。

皆さんご承知かと思いますが、おいらは貪欲です。ユーザー様、お客様が喜ぶソフトウェアを世に送り出したい気持ちは人一倍持っておるつもりではありますが、皆さんが思うほどお人よしではないんです。

まぁね、悩んでいてもはじまらないですからね。自分、協力者、ユーザー様方にとって一番良い方法は必ずあるはずです。おいらはそいつを早いうちに見つけなければなりません。それは必ずしもオープンソース化とは思っていませんが、もしかしたらそれに近いものがあるのかもしれませんな。

今の段階で、おいらが描く具体例を提示してしまってよいものかどうか、いささか疑問ではありますが、ここは雑談ブログ。あること無いこと、書いてきます。

〜理想像〜

ユーザー会なるものを発足し、信頼のおける、やる気のある協力者を集め、その内部でのみ、ソースコードの開示、改良を行っていきます。外部に対してオープンソースを行うわけではないので、ユーザー会でやり取りするソースコードの利用規約はちょっと厳しいです。っつか、これは “オープンソース” とは言わず、”仲間を増やす行為” なだけですね(^^;;;

・改良部分の著作権は改良者が有する

・ABそのものの著作権はおいらが有する

・バイナリコード・ソースコードの二次配布は禁止

・ユーザー会への入会・脱会はおいらの独断で決まる

実際の作業は、VSSやCVSなどを使ってバージョン管理と作業の排他制御を行いながらやればいいんでしょうか。専用のMLも用意する必要がありますな。複数人数での作業をしたことがないんで、これをやるとなると・・・・・まだ自身ないっす。

しかも、ABを構成しているソースコードはお世辞にもキレイにものではありません。他人が見て理解できるものかどうか…これが一番ネックになりそうかな〜。

ともかく、オープンソースに関する知識は無いに等しい状態なんです。勉強を重ねて、自分の意見をより明確にしていかなければならないです。

行って参りました、内定式！AM10:30集合だったんで、結構早起きです。

まず、一つ目のドッキリは朝っぱらから。

数日前、大学の友人、ごっつぁんがおいらんちに車を置かしてほしいといってきたんで、二つ返事でOKしたんですね（おいらんちは新富士駅の近くなんで…）。その日にあたるのが今日で、もちろん、行き先までは聞いていなかったんです。おいらが朝起きた直後、玄関のベルが鳴ります。

こんな早くからだれだぁ〜、と思ったら、ごっつぁんでした。しかも、スーツ姿。

・・・・・もしや！！！

おいら「今日はなんだい、内定先の会社にでも行く日なの？」

ごっつぁん「そうだけど。今日一日車置かしてよ」

おいら「まさか、新幹線で東京行ったりする？」

ごっつぁん「そうだよ。新幹線は8:18発のだよ」

おいら「マジ！？オレもその新幹線のるから、10分まっとって」

こんな感じでですね、一人でムッスリと乗るはずだった新幹線にはごっつぁんと乗ることになったんですよね。もしかして、今日はついている日なんかと思いながら内定式の会場へ着いた瞬間・・・・・

な〜んかですね、見慣れた顔がそこにはあるんですよね。。。。。

おいらはそいつに気づき、そいつもおいらに気づき、数秒間、互いに「え、オメェなにやっとんよ！？」という状態だったんです。

そいつの正体は高校時代の同級生のナガサワ。

まさかですねね、この就職戦線でですね、内定先の会社で高校時代の友達に会うとはですね、思うわけがないんですね。着慣れないスーツを着てまでして内定式へ着たにもかかわらず、受付の段階で気が抜けたおいらたち…。二つ目のドッキリはこんな形でおいらを楽しませます。

結局、内定式の中核をなす内定書授与なんてのは10分ちょいで終わってしまい、あとは和気藹々とした時間をすごします。懇親会で仲良くなったやつらとも話しをし、ランドマークタワーの最上階を散歩したりと、おれたちゃぁ何しにきたんよ、とお堅い雰囲気を忘れさせてくれるような会社さんには感謝感謝です。

後は入社前教育についての説明を受け、帰路へと着いたおいらなんですが、まだ本日最終、三つ目のドッキリが残ってるんですよ。

新幹線の中で寝いていると、ケータイが鳴ります。だれだぁ〜と思いながら画面を見ると「カトー」の表示が！そう、おいらの師匠である司法人カトーさんです。

すかさずデッキへと出て電話をかけなおします。電話の向こうでは、なにやら聞きなれた音声案内が流れています。

電話の向こう 〜○×番線に電車が参ります。黄色い線の内側に下がって・・・・・〜

カトーさん「山ちゃん、今日はバイトなの？」

おいら「今日は内定式で、今帰ってるところなんです。新幹線の中からですよ〜」

カトーさん「マジ！？オレ、今静岡駅であと10分くらいで新富士まで着くんだけど」

おいら「ってそれじゃ、改札で会っちゃうんじゃないっすか？こっちもあと10分くらいで新富士ですよ」

そう。今日の締めくくりは、帰りの電車です。おいらは下り線、カトーさんは上り線で新富士を目指しているんです。しかも、到着時刻はほぼ同時。おいら乗ってる新幹線が駅に着くと、反対車線にはすでに電車が止まっとりました。

すたこらと改札へ向かうと、そこにはカトーさんの姿が。なんでしょうね、この絶妙なタイミングは。まぁ、この後は2時間ほどいつもの調子でくっちゃべりながら、一日が終了したというワケです。

ZZR1200を手放して1年3ヶ月(ノ_<。) ポカポカした日曜日なんかにバイクの大群見ると未だにウズウズしちまいます…。

いつかはリターン。しかし、いまさらスピードを追求するのもあれなんで、スーパースポーツは選び辛いんです。じゃあ、アメリカンでゆったり走ったら・・・・・それだったら車買い換えたいっす。

ZX-10RやCBR954とか、速さに関してすばらしいバイクはまだまだあるんですが、ZZR1200も最速系のジャンルには含まれることでしょう（ツアラー系にも属しますが）。結局、遠出気分が湧き出てくるような、バケモノのようなスペックを誇るバイクはおいらの中でZZR1200以外にはないんです。

ということで、バイクを買いたいと思っても、次に選びたい車種が決まらないんです。社会人になってもしお金に余裕ができたら、次にバイクを買いたい衝動に駆られたときのために心の中で車種を決めておきたいものです。

そんなことを考えながら、な〜んとなくKAWASAKI@USAのサイトを見ると、あるではありませんか！ZX-14！！！

http://www.kawasaki.com/product_detail.asp?product=135&tag=motorcycle

ZZR1200を超えるバイク。こいつしかないです。おいらは将来、バイクにリターンすることがあったら、このバイクを買うことにします。ローンを組んでまでして、買います。生活をかけてでも・・・・・（いけない、いけない、いつもの悪いクセが…）

さてさて、もうアメリカではZX-14という名で売られているんでしょうかね。気になるお値段は$11,499とあります。本日の円レート（1$ = 113.49円）で計算すると130.5万円なり。たけぇーーー

ググッてみると、国内で手に入れたという情報はまだ無い模様。逆車ルートの確保はまだされていないんでしょう。どうやら2006年モデルでZZR1400という車名で出てきそうです。っとその前に、今月開催される東京モーターショーで出展されますな。モーターショー、まだ行ったことないんで、今年はなんとかして足を運びたいもんです。

夜中だっつーのに、熱くなってしまいました。

明日は中日残念セール真っ只中、バイトに精をだします。風呂はいって寝るかぁー