2009年07月03日
gccのtipsを紹介します。主にgcc3.x からgcc4.x で変わっているところです。
#include <stdio.h>
int main()
{
printf("Hello, world!\n");
}
このプログラムはgcc3では普通にprintfを呼び出すコードを生成しますが、gcc4ではどうなるでしょうか。ARM版のexeGCC4でちょっと試してみます。
2009年07月03日
1969 年に Bell Lab の Kenneth L. Thompson と Dennis M. Ritchie がプロトタイプを作成した時から数えて、今年は UNIX 40 周年の節目だそうです。UNIX の 1/4 世紀という本がありますが、あと10 年したら UNIX の半世紀ですね。
ちょっと昔の話をしたいと思います。35 年近く前の C の話です。（もちろん私は 20 代なので、まだ生まれてません。）1975 年、UNIX v6 がリリースされました (後の BSD UNIX につながる版です)。この版は pre K&R C という、現代の C (C99) から見ると非常に素朴な C で実装されています。
Dennis M. Ritchie, "C Reference Manual" (1975)
http://www.cs.bell-labs.com/who/dmr/cman.pdf
今日あたりまえのように使われている、void/unsigned/const/enum/union/volatile … ここらへんのキーワードが軒並み存在しません。（代わりに entry という謎のキーワードがあったりします。）
なんと、型のキャストという概念も存在しません。こんなんでまともなプログラムかけるのかな ? と思うかもしれませんが、Lions' Commentary on UNIX を読んでいると、いろいろと面白い技巧が垣間見れます。
参考サイト : 2238クラブ
キャストも unsigned も存在しないので、符号付き整数を unsigned で扱いたい場合は、ポインタ変数に代入してから計算していたようです。ポインタは unsigned ですから、アセンブラ的な感覚からすれば、unsigned というキーワードは無くても困りませんね :-)
rdwri.c
特定のメモリアドレスが定数として define されている場合、どのようにして参照すれば良いのでしょうか ? 今日の C ならば、*(int *)SW のように、ポインタへの型キャストを使えば良いわけですが、キャストは存在しません。
param.h を見てみますと。
いかがでしょうか ? 面倒で実用性が低い言語だと思われた方もいるかもしれませんし、パズル的で面白いと思われた方もいるかもしれません。
私には、pre K&R は、ある種のミニマリズム的美しさと実用性が奇跡のバランスで釣り合っている言語のように思えます。単に学術的な意味でのスマートな言語は他にもたくさんありますが、なんせ UNIX v6 を書いた言語なわけですから、やはり説得力が違います。
ちょっと昔の話をしたいと思います。35 年近く前の C の話です。（もちろん私は 20 代なので、まだ生まれてません。）1975 年、UNIX v6 がリリースされました (後の BSD UNIX につながる版です)。この版は pre K&R C という、現代の C (C99) から見ると非常に素朴な C で実装されています。
Dennis M. Ritchie, "C Reference Manual" (1975)
http://www.cs.bell-labs.com/who/dmr/cman.pdf
今日あたりまえのように使われている、void/unsigned/const/enum/union/volatile … ここらへんのキーワードが軒並み存在しません。（代わりに entry という謎のキーワードがあったりします。）
なんと、型のキャストという概念も存在しません。こんなんでまともなプログラムかけるのかな ? と思うかもしれませんが、Lions' Commentary on UNIX を読んでいると、いろいろと面白い技巧が垣間見れます。
参考サイト : 2238クラブ
キャストも unsigned も存在しないので、符号付き整数を unsigned で扱いたい場合は、ポインタ変数に代入してから計算していたようです。ポインタは unsigned ですから、アセンブラ的な感覚からすれば、unsigned というキーワードは無くても困りませんね :-)
rdwri.c
6323: /* Return the logical maximum
6324: * of the 2 arguments.
6325: */
6326: max(a, b)
6327: char *a, *b;
6328: {
6329:
6330: if(a > b)
6331: return(a);
6332: return(b);
6333: }
volatile はまぁ、この時代の C は PDP-11 マクロアセンブラみたいなものなので、もともとほとんど最適化は行われていなかったので問題は無かったのではないでしょうか。手で register のようなキーワードを使い、最適化を指示していた時代です。ある意味、C の成熟を象徴するようなキーワードだと思います。特定のメモリアドレスが定数として define されている場合、どのようにして参照すれば良いのでしょうか ? 今日の C ならば、*(int *)SW のように、ポインタへの型キャストを使えば良いわけですが、キャストは存在しません。
param.h を見てみますと。
0166: #define SW 0177570
0167:
0168: /* --------------------------- */
0169:
0170: /* structure to access : */
0171:
0172:
0173: /* an integer */
0174:
0175: struct { int integ; };
この意味を理解するには、pre K&R C の struct 内部のメンバーの名前空間が単一であるという仕様を知っている必要があります。単に先頭アドレスからのオフセットと、メンバーの型だけが意味を持ちます。そして、明示的なキャスト構文はありませんが、アセンブラ的な意味での暗黙の型キャストが行われます。アロー演算子 -> の左側にあるスカラ値は、問答無用で構造体へのポインタ扱いされます。整数型も文字型も一切型チェックは行われません。というわけで、特定のメモリアドレスから、整数型として値を参照したい場合は、SW->integ のようにして参照できるわけです。いかがでしょうか ? 面倒で実用性が低い言語だと思われた方もいるかもしれませんし、パズル的で面白いと思われた方もいるかもしれません。
私には、pre K&R は、ある種のミニマリズム的美しさと実用性が奇跡のバランスで釣り合っている言語のように思えます。単に学術的な意味でのスマートな言語は他にもたくさんありますが、なんせ UNIX v6 を書いた言語なわけですから、やはり説得力が違います。
2009年07月02日
開発メンバーの新人、若槻です。
去年の 11 月から、京都マイクロコンピュータ株式会社という、デバッガを作っている会社で働いています。
デバッガというと地味な感じがするかもしれませんが、本来ソフトウェア開発には無くてはならないものです。ところが残念なことに、プログラミングの教科書などでは、デバッガは全く触れられないか、非常にあっさりとした扱いで終わることがほとんどだと思います。また、初心者のうちからデバッガに頼ることを覚えてしまうと、ちゃんと脳内でプログラムの動きを想像して机上デバッグする癖がつかないので邪道だ、というような主張をする人もたまに見かけます。
そういう私も、この会社に入るまでは、それほどデバッガの必要性を感じていませんでした。しかし、今ではデバッガ無しでプログラムを書くことは大変もどかしく、苦痛に感じます。例えばよくある状況として、変数の値がおかしくなっているようだが、この変数への変更はどこで行われているのか調べたい、という状況があると思います。これをデバッガ無しで調べようと思ったら、ソースコードを隅々まで見なければいけないのでかなり大変 (見逃す可能性も高い) ですが、デバッガがあればデータブレーク機能 (特定番地のメモリの読み書きが発生した瞬間に止まる) で一発です。
デバッガ無しでプログラムを書くということは、例えるならば、CT や MRI などの最新医療機器を使わずに診察を行うことと同じように思えます。もちろん基本技術をきちんと習得することは重要ですし、問診や想像力を駆使し、聴診器一つ (printf デバッグ) で病気を診断するベテラン医師の能力は素晴らしいものですが、やはり直接内部を見ることができる確実性には代えられません。
私が会社に入ってすぐに先輩たちに言われて、いまでも強く印象に残っているのですが「仮説は重要だが、仮説はあくまでも仮説であって、(特に組み込み業界では)実際に動いているものだけが真実。プログラム上のロジックがいくら正しくても、もしかしたらハードウェアにバグがあるかもしれない。」という教訓があります。いくら仮説の上に仮説を積み重ねていっても、いつまでたっても砂上の楼閣です。デバッグの際には、確実性をコツコツと積み上げていくことが何よりも重要です。これもまた最近辻先輩に言われたことですが「デバッグとは怪しいところを闇雲に探すことではなく、確実なところを探すことだ。」至言だと思います。
また、デバッガは、バグを発見するためだけではなく、ソースコードを理解する際にも非常に有益です。GCC や Linux のように、大量の ifdef でソースコードが切られている場合、そもそもどの行が実際に実行される有効行なのか ? ということすらわかり難く、下手をすると全く関係ないところを延々と見ていたということにもなりかねません。当然のことながらデバッガを使えば、実際に動いているところだけを直接見ることができます。
先輩方に比べて、まだまだ知識も経験も浅い若輩者ですが、私がこの会社に入って感じたことや得た経験を書いていくことにより、一人でも多くの人にデバッガ（開発）の魅力を伝えていくことができたら良いなと思います。
去年の 11 月から、京都マイクロコンピュータ株式会社という、デバッガを作っている会社で働いています。
デバッガというと地味な感じがするかもしれませんが、本来ソフトウェア開発には無くてはならないものです。ところが残念なことに、プログラミングの教科書などでは、デバッガは全く触れられないか、非常にあっさりとした扱いで終わることがほとんどだと思います。また、初心者のうちからデバッガに頼ることを覚えてしまうと、ちゃんと脳内でプログラムの動きを想像して机上デバッグする癖がつかないので邪道だ、というような主張をする人もたまに見かけます。
そういう私も、この会社に入るまでは、それほどデバッガの必要性を感じていませんでした。しかし、今ではデバッガ無しでプログラムを書くことは大変もどかしく、苦痛に感じます。例えばよくある状況として、変数の値がおかしくなっているようだが、この変数への変更はどこで行われているのか調べたい、という状況があると思います。これをデバッガ無しで調べようと思ったら、ソースコードを隅々まで見なければいけないのでかなり大変 (見逃す可能性も高い) ですが、デバッガがあればデータブレーク機能 (特定番地のメモリの読み書きが発生した瞬間に止まる) で一発です。
デバッガ無しでプログラムを書くということは、例えるならば、CT や MRI などの最新医療機器を使わずに診察を行うことと同じように思えます。もちろん基本技術をきちんと習得することは重要ですし、問診や想像力を駆使し、聴診器一つ (printf デバッグ) で病気を診断するベテラン医師の能力は素晴らしいものですが、やはり直接内部を見ることができる確実性には代えられません。
私が会社に入ってすぐに先輩たちに言われて、いまでも強く印象に残っているのですが「仮説は重要だが、仮説はあくまでも仮説であって、(特に組み込み業界では)実際に動いているものだけが真実。プログラム上のロジックがいくら正しくても、もしかしたらハードウェアにバグがあるかもしれない。」という教訓があります。いくら仮説の上に仮説を積み重ねていっても、いつまでたっても砂上の楼閣です。デバッグの際には、確実性をコツコツと積み上げていくことが何よりも重要です。これもまた最近辻先輩に言われたことですが「デバッグとは怪しいところを闇雲に探すことではなく、確実なところを探すことだ。」至言だと思います。
また、デバッガは、バグを発見するためだけではなく、ソースコードを理解する際にも非常に有益です。GCC や Linux のように、大量の ifdef でソースコードが切られている場合、そもそもどの行が実際に実行される有効行なのか ? ということすらわかり難く、下手をすると全く関係ないところを延々と見ていたということにもなりかねません。当然のことながらデバッガを使えば、実際に動いているところだけを直接見ることができます。
先輩方に比べて、まだまだ知識も経験も浅い若輩者ですが、私がこの会社に入って感じたことや得た経験を書いていくことにより、一人でも多くの人にデバッガ（開発）の魅力を伝えていくことができたら良いなと思います。
2009年07月01日
以前少しはまってしまったのですが、Linux kernel 2.6.29 は、gcc 4.1.[01] ではコンパイルできなくなったようです。
エラーメッセージを頼りに linux-2.6.29/include/compiler-gcc4.h を見てみると、なるほど。
どうやらミスコンパイルが起こるので、はじかれているようです。
この時に入ったようですね。
http://kerneltrap.org/mailarchive/git-commits-head/2009/1/2/4576264/thread
Linux Kernel 2.6.28 のリリースが 2008 年 12 月で、2.6.29 のリリースが 2009 年 3 月ですから、その間に入った変更のようです。
エラーメッセージを頼りに linux-2.6.29/include/compiler-gcc4.h を見てみると、なるほど。
/* GCC 4.1.[01] miscompiles __weak */
#if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
# error Your version of gcc miscompiles the __weak directive
#endif
どうやらミスコンパイルが起こるので、はじかれているようです。
この時に入ったようですね。
http://kerneltrap.org/mailarchive/git-commits-head/2009/1/2/4576264/thread
Linux Kernel 2.6.28 のリリースが 2008 年 12 月で、2.6.29 のリリースが 2009 年 3 月ですから、その間に入った変更のようです。
2009年07月01日
blog.kmckk.comを訪問してくださった皆さま。
こんにちは、はじめまして。京都マイクロコンピュータの辻です。
この度、僕たち京都マイクロコンピュータ(KMC)でも、BLOGを利用してメッセージ発信をして行こう、という事になりました。
皆さま、今後ともよろしくお付き合いください。
このBLOGでは、製品に関する技術・サポート情報なども取り扱いますが、直接に製品とは関係のない色々な事を取り上げていくつもりです。
このBLOGですが、訪問して頂いた皆さまと共に成長していきたいと思っておりますので、コメントなどもよろしくお願いいたします。
2009年7月1日
京都マイクロコンピュータ株式会社
スタッフ一同
こんにちは、はじめまして。京都マイクロコンピュータの辻です。
この度、僕たち京都マイクロコンピュータ(KMC)でも、BLOGを利用してメッセージ発信をして行こう、という事になりました。
皆さま、今後ともよろしくお付き合いください。
このBLOGでは、製品に関する技術・サポート情報なども取り扱いますが、直接に製品とは関係のない色々な事を取り上げていくつもりです。
このBLOGですが、訪問して頂いた皆さまと共に成長していきたいと思っておりますので、コメントなどもよろしくお願いいたします。
2009年7月1日
京都マイクロコンピュータ株式会社
スタッフ一同
