« May 2008 | Main | July 2008 »

2008.06.30

今日の日記

・長門のUART
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1017326745
こういうの見ていると、UARTの回路説明とか需要あるのだろうか。
最初のバージョンはバグがあるので、こっち使ってくださいね。質問もOKですよ。
(長門の)UARTを作ろう! その2
Verilog+UARTではなく、長門+UARTで検索するのが正解

・FPGAのコンフィグ
いやいやいや、分かる人にしか伝わってないwww
http://blogs.dion.ne.jp/sunagimoutchy/archives/7300256.html
こういうのは大好きだったりする。

・Googleの人のありがたいお言葉
Sergey:「The more you stumble around, the more likely you are to stumble across something valuable」

・ランディ・パウシュの「最後の授業」の日本語字幕
ひげぽんさんの所で紹介されていてずっと見たかったのだが、ようやく時間が取れて見る。
最後がずるい。最初と言っている事が違う。7時30頃から会社で見だして、業務時間始まっているのに大泣きする。僕はこんな良いメッセージを残せるかな。

・多分影響された
久しぶりに土日を休む。嫁が買い物に行っている間に、3歳の娘と留守番をする。
突然娘がガムテープを取り出し、畳の間に謎の模様をぺたぺた貼り始めた。
「娘が実はハルヒで宇宙人を呼んでいる→将来娘の友達として長門がうちに遊びに来る」という可能性を感じたので、あえて手伝ってみた。一息ついたところで、
僕「これ見たらお母さんどう思うかなぁ」
娘「(困った顔で、怒られるのが分かるので黙っている)・・・」
僕「お母さん、怒るかなぁ。でも、帰ってくるまで片付けたら大丈夫ちゃう?」
娘「ドアがカチャってなったら、お父さん片付けてや」
僕「それ無理(朝倉さん風)」

結局飽きて別の遊びをしている間に、ガムテープは全部はがして証拠は隠滅しておいた。幸せな土曜日でした。

| | Comments (4) | TrackBack (0)

2008.06.27

今日の日記

仕事が山を越えたはずが、土日を休もうとすると始発→終電コンボ。どっちか出社する前提ならずいぶんと楽になるんだが。1時頃に、「ちょっと打ち合わせ良い?」って付いていったら6時30分に解放とか酷すぎる。

そんな事はさておき、Google TechTalk 京都に申し込みました。「ソフトウェア開発者、研究者、学生の皆様」には、該当していない気がするのですが、とりあえず行ってきます。
Twitterの人達に会えるのも楽しみです。
http://twitter.com/yaotti/statuses/844746458

関西でARMプログラミング勉強会とか出来ないだろうか?家に余っているGBAと、西田さんのLinuxから目覚めるぼくらのゲームボーイ!が教科書なら、そこそこ遊べると思う。同じFPGAボードやマイコンボードを人数分揃えるのは大変だけど、GBAならすぐそろいそうだし。共通プラットフォーム大事。

ぱた☆へねが更新されないのは某社の陰謀。あきらめて次の問題を解く。

プリプロセッサ→字句解析→構文解析じゃなくて、字句解析→プリプロセッサ→構文解析でも良いよね。プリプロセッサを通る前のファイル名、行番号を保持するなら後者の方が楽。`define、`undef、`defineの再定義コンボも元の情報を保持したまま楽に抜けられれそう。

最新版のOpenSparcのtar.bz2は、Lhazで復元可能。eoやcygwinのtarではエラーがでる。

| | Comments (0) | TrackBack (0)

2008.06.23

VMの本を見てみた

レジスタマシンとスタックマシンを整理するために、Virtual Machinesを眺めてみた。Googleの検索結果をまとめてレポートを書く学生みたいだが、気にしないことにする。

7章から
・VMへRTM(Register Transfer Model)を使うのは比較的新しい話である。Parrotが最近の一番大きい実装。ほとんどのVMは、スタックベースである。Pascal-S、Pascal-P4、UCSD Pascal、Smalltalk、Javaこの辺りは、全てスタックベースのVM。

・スタックベースはスタックに対して操作を行うので、zero-address architecturesとも呼ばれる。zero-address architecturesのprimary competitorがRTM。違いは演算対象/オペランドにある。リアルプロセッサでは、x86は両方の特性を持つハイブリッド仕様。shinhさんの指摘通り。

・VMの場合スタックへのアクセスがボトルネックになる。VMでは好きなだけレジスタをもて、何かしらの配列で実装されるだろう。VMのレジスタは、実機のレジスタか、(サイズが分かっているなら)キャッシュに割り当てて最適化できる。Theoriaさんの考察通り。

・RTMの欠点。(1)コンパイラのコード生成が大変。(2)実機のレジスタを割り当てる場合、実機が持っているレジスタより少ない数しか使えないから、パフォーマンスの向上は少ししかない(3)スタックマシーンに比べると、実装が難しく実行時のコードサイズが大きくなる。(4)スタックを使わない限り、関数呼び出しの方法(引数と戻り値の渡し方)が制限される。(5)経験的にRTMの実装は特別難しいわけではない。が、RTMを作っても結局引数の問題、状態の保存などでスタックが必要になってくる。RTM用のコードを生成するコンパイラは、レジスタ間の転送だけでなく、スタックの操作を行う命令もできないといけない。

VMレベルでレジスタ構成してもスタックとの速度差がないから、頑張った割に意味が無いって事だな。速度差を出すためには、実機のレジスタやキャッシュサイズに会わせないといけない。これも面白くないし、頑張っても効果がない。なるほど。
組み込みプロセッサなら、1~2CLKでアクセスできる内蔵SRAMがあるから、そこにVMのレジスタを割り当てたらよさげ。と一つだけアイデア出して考察にします。

| | Comments (2) | TrackBack (2)

今日の日記

おかしい。山を越えたはずなのに忙しい。

・そろそろ僕のターン
EBNFをRacc形式に変換
ここを目標に頑張ろう!

きむら(K)さんにも本とBlogを教わる。ありがとうございます。
焦らない焦らない。

・Lisperの食べ物
継続だんごなるものを食べた。
Schemeのイベントのお菓子にしてみてはどうだろう。

Google本を読んでみた
前半はふ~んと思いながら読む。あんまり興味が無いらしい。

中盤はSFの世界だな。通信が絶たたれてネットワークが分断されたら、過半数を支配している方が投票でマスターを決めるとか。失われたデータは何秒以内に自動的に復旧するとか。ラノベっぽい。

後半の電源の話や、HDDの故障の話は面白い。敷地で課金のデータセンターを、ラックにコンピュータ詰め込んで、破産させるとかGoogleすげー!!!。ATX電源の効率化とか、僕に言ってくれたらすぐ設計したのに。自分が作ったプロダクトでも、ATXコネクタ付いているけど、別に性能の良い電源を供給できる別コネクタが付いている。Google製のの電源も評価したいな、うちに売ってくれないかなぁ。

全体的には面白かったです。
いろんな逸話でソースがある場合は、しっかりと書いてあるのが素晴らしい。難しい話なのに、かみ砕いてわかりやすくなっていました。楽しく読めましたよ。

・仕事の効率が落ちている原因
僕のはてぶを見たら、なんとなく原因が分かった。

| | Comments (0) | TrackBack (0)

2008.06.20

今日の日記

・仕事の話
クオータス8、左下のフロー使いにくいよね。誰か同意して。

・ケイデンスがメンターを買収?
シンプリシティもそうなんだけど、外資の人ってこういうのが大変だよな。

・Pythonの色分け設定ファイル for Peggy
http://www.interq.or.jp/japan/s-imai/python/peggycrec.html
ありがとうございます。早速使わさせていただきます。

| | Comments (2) | TrackBack (0)

2008.06.18

今日の日記

・VMのレジスタとかスタックとか
http://d.hatena.ne.jp/scinfaxi/comment?date=20080617#c

ひげぽんさんのここに反応。
>かといってVMのレジスタを使うならそれはレジスタマシンだ!って話になってしまいますしね。
レジスタマシンとスタックマシンって、厳密に分けるような物じゃないと思っていた。

そもそも世の中にはスタックメモリなんて物は無くって、普通のメモリをスタックとして使っているだけ。効率の問題があってPUSH、POPな命令と専用のSPがあるだけで、やっていることはメモリアクセスと同じ。レジスタにしても同じでALUに直結しているメモリととらえると、操作の対象を指定してリード/ライトをしているだけ、本質的には変わらないはず。

実際、スタックとレジスタがごっちゃになっているCPUってのは世の中にあって、一番有名どころでSparc。これはレジスタがスタックっぽく動く。初代Niosはスタックの中にレジスタもローカル変数も全部持っていたけど、命令セットは普通のCPUと同じだった記憶がある。リアルなCPUでスタックとレジスタをごっちゃにしちゃうデメリットは、サイズの上限があること。100とか1000とかそういう単位でスタックがあふれることになる。レジスタとしてアクセスできる領域を増やすとコスト(お金)や速度の面で不利になる。

> alohakun
> 時代は IA-64 (笑) レジスタが 16 本とか 32 本とか 64 本とか 128 本あれば,何も考えなくても良い w

VMなんだから10000個レジスタ確保しちゃえばよい気がする。10000個で足りなきゃ、動的に追加で10000個確保しちゃえw。VMのレジスタ増やしたからって、お金取られるわけじゃないしね。

命令セットどうするよ、ってのは気がつかなかった事にする。

・アイマス
GO MY WAYってやっぱりフルコーラス版あるんだ。
で、Amazonに行ったらキャラ×歌の組み合わせがあって、自分の甘さを思い知る。好きなキャラの好きな歌だけ買うって出来ないのね。冷静にこれって声優さんが歌っているだけだよな~って思ったら負けなんだと思う。
どうするか・・・

| | Comments (4) | TrackBack (0)

2008.06.17

今日の日記

・ スーパークリエイターがSI業界で即戦力になれない理由
http://d.hatena.ne.jp/aike/20080615
読んでいて、あーなるほどと感心しました。もしSIベンダーが人材不足で困っているなら、この辺りの情報を公開していくのが良いと思う。そうすれば、コミュニケーション能力という曖昧な表現じゃなくて、本当に欲しいスキルが明らかになる。現場にあるバッドノウハウが共有できれば、現場の人達は別の所にリソース回せるし、少しは楽になるんじゃないかな。情報を出すことを良しとしない人がいるんだろうな。

LSIの設計も同じで、仕事に関わっている人に比べて情報が圧倒的に少ない。Verilogの合成、シミュレーション、検証手法、ARMプログラミング、AMBAの設計。せめて国内だけでも共有できたら、僕達の業界も楽になりそうな気がする。

・今日のアイマス
♪携帯取りだしポパピプペ、デートしてくれますか?
がエンドレスで流れている。これは危険だ。

「団結」って歌が、もろ会員番号の歌!
♪そろそろゆうゆも 食べごろだ~

・OKWave
しっかりした回答で驚く。
verilog HDL のレジスタ記述について
http://okwave.jp/qa4094109.html
微妙な表記があると、シミュレータは記述に正確な動きをするけど、FPGAは既存のリソースに割り当てちゃって同じ動きしない可能性はある。たとえばnegedge rst_x で記述して電源投入時からrst_xがLだとしても、FPGAはrst_x == 0の状態になりそう。

| | Comments (4) | TrackBack (0)

2008.06.14

今日の日記

・ビットフィールド
 ビットフィールドを上手く使っている例として、ワンチップマイコンのレジスタ設定を紹介しようとしたが、ルネサスもARMもデータシートのダウンロードに登録が必要だったので面倒になって止める。

ぎりぎりの所でやっていると、ちょっとしたことで嫌になる。ビットフィールド使うな。自分で論理演算しろ。

・新横浜
久しぶりに行ったら、原型が分からないくらい変わっていた。新幹線の出口から吉牛に行くのが大変だった。でっかい本屋はいまいち。ファーストキッチンの横の本屋の方が、いろいろ分かっている。本屋で本を選んでいるときに、ビックカメラの放送が聞こえるのが、あれほどイライラするものだとは思わなかった。

・アイマス中毒
歌(声)だけ、ゆうゆとまみまみに出来ないものだろうか?国生とか新田バージョンも作れば売れると思う。人妻でもOK。

・強み
アプリケーションが弱い。基板を作ったり、メモリコントローラ作ったりできても、仕事的に最終アプリまで持って行く事がない。前の前の会社でも、コンパイラの設定して、CPUブートして、ICEつなげて、必要ならOS立ち上げて、そこで終わっている仕事が多い。せいぜいハードウェアのセルフテストレベル。

いろいろ組み込んでアプリケーションまで持って行ける人は尊敬する。

| | Comments (0) | TrackBack (0)

2008.06.11

今日の日記

・泥の話/メモの話/フツウの話
結構な量を書いたけど、読み直してみたら上から目線の痛い文章だったので無かったことにする。
まとめると、みんな仲良くやろうぜ!

・FPGAボード
陰気な男でいいですか?から

Xilinx Spartan-3A Evaluation Kit が$39!
ダウンロードケーブル付属で、電源もUSBから取れるのか。

ダウンロードケーブルを付属すると高くなるのはしょうがないと思っていたけど、一個マイコンかまして普通のUSBケーブルでコンフィグレーションさせることで、上手くコスト下げているんだなぁ。気になるのが、普通のUSBケーブルだけでChipScope使えるのかどうか。

そのあたりがよく分からないので、最初の一台には勧めないでおきます。

・アイマス
♪Go My Way~
最近、良さがちょっと分かってきた。
女の子が可愛いのは素晴らしい。技術の進歩を感じますね。ただ、ゲームの内容がさっぱり想像できない。おにゃんこの歌を女の子が歌っているのは、全然違う歌の振り付けを編集してくっつけているのかな。才能の無駄使いっぷりが、ウィキノミクスを思い出した。
http://b.hatena.ne.jp/entry/http://www.nicovideo.jp/watch/sm1077035


・数学
http://d.hatena.ne.jp/snow-bell/20080531
レベルの差はあれ、誰もが悩んでいることですね。自分にとって必要な物を一個一個勉強していくしかしょうがないと思う。僕もブログでいろんな人にいっぱい教わっているので、「ここまで分かりました」的な事を書けば、誰かが教えてくれると思う。まあ、はじめからそれを期待するのは良くないですが。

僕の場合は、とりあえず分からないところは後回しにして、いろんな勉強をし続けるようにしています。勉強をしていく中で、本当に自分に必要なことってのは何回もでてくるので、ああこれが分からないと駄目だなとなってから本気で勉強します。少なくとも大学の教科書レベルであれば、頭が悪いからわからないって事は無いはず、が自分を励ます言葉です。

SICPは大学の数学も履修しているような大学生向けだから、主婦向けSICPとかあれば良いと無責任に言ってみる。平方根じゃなくて旦那の退職金を計算させるとか。

| | Comments (0) | TrackBack (0)

生まれてくるのが遅かった問題

http://d.hatena.ne.jp/shinichiro_h/20080607#1212846686
円の例えわかりやすい。

若い人がうらやましいのは優秀な人が多く感じるのと、もし自分が20代前半だったらC++普通につかいこなせるんじゃね?という「たられば」を考えてしまうから。もっと早く生まれたいってのは無いな。若い人がうらやましいのも、もう少し早く生まれていればというのも隣の芝生だと思う。

僕は一番面白いタイミングでエンジニアになれたと思ってる。僕が見ている前で、恐ろしい速度でFPGAが進化していって、今のFPGAの中にはPowerPCが何個も入っている。最大規模のFPGAは、一昔前の携帯やデジカメがまるまる入ってしまうだけの容量を持っていて、ぶっちゃけ一人、二人じゃ使い切れない。速度も無茶苦茶速くなった。で、このリソースを使い切るようなキラーアプリケーションが無い。

僕の頭の中には、やりたいことがいっぱいいっぱいある。基板の設計も出来るし、FPGAの回路もかける、CPUのプログラムも出来る。独立して会社起こして、やりたいことをやれる立場にある。これが20代前半なら、やりたいことがあってもスキルが追いついて来なかったと思う。やりたいことがいっぱいあって、できる立場にいて、今このタイミングでこの業界にいることに幸せを感じている。

今までは、優秀な人に驚かせられっぱなしだったけど、一生に一度くらいは世の中の人を驚かせたい。それがかなわないなら、アイデアを持っている人に対して自分の技術を提供しようと思う。もっとマイコンを!もっとFPGAを!

面白いのはこれからですよ。

| | Comments (0) | TrackBack (0)

2008.06.05

今日の日記

・Text Processing in Python
ときどきの雑記帖 i戦士篇
ええっ、せっかく買ったのに無料で読めるの。ちょっとショック。

・ゲーム
通勤途中にソーマブリンガーに夢中になって、全然本を読まない。幻霧ノ塔ト剣ノ掟のみを持ち歩けば、UIでいらいらしてゲームしない作戦に出る。結構成功している。


・デバッグではじめるCプログラミング
この本、他の言語でやったらもっと楽じゃないかな。例えばPerlとか。この内容なら、Perlでもforで回せば良いと思うし。

・Palmware
Pythonのif __name__ == "__main__":程度の小ネタをPalmに入れておくのに、良いPalmwareが無い。というか、ほとんど開発終了。Pythonって、インデントに意味があるから、モバ機のメモと相性が悪いな。
昔買ったNoteStudioの実行ファイルが奇跡的に見つかったので、これを使ってみようと思う。

・Twitter怖い
Cについて適当に返事したら、(上野氏)
ファボついていたのでフォローし返したら、バイナリハックの人
あろはさんの後輩だと思ってなれなれしくしたら、北海道ベンチャーの社長
おっぱいパブでフォローしたら、あこがれの大企業でカーネル本の翻訳者
とらドラの人だと思っていたら、スーパーハッカー。IronPythonの使い手。

twitterの発言だけで判断してはいけない。

| | Comments (0) | TrackBack (0)

デバッグではじめるCプログラミング

デバッグではじめるCプログラミング読みました。

ローグっぽいゲームを作りながらCの基本的なプログラミングを学んでいく本。

・超入門書を読んでもよく分からない。FizzBazzの問題をどうしてよいのかわからない。
・漠然とゲームを作りたいが、どこから始めてよいのか全くわからない。

人向けです。ここを読んでいる人は既に対象外かと。まわりに初心者にすらなれない人がいたら、この本を紹介してください。そんな本です。ハチロクな世代には需要があるかも。

前半はうだうだと進むのですが、途中から意外に面白くなってくる。ゲームを手探りで作っていく過程が見れて面白い。僕も最初のゲーム作りってこんな感じだったと思う。そんな懐かしい思いを感じながら最後まで読めました。最初はマップ決め打ちで画面に出していたけど配列を使ってデータ化したり、ここで配列やループを使うとすっきりかける事を発見したり、懐かしい感覚がいっぱいでした。画面に文字を表示させながら、if文やwhile文の動作確認とかみんなやったでしょ、それがずーっと書いてあります。

途中にあるゲームの仕様書(50ページ周辺)は面白い。なかなか違う業界の仕様書って読めないので、勉強になりました。メッセージ領域の仕様に「発話者は基本的にイーノ本人です」と書いてあって、誰がしゃべるかを仕様で決めるのは斬新でした。組み込みだとエラーメッセージは表示されるものであって、人格としての誰という概念は無いので。

全体を通して素晴らしいなと思ったところは、やり方は一つではないよ、としっかり書いてあることです。始めてプログラミングするときは、このやり方であっているのかが、すごく気になります。この本は、2つのやり方があるけど今の段階ではどっちでもよいよね、と書いてあってとりあえず動く物を作ろうというスタンスです。エディタを目の前にして、最初の一歩が書けない人には助かると思います。

今、ブログで難しい事を書いている人たちも、最初はこんな感じでゲーム作っていたんだと思う。で、真っ先に思い出したのが、k.inabaさん。
> といっても、あんまりまともに勉強してなかったので関数という概念の使い所が わかんなくて、 この頃の俺は全部mainの中に書いてました。5000行くらいあったんじゃないかな。独学って怖いですねー。
k.inabaさんですら最初はこうだったんだから、とりあえず動かしてみるのは大事ですよ。

この本に対する要望はいっぱいあって、順番に書きます。

・本のタイトル
怒られそうだが書く。
Cプログラムの中身がわかる本、と同じでタイトルは「C言語」にして欲しい。Amazonで検索できない。もっと言うと、デバッグを全面に出すよりは、最初の一歩とか、ゲームを作るとかを全面に出した方が良いと思う。このタイトルでは、初心者がこの本を最初の一冊に選ぶとは思えない。

・全体の構成
前半は雑談が多く、後半が息切れしているように感じます。前半の雑談を減らして、最後までしっかり書いて欲しい。雑談も、ゲーム業界の昔話でコラムを書いてもらった方が、本の内容にもあっていると思います。

・参考文献
巻末に参考文献があるのですが、読み物とCの本がごっちゃになっていて、どれから読んで良いのかがわからないです。コンピュータの事を知りたかったらこれ、もっとCの事を知りたくなったらこれ、と一行コメントが欲しいです。

・索引
せっかく具体的なエラーメッセージの理由と解決策が書かれているのに、索引から見つけることができません。エラーメッセージとそれが出てくる場所は、一覧表が欲しいです。

・CDROM
初心者向けなので、必要な環境はCDROMで入れて欲しい。BCCの入手先として「*本書の執筆時点では、作者のサイトから直接ダウンロードできないようです。インターネットをよく探すと見つかりますから、検索サイトなどで調べてみてください」はひどい。筆者というよりは、編集者の方でなんとかならなかったのだろうか。コンパイラが変わればエラーメッセージも変わるので、この本で勉強する以上BCCは必須。だったらCDROMで開発環境ごと付けて欲しい。BCCが配布出来ないなら、他のCコンパイラでも良かったと思う。

・ファイルの入出力
ゲームを作るのであれば、ポインターよりもこっちの方が優先順位高いと思う。セーブとロードは、入れて欲しかったです。

実際にはコードを打ち込んだ訳ではないのですが、打ち込んでいくとまだまだ出てくると思います。この本のプログラミングへの姿勢や取り組み方は素晴らしい物があるので、もうちょっと内容を整理すればもっともっと勧めやすい本になったと思います。実際に初心者の人にこの本で勉強してもらって、フィードバックかけると素晴らしい本になるんじゃないのかな。いまさらですが、月刊誌で連載→整理して出版の流れを取っていたら、同じ切り口でも違う内容になったと思います。

いろいろ書いたけど、僕はこの本好きですよ。

| | Comments (3) | TrackBack (0)

今日のぱた☆へね

Cのビットフィールドで足踏み。
gccのアセンブラ出力がそのままpcspimの入力として使えないので、変換のスクリプトをPythonで書いた。やっていることは、

・pcspimでエラーになって、そのまま削除しても良さそうな所を行ごと削除
.file .section .previous .globl .ent .ident .set reorder end .size
・sw $2,%gp_rel(data)($28) という謎の表記を、sw $2,data に変更。
・.comm receiver,4,4で確保しているメモリを、.data (改行)receiver: .byte 0 0 0 0で確保。bssだからこれでいいはず。

問題2.8はそれっぽく変換できた。もうちょっと他の問題で使ってから公開予定。すぐ欲しいって人はコメントよろ。テキスト処理って変数名のつけ方がよくわからん。で、pcspimでビットフィールドの操作を追ってみたら、教科書とbitの割り付けが違う。ビットフィールドとはそういう物だ、で1エントリーが書ける。

よい子はビットフィールド使わない方が良いと思うよ。参考:http://portable-c.jugem.jp/?eid=8

今日の結論:GCCが苦手

| | Comments (0) | TrackBack (0)

Verilog2005 の Compiler directives

VerilogのCompiler directiveの一覧。
[]の中は、IEEE Std 1364-2005で対応するセクション。

`begin_keywords [19.11]
`celldefine [19.1]
`default_nettype [19.2]
`define [19.3]
`else [19.4]
`elsif [19.4]
`end_keywords [19.11]
`endcelldefine [19.1]
`endif [19.4]
`ifdef [19.4]
`ifndef [19.4]
`include [19.5]
`line [19.7]
`nounconnected_drive [19.9]
`pragma [19.10]
`resetall [19.6]
`timescale [19.8]
`unconnected_drive [19.9]
`undef [19.3]

全部がプリプロセッサで処理しないといけないわけでも無いなぁ。
ぱっと見、`ifdef、`ifndef、`else、`includeだけ処理すればよさげ。ちゃんと規格書読もう。
ちゃんとしたパーサ作るって、言語仕様を押さえないといけないから大変だな。いまさら気がついたよ。適当に文法ファイル作ればOKかと思ってた。

| | Comments (0) | TrackBack (0)

2008.06.02

プリプロセッサと字句解析と構文解析と

今悩んでいるところをまとめてみました。
ターゲットはVerilogですが、伝わりやすいようにソースはC言語で整理してみました。

(1)やりたいこと
パーサを作って、ドキュメントやテストプログラムを自動生成したい。

(2)僕が理解している教科書的流れ
プリプロセッサ:全てのマクロを展開する。

字句解析:マクロが展開されたソースコードに対して、字句解析を行う。

構文解析:字句解析の後に、構文解析を行う

(3)困っていること その1
#define SIZE 5
int a[SIZE];

をプリプロセッサを通すと、int a[5];になってしまい、5という値が#define SIZE 5 によって展開されたという情報が無くなってしまう。

僕が作りたいプログラムでは、int a[SIZE];という情報も使いたい。

(4)困っていること その2
#include や#ifdefなどのディレクティブは最初のプリプロセッサで処理して、#define による置換はシンボルテーブル相当の物を作っておくのはどうか。

極端な例だけど、こんな変態的なマクロに対応できない。
#define SIZE 3];int b[2
int a[SIZE];

これくらいは普通にある。
#define SIZE ((FOO+BAR)/8)
int a[SIZE * 2];

(5)妥協できるところ
・構文解析が成功するかどうかは正確でなくても良い。別のコンパイラで、コンパイルが通ることを確認したソースのみをターゲットにする。
・int a[SIZE * 2]; であれば、展開後の値と"SIZE * 2"という文字列で定義されている、という2つの情報があればよい。
・最初は、配列の大きさだけが元の文字列との対応が取れていれば良い。当面これ以外では使わない。

(6)今気がついたこと
・SIZEが5の時SIZE * 2が10になる、という情報は構文解析だけじゃ駄目。次のステップが必要。教科書に戻らないといけない。
・[]の中は配列の大きさを与える文字列、として処理すればあっさり終わる気がする。実際、今までのツールがそうやって処理していた。その文字列に対して、toInt()とかgetSize()があればよい。(4)の極端な例は対応しない。

整理したらすっきりしましたよ。

| | Comments (10) | TrackBack (0)

« May 2008 | Main | July 2008 »