本の虫: Clang VS 自由ソフトウェア
オープンソースで有名なEric S. Raymondが、自由ソフトウェアで有名なRichard Stallmanに、GCCのアンチプラグインポリシーについて突っ込んでいる。 GCCは、長年、コンパイラーのモジュール化を政治的な理由で行っていなかった。もし、例えばパーサーや意味解析だけを分離して使えるようにしたり、内部表現を規格化したりしてしまうと、GCCの一部が、不自由なソフトウェアに取り込まれたり、あるいは不自由なソフトウェアがGCCのプラグインという形で入り込むことになってしまう。これは、利用者の自由を第一とする自由ソフトウェアにとって、悪夢のような未来である。そのような未来を未然に防ぐために、政治的な理由で、GCCのはプラグインに反対するポリシーを採用している。もし、GCCを改良したければ、自由なソフトウェアとなるべきなのだ。そして、GCCのプロジェクトに参加するべきなのだ。 とはい
GCC, the GNU Compiler Collection The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Ada, Go, D, Modula-2, and COBOL as well as libraries for these languages (libstdc++,...). GCC was originally written as the compiler for the GNU operating system. The GNU system was developed to be 100% free software, free in the sense that it respects the user's freedom. We strive to
LLVM/Clangがぜってーサポートしねーと宣言しているLinuxカーネルに多用されているGCC拡張
[Phoronix] LLVM/Clang 3.3 Should Be Close To Building Linux Kernel LLVMLinux Bug 9254 – clang can't build iptables in Linux kernel: error: fields must have a constant size: 'variable length array in structure' extension will never be supported ClangでLinuxカーネルをビルドできる状況は、多くの勢力に望まれてきた。理由は様々だ。Clangはビルド時間が短い。静的解析による警告も優れている。ソースコードも綺麗だ。複数の独立した実装でコンパイルできるコードは、誤りを静的に発見しやすい移植性にも優れる。より優れたコピーレフトなライセンスであるGPLv
For full functionality of this site it is necessary to enable JavaScript. Here are the instructions how to enable JavaScript in your web browser.
OCaml 2010年01月22日 GCC ARM バックエンドの中の O’Caml プログラム GCC のソースツリー中の gcc/config/arm/ 以下には、OCaml という関数型（プログラミングを支援する）言語 ML (Meta-Language) の方言で書かれたプログラムが存在しています。 NEON 命令のためのヘッダ、テストケース、ドキュメントなどを生成するために O'Caml プログラムが使われているようです。 Contents of /trunk/gcc/config/arm/neon-gen.ml Contents of /trunk/gcc/config/arm/neon-schedgen.ml/a> Contents of /trunk/gcc/config/arm/neon-testgen.ml Contents of /trunk/gcc/config/a
clangというのはllvm向けのC/C++/Obj-Cのためのフロントエンドで、最近はGoogle ChromeとかFirefoxもコンパイルできるレベルにまで成熟してきているらしい。 いくつかのブログで紹介されているのを見ても、ふーん、ぐらいにしか思っていなかったのだが、あんな大規模なソフトウェアがコンパイルできるというのは、考えてみるとすごいことである。大事なことなので強調しておくが、すごいことである。十分に実用的なレベルに到達していることだ。ビルドも早いし生成されたコードもg++と同程度には速いというし、試してみる必要がある。 という訳で、いくつか実際にソフトウェアをビルドしてみた。試してみた限りでは、 libstdc++のtr1/unordered_mapがビルドできない C++のコーナーケースで、clangが許容しないものが多い といった問題があったが、割とどれもすんなりとコン
GCCや多くのコンパイラーは，C言語の標準(C99)にインライン関数が取り込まれるずっと前からインライン関数をサポートしていた。そのためかインライン関数の定義は様々で，同じ書式でも各コンパイラで挙動が異なる場合がある。 今回は，インライン関数の定義をまとめ。それぞれ出力されるアセンブラコードを比べてみる。 概要 先頭に inline という言葉を付けて関数を宣言すると，コンパイラーはそれをヒントにコードをインライン化――関数のコードを呼出し元に展開する。これにより，関数呼び出しのオーバーヘッドが取り除かれ実行が早くなる。 inline はコンパイラに対するヒントであって指示ではないから，様々な理由からヒントが無視され，インライン化されず実際の関数として出力される場合がある。例えば，その関数のアドレスが参照される場合や，関数定義内の再帰呼出しなどはインライ化できないし，コンパイラーの最適化を
忙しさにかまけてここの存在をしばらく忘れてしまっていました。 ここんとこ色々なコンパイラを読んだり書いたりしているのですが、構文木の実装にもいろいろなやり方がありおもしろかったので書いときます。読んだ処理系にだいぶ偏りがありますがご了承ください。 バリアントを使う 関数型言語で言語処理系を作るならやはりバリアントでしょう。 例えばocamlならば type expression = { pexp_desc: expression_desc; pexp_loc: Location.t } and expression_desc = Pexp_ident of Longident.t | Pexp_constant of constant | Pexp_let of rec_flag * (pattern * expression) list * expression | Pexp_funct
科学者とあたまを書いたひとだけれども、この名前どっかで聞いた事があるなと思ったら, 昨日劇団青年座の人の講演で聞いたのだった。 「フユヒコ」という劇団青年座の公演が明日NHKで放送されるらしいです。冬彦ってのは寺田寅彦のペンネームらしい。 http://cgi4.nhk.or.jp/hensei/program/p.cgi?area=001&date=2008-12-12&ch=31&eid=9950 おもしろそうだから観てみようかな。 ところで小柴先生が同じような事を言っていたのを思い出した。このインタビューは面白い。 一流の理論家は、「自分の理論では、ここまでは使えるけれど、これから先は分からない」という適用限界をいつも意識している。ところが二流の理論家というのは、自分が名前を覚えた、あるいは、使った理論で何でもやれると思ってしまう。二流の理論家に困らされるのは、新しい実験計画が出てき
先日、 プログラムの動作をトレースするツールとして ftrace を公開しました。 その後 KLab では引き続き機能拡張を行っており、関数に渡された引数を表示 するような改良を行いました。引数が解ると自作した関数の意図しない動作を 追うときにとても便利そうです。 以下からダウンロードしておためしください ftrace-0.92.tar.gz 注意点 x86(32bit) な環境でしか動作しません デバッグ対象のプログラムは -g と -finstrument-functions フラグを付けてコンパイルされている必要があります。 依存するライブラリは glib1.2, libelf, libdwarf です debian sarge の方は $ apt-get install libglib1.2-dev libelfg0-dev libdwarf-dev を実行すると ./config
C言語で書かれたソースコードを読んでいるとき、関数ポインタから呼び出されている機能の実体がどこに書かれているのかを探すのに苦しんだ経験はありませんか？ 私はあります、いっぱいあります！！ そんなときはどうするかというと・・・ 手順１： まずは気分転換をする！ 手順２： そして気合いを入れ直す！ 手順３： さらに気力で読み砕く！ 手順４： 最後に根性で発見する！ これが、ごく一般的な作業手順(?)かと思います・・・（ごめんなさい嘘です） でもまあ、実際にここまで出来れば、そのプログラムの大まかな構成とか癖みたいなものはだいたい把握できているはずなので、他の関数ポインタについてもある程度当たりをつけて見つけだすことが出来るようにはなるかと思います。 ・・・・・が、、できれば気合いと根性を使わずに追えるなら追いたいのが人情ですよね。 straceやltraceを使えばシステムコールやライブラリコ
普通のやつらの下を行け: Cで動的コード生成・実行 スクリプト言語には動的にコードを生成して実行する機能を持ったものが多くあります。 普通のやつらの下を行けの第3回として、今回は C による動的なコード生成と実行に取り組んでみたいと思います。 今回書いたコードの main() 関数は以下のようなものです。 int main(int argc, char **argv) { assert(argc == 2); define(int, add, (int x, int y), "{ return x + y; }"); define(int, mul, (int x, int y), "{ return x * y; }"); define(int, add_argv1, (int x), "{ return x + %d; }", atoi(argv[1])); printf("%d\n"
普通のやつらの下を行け: assert_caller() 以前に、低レベルプログラミングを愛好する知人が「普通のやつらの下を行け」を口癖にしていました。当時は何を言っているのかと聞き流していましたが、自分も最近になってようやく低レベルプログラミングのおもしろさがわかってきました。今回は「普通のやつらの下を行け」企画の第一弾として assert_caller() なるものを作ってみたいと思います。 assert_caller() とは assert_caller() とは、特定の関数からの関数呼び出しだけを通すためのアサーションです。たとえば、次のように foo() の先頭で assert_caller(main) と書いた場合、 foo() は main() からしか呼び出せなくなります。他の関数から foo() を呼び出した場合はエラーメッセージとともに異常終了します。 void foo
2010年03月11日 Clang と LLVM を使ってみる。 前回は Clang フロントエンドだけをビルドしました。 今回は LLVM もビルドして、実際に使ってみます。とはいっても、前回と同様に LLVM.sln を開いて、ALL_BUILD するだけです。時間がかかるかなと思って前回は試さなかったのですが、10 分もかかりませんでした。 lli.exe (LLVM 仮想マシン本体。JVM の java コマンドのようなもの)、llc.exe (ネイティブアセンブリコードへのトランスレータ) の他に、llvm-as.exe や llvm-ld.exe、llvm-nm.exe など、おなじみの binutils ライクなコマンド群が生成されます。 まず、GCC にパスが通っていれば、Clang はデフォルトで gcc をアセンブラとして使用するので、通常の実行形式が作れます。 (PA
.related_ss_div{ background-color:#f1faf5; border: 1px solid rgb(228, 237, 235); } div#recentVoters { width:156px; border:1px solid #555; margin-top:5px; } div#recentVoters h3 { background:#000 url(/https/b.hatena.ne.jp/images/thumbs_up.gif) 3px 1px no-repeat; color:#FFC; font-size:14px; font-family:Arial, Helvetica, sans-serif; padding:5px 0 5px 28px; margin:0 0 4px 0; } a {font-size:11px} a.h-orang
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
