OpenBSD が PCC をソースツリーに投入 47
ストーリー by GetSet
gccに慣れきった目にはかなり新鮮かも知れない 部門より
gccに慣れきった目にはかなり新鮮かも知れない 部門より
tamo 曰く、
OpenBSD (4.2 の予約受付中) がPCC をソースツリーに入れました。(コミットログ)
OpenBSD は以前から GCC の最適化重視路線に反発を強めていたため、 NetBSD の i386 ユーザスペースをビルド可能 になった Anders Magnusson 版 PCC に飛び付いたようです。 まだバグや未実装機能がありますが、コンパイル速度 (出力コードの速度ではなく) が GCC の数倍ということで、 もしデフォルト cc に採用されれば、開発時間の有効利用につながりそうです。また、GCC とは違うエラーチェックにより、 既にコード品質の改善に役立っています。
なお、PCC と言えば 4.3BSD 時代には "The Compiler" だったようで、 ちょっとした歴史のあるコンパイラです。 言語依存部分と非依存部分が分離されているため、他言語への拡張も可能のようです。
本音は…？ (スコア:3, 興味深い)
関連コメント (スコア:3, 参考になる)
pkgsrc にも入ってます [netbsd.org]。
Re:関連コメント (スコア:1)
bulk build したら、どのくらい通るんだろうか？
コンパイル時間と開発時間の相関関係 (スコア:3, 興味深い)
コンパイル時間が問題になるのは、何度もコンパイルする人だけだと思うんですよね。
そういう人はちょっと書き換えてコンパイル。またちょっと書き換えてコンパイルと
やってます。
開発時間が短い人は、プログラムをきちんと考えて作っています。ちょっと書き換えて
コンパイルとかやってません。
私は開発時間が短い人間ではないのですが、手が不自由な方を知っているのですが、
その方は、上記のような何度もコンパイルという作業をやってなくて、きちんと考
えて作られているようでして、一般の健常者の方より開発時間が断然速いです。
キモはコンパイル時間じゃなくて (スコア:3, すばらしい洞察)
# 真っ先に採用したのがNetBSDの人たちというのもそのセンでしょ
# コンパイルが速いのは「オマケの長所」というか
もともと、移植性と最適化はトレードオフなところがあるから、選択肢が広がったのは単純にプラスだと思う。
Re:キモはコンパイル時間じゃなくて (スコア:4, 参考になる)
手の不自由さは関係なかろう (スコア:3, すばらしい洞察)
ビルドなんかバックグラウンドで常に回してて自動的にテストスィート動かしてるプロジェクトなら
コンパイルの間ぼーっとしているなんてことはないし、そうではなくてあなたの言うようにコンパイルと
編集を繰り返すスタイルの開発ならコンパイル回数を減らすように条件反射的なデバッグをやめて
熟考しながらコードを書けばいいのです。
その事実に健常者と肢体不自由者との差なんてないのでは？
人差し指だけでぱちぱちキーボードを打つというスタイルの人もいるし、
タッチタイピングの速度と関連付けて議論するのは不毛では？
Re:コンパイル時間と開発時間の相関関係 (スコア:3, 興味深い)
その中には最新の i386 なんかより圧倒的に遅いものもザラにあって、そういう
奴でユーザランドやports/pkgsrc パッケージをセルフコンパイルさせるとなると
コンパイル時間が問題になってきますね
カーネルやデバドラなんかだと、コンパイルして差し替えてリブートしてみて、
あいや、また駄目か、とかやってるのはふつーだし
Re:コンパイル時間と開発時間の相関関係 (スコア:1, 興味深い)
Re:コンパイル時間と開発時間の相関関係 (スコア:0)
ナイトリービルドとか有るじゃん。
業務アプリみたいな事言ってるんじゃねーよ
コンパイルできないや (スコア:2, 興味深い)
./configure && make したら、途中で止まっちゃった。
gcc 4.3.0 がいけないのかな。
$ flex --version
flex 2.5.33
$ gcc --version
gcc (GCC) 4.3.0 20070904 (experimental)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ make
:
flex scanner.l
gcc -g -O2 -DCPP_DEBUG -Wall -Wmissing-prototypes -Wstrict-prototypes -Werror -c -o scanner.o lex.yy.c
cc1: warnings being treated as errors
lex.yy.c:2127: error: no previous prototype for ‘yyget_lineno’
lex.yy.c:2170: error: no previous prototype for ‘yyset_lineno’
f77もあるみたいね。
love && peace && free_software
t-nissie
Re:コンパイルできないや (スコア:2, 参考になる)
GCC4 は型宣言に厳しいっすね。
Re:コンパイルできないや (スコア:3, 興味深い)
$ tar zxf pcc-current.tgz
$ cd pcc-0.9.8
$ rm -rf `find . -type d -name CVS`
$ emacs cc/cpp/Makefile.in cc/ccom/Makefile.in os/linux/ccconfig.h # 下のように編集
$ ./configure --prefix=/usr/local/pcc
$ make
$ make -n install
$ su
# mkdir -p /usr/local/pcc/bin
# mkdir -p /usr/local/pcc/libexec
# make install
PCCの作者より上手にMakefileを書いたり、autotoolsを使う自信はあるぞ。。。
f77はコンパイルされないみたい。
$ cat hello.c
/* hello.c */
int main(void)
{
printf("Hello World!\n");
return 0;
}
$ /usr/local/pcc/bin/pcc hello.c
$ ./a.out
Hello World!
$
#include <stdio.h> は付けるとダメ
$ diff -u cc/cpp/Makefile.in~ cc/cpp/Makefile.in
--- cc/cpp/Makefile.in~ 2007-01-02 14:49:40.000000000 -0500
+++ cc/cpp/Makefile.in 2007-09-17 20:57:43.000000000 -0400
@@ -2,7 +2,7 @@
#
# Makefile.in for cpp
#
-XFL=-DCPP_DEBUG -Wall -Wmissing-prototypes -Wstrict-prototypes -Werror
+XFL=-DCPP_DEBUG -Wall -Wstrict-prototypes -Werror
prefix = @prefix@
exec_prefix = @exec_prefix@
$ diff -u cc/ccom/Makefile.in~ cc/ccom/Makefile.in
--- cc/ccom/Makefile.in~ 2005-05-14 10:08:01.000000000 -0400
+++ cc/ccom/Makefile.in 2007-09-17 20:57:24.000000000 -0400
@@ -3,7 +3,7 @@
# Makefile.in for ccom
#
XFL=-DPCC_DEBUG -DGCC_COMPAT \
- -Wall -Wmissing-prototypes -Wstrict-prototypes -Werror
+ -Wall -Wstrict-prototypes
CC = @CC@
CFLAGS = @CFLAGS@ $(XFL) -I. -I${MIPDIR} -I$(MDIR) -Dmach_${TARGMACH} \
$ diff -u os/linux/ccconfig.h~ os/linux/ccconfig.h
--- os/linux/ccconfig.h~ 2007-03-10 03:14:44.000000000 -0500
+++ os/linux/ccconfig.h 2007-09-17 21:29:56.000000000 -0400
@@ -32,12 +32,12 @@
*/
/* common cpp predefines */
-#define CPPADD { "-D__linux__", "-D__ELF__", "-I" INCLUDEDIR "/pcc", NULL, }
+#define CPPADD { "-D__linux__", "-D__ELF__", "-I" INCLUDEDIR "/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include", NULL, } ？？？必要？？？
#define DYNLINKER { "-dynamic-linker", "/lib/ld-linux.so.2", NULL }
#define CRT0FILE "/usr/lib/crt1.o"
-#define STARTFILES { "/usr/lib/crti.o", "/usr/lib/gcc/i586-suse-linux/4.1.0/crtbegin.o", NULL }
+#define STARTFILES { "/usr/lib/crti.o", "/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/crtbegin.o", NULL }
#define LIBCLIBS { "-lc", "-lgcc_s", NULL }
-#define ENDFILES { "/usr/lib/gcc/i586-suse-linux/4.1.0/crtend.o", "/usr/lib/crtn.o", NULL }
+#define ENDFILES { "/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/crtend.o", "/usr/lib/crtn.o", NULL }
#define STARTLABEL "_start"
#if defined(mach_x86)
love && peace && free_software
t-nissie
Re:コンパイルできないや (スコア:3, 参考になる)
gcc をコンパイルするときって、元々あるコンパイラを信用していないというか
stage1: 古いコンパイラで gcc をコンパイル→gccバイナリそのものは古いコンパイラが出力してるので、あてにしたくない
stage2: stage1で出来たgccで、gccをコンパイル→古いコンパイラが出したgccの出力なので、もしかしたらバグってるかも
stage3: stage2で出来たgccで、gccをコンパイル→stage2とstage3の出力を比較してバイナリが一致していれば安心
って流れで、「gccで自身をセルフコンパイル」しますよね。「cc は最適化がとろいし、たまにバグってるので当てにしたくない」って感じでしたっけ。
今時のgccは最適化を強くすると挙動が怪しいとかよく聞きますし、最適化無しのgccは結構遅いコードを吐き出しますから、
gccの最適化無しでpccを作った後、pccで最適化オプションつけてpcc自身をセルフコンパイルぐらいはしてもいいんじゃないかなとか思ってしまいます。
Re:コンパイルできないや (スコア:1)
ふつうのプログラムもうまくコンパイルできません。どっかからヘッダファイル
ひとそろいをダウンロードしてくるのでしょうか。
os/linux/ccconfig.hのCPPADDは
#define CPPADD { "-D__linux__", "-D__ELF__", "-I" INCLUDEDIR "/pcc", NULL, }
だと、-I$PREFIX/include/pcc になるみたいです。
love && peace && free_software
t-nissie
Re:コンパイルできないや (スコア:0)
「ドッグフードを食べる」的な意味合いもあるかもしれません。あと、問題が起きたときに、原因を絞ることができそう。
それに、「自分自身をコンパイルできるようになる」のは漢のロマンですし。
Re:コンパイルできないや (スコア:0)
コードを読む (スコア:2, 興味深い)
そして出てきたアセンブリも読んでみる。
自分の使っているアーキテクチャに合わせて改造して、出力されたコードを動かしてみる。
ベンチマークを走らせて、ピープホールのオプチマイズを追加してみたり。
gccなどは読むのもいじるのも大変ですからね。 半年くらい楽しめる。(人によっては一生?)
The Compiler? (スコア:2, 参考になる)
でも，4.2BSDにはすでにpccが載ってたのは記憶している． Unix Programmer's Manual, 7th editionにすでにpccが載ってるんだから，UNIX V7以降ずっと4.3BSD-renoまで使われてたんじゃないのかなぁ．
Re:The Compiler? (スコア:2, 興味深い)
日本語版 [wikipedia.org]では
となっている文章が、Wikipedia英語版 [wikipedia.org]では と、文の区切りが変わってる。後半部分は「主要なCコンパイラのベースとなっていた1980年代初期から1990年リリースの4.3BSD-Reno(が、GCCが標準になった4.4BSDに置き換わる)までの長い間」と訳さなくちゃいけないんじゃないのかな。
末端には (スコア:1, 興味深い)
#BSD使ってないのでAC
Re:末端には (スコア:4, 興味深い)
その GCC の最適化が時々バグっていたりして怖いよね、というのがセキュリティ命な OpenBSD の立場なんでしょう。
良く分ってないのだが (スコア:1)
まぁ、選択肢が増える事は良い事なんだが、、、
uxi
Re:良く分ってないのだが (スコア:1, すばらしい洞察)
Re:末端には (スコア:1, すばらしい洞察)
タレコミで言及されてるのは開発者のメリットですし。
杞憂なのはその通りだけれど (スコア:1, すばらしい洞察)
# ぐぐってみたら、ICCがGCCアプリとのリンクを公式サポートしたのが2003年末 [xlsoft.com]らしい。
Re:末端には (スコア:1, 参考になる)
日本語読めない人ですか?「エラーチェック」でしょ?
tech-toolchain のメールでも、エラーと未実装機能はちゃんと区別してるじゃない。
Re:末端には (スコア:0, おもしろおかしい)
>日本語読めない人ですか?「エラーチェック」でしょ?
>tech-toolchain のメールでも、エラーと未実装機能はちゃんと区別してるじゃない。
エラーチェック、日本語ちゃうやん･･･
Re:末端には (スコア:0, 興味深い)
#本当だ！
Re:末端には (スコア:0)
Re:末端には (スコア:0)
安全な使い方だと思うのですが、手間の問題は最大の障壁？
おっさんのハートをわしづかみ (スコア:4, おもしろおかしい)
Re:おっさんのハートをわしづかみ (スコア:1, おもしろおかしい)
# 確か本人が/.jにいたような気がするので AC
Re:おっさんのハートをわしづかみ (スコア:1)
Re: (スコア:0)
Re:距離÷時間=速さ (スコア:1, オフトピック)
数値としては「5 から 10 分の 1」ということになりますから、その方が直感的でしたね。
ごめんなさい。
ただ、「コンパイル時間が GCC の 5 から 10 分の 1」と書くと、
「PCC をビルドする時間と GCC をビルドする時間を比較して……」
と思われそうで困りますが。(それなら 10 から 100 倍ってとこかな？)
タレコミ道は長く険しいですなあ。
Re:距離÷時間=速さ (スコア:0)
いいかげん (スコア:0, 興味深い)
Re:いいかげん (スコア:0)