コンパイラを作ってみたいと思っていても、アセンブリ言語はよくわからない。 パーサーみたいなコードは書いたことがあるけれど、コード生成の処理はさっぱりだ。 実行ファイルをバイナリエディターで見るとかなにそれ怖い。 そんな私なのですが、LLVMに興味を持ち始めています。 SwiftやRust、あるいはEmscriptenなど、近年注目されている言語やコンパイラ技術の中枢にはLLVMがあります。 アセンブリはよく分からなくてもLLVMを使いこなせるようになれば、マルチプラットフォームで実行ファイルを生成できる言語処理系を作るのではないか。 コンパイラ作ってみたいな、LLVMを使ってみようかなと思っている今日このごろです。 ところが、いざLLVMを勉強しようと思ってもどこから始めればいいかよく分かりませんでした。 マニュアルは巨大で読む気が起きないし、リファレンスを見てもさっぱりです。 雰囲気はわ
この記事は Vim Advent Calendar 2013 88日目の記事になります。 元ネタ それ、Vim で。 と、いう事でやってみました。 [必要なプラグイン] Shougo/vimproc.vim コマンドを非同期で実行する osyo-manga/vim-watchdogs シンタックスチェックを行う jceb/vim-hier エラー箇所を波線でハイライトする dannyob/quickfixstatus カーソル位置のエラー内容をコマンドラインに出力する thinca/vim-quickrun watchdogs.vim のバックエンド osyo-manga/shabadou.vim quickrun.vim の hook 拡張 NeoBundle "Shougo/vimproc.vim" NeoBundle "thinca/vim-quickrun" NeoBundle "
本の虫: Clang VS 自由ソフトウェア
オープンソースで有名なEric S. Raymondが、自由ソフトウェアで有名なRichard Stallmanに、GCCのアンチプラグインポリシーについて突っ込んでいる。 GCCは、長年、コンパイラーのモジュール化を政治的な理由で行っていなかった。もし、例えばパーサーや意味解析だけを分離して使えるようにしたり、内部表現を規格化したりしてしまうと、GCCの一部が、不自由なソフトウェアに取り込まれたり、あるいは不自由なソフトウェアがGCCのプラグインという形で入り込むことになってしまう。これは、利用者の自由を第一とする自由ソフトウェアにとって、悪夢のような未来である。そのような未来を未然に防ぐために、政治的な理由で、GCCのはプラグインに反対するポリシーを採用している。もし、GCCを改良したければ、自由なソフトウェアとなるべきなのだ。そして、GCCのプロジェクトに参加するべきなのだ。 とはい
Clang の clang-tools-extra に含まれている ClangCheck を使ってみました。 ClangCheck は Clang の LibTooling を使用したシンタックスチェッカーです。 LibTooling - Clang 3.3 documentation ClangCheck - Clang 3.3 documentation [main.cpp] void func(int){ } int main(){ std::cout << "homu" << std::endl; func(); int n = 0 return 0; } [出力] $ clang-check.exe main.cpp -- D:\test\test\main.cpp:8:2: error: use of undeclared identifier 'std' std::cout
By Sylvestre Ledru (Debian, IRILL). Presentation This document presents the result of the rebuild of the Debian archive (the distribution) with clang, a C/C++ compiler. clang is now ready to build software for production (either for C, C++ or Objective-C). This compiler is providing many more warnings and interesting errors than the gcc suite while not carrying the same legacy as gcc. This rebuild
なんかスレッド回りの処理が追加されたっぽいです。 実装自体は、libclang.py で行っている、libclang を使ってないと反映されないかも。 実際にどこら辺が非同期になっているのかわかりませんが、コード補完自体はそれっぽくなっている感じ？ 全体的に重くなるので、試すときは注意してください。 今後に期待。激しく期待。 あと、あんまり参考にならないかも知れませんが、以前と同じ条件で測ったらこんな感じでした。 [llvm 2.9] 1回目 3.54s 2回目以降 0.38s PC の性能によっても違うかもしれません。 気になる方は試してみてください。 [clang_complete] https://github.com/Rip-Rip/clang_complete
Clang のツリーを眺めていたら, "clang-completion-mode.el" というファイルがあった. clang のプログラムを呼び出してコード補完ができるらしい. (使いかたを説明してくれている人もいた.) 以前読んだ時 は気付かなかったけど, 二年前からあったようだ. こんなものがプラグインで書けてしまうなんてさすがモダンなコンパイラは違うなーインデクスはどうするのかなーと 感心しつつコードを見ていたらインデクスのような前処理はないようす. それに全然プラグインじゃない. Clang 組み込みの機能として実装されていた. 以前から Xcode(4) がどんな風に Clang を統合するのか気になっていた. コード補完はそうした取り組みの一環かもしれない. 高々 Emacs のため Clang 組込みの機能を増やすとも思えないからね. というわけでざっとコードを眺めてみよ
clangというのはllvm向けのC/C++/Obj-Cのためのフロントエンドで、最近はGoogle ChromeとかFirefoxもコンパイルできるレベルにまで成熟してきているらしい。 いくつかのブログで紹介されているのを見ても、ふーん、ぐらいにしか思っていなかったのだが、あんな大規模なソフトウェアがコンパイルできるというのは、考えてみるとすごいことである。大事なことなので強調しておくが、すごいことである。十分に実用的なレベルに到達していることだ。ビルドも早いし生成されたコードもg++と同程度には速いというし、試してみる必要がある。 という訳で、いくつか実際にソフトウェアをビルドしてみた。試してみた限りでは、 libstdc++のtr1/unordered_mapがビルドできない C++のコーナーケースで、clangが許容しないものが多い といった問題があったが、割とどれもすんなりとコン
FreeBSD Daily Topics 2010年4月19日FreeBSD GCCを置き換えるLLVM Clang、広くテスト呼びかけ src ClangBSD - LLVM Clang Call for Test Roman Divacky氏がメーリングリストにおいてLLVM ClangのFreeBSD統合が一定のレベルに達したとしてコミュニティに広くテストを呼びかけています。LLVM Clangがセルフホストに到達したこと、ClangのC++サポートが向上したこと、i386/amd64のシステムとカーネルのビルドと成功していることなどが背景にあります。 テストはClangBSDのブランチを取得してビルドすることで実施できます。作業の詳しい方法はBuildingFreeBSDWithClang - FreeBSD Wikiにまとまっています。いつ、どのタイミングでメインブランチに取り込
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
yebo blog: ClangでLinuxカーネルをビルドできた