Portable C Compiler 1.0 released(undeadly.org)
undeadly.org
Portable C Compiler 1.0 released
http://undeadly.org/cgi?action=article&sid=20110403095326
4 comments
I tried this and immediately hit three internal compiler errors and one rejection of perfectly valid code. As far as I am concerned, this is not a compiler.
Did you file a bug report?
http://pcc.ludd.ltu.se/bugs/
http://pcc.ludd.ltu.se/bugs/
I haven't had time to distill the ICEs into proper bug reports anyone would want to touch. The last failure was easy to reduce, and I added a note to an already open entry for what seemed to be another instance of the same bug.
[deleted]
How does PCC compare to the Plan 9 C compiler? The Plan 9 C compiler is BSD licensed; has a straightforward implementation; emits code for x86, x86-64, and ARM; and is a core component of Google's Go toolchain.
Someone needs to port this to OSX. This could enable a non-admin install of MacPorts on computers without XCode, which is impossible so far.
There can be good reasons why an IT organization has not installed development tools.
MacPorts is the deep end of the (support) pool for somebody that can't (also) install Xcode.
MacPorts is a good way for a non-admin or inexperienced user to get themselves seriously tangled with PATH, or with unexpected tool skews and the odd-ball errors. (And this is ignoring how much replication arises within what's installed by Apple and with what's also installed by MacPorts, bypassing what's installed by Apple.)
But if you really want to try a C compiler download for Mac OS X (or other boxes) that doesn't involve downloading and installing Xcode, have a look here:
http://llvm.org/releases/download.html
MacPorts is the deep end of the (support) pool for somebody that can't (also) install Xcode.
MacPorts is a good way for a non-admin or inexperienced user to get themselves seriously tangled with PATH, or with unexpected tool skews and the odd-ball errors. (And this is ignoring how much replication arises within what's installed by Apple and with what's also installed by MacPorts, bypassing what's installed by Apple.)
But if you really want to try a C compiler download for Mac OS X (or other boxes) that doesn't involve downloading and installing Xcode, have a look here:
http://llvm.org/releases/download.html
There might be reasons why an IT org. has not installed Xcode, but those might not be good enough reasons for the users. From a users perspective, it might be nice to have a choice.
Could someone elaborate why one would use pcc over the also liberally licensed clang/LLVM, except for ancient architectures on which LLVM doesn't run or is too slow?
The original motivation (from back in 2007) was threefold:
(1) BSD licensed, which was felt to be preferable to GCC (ie. GPL) for BSD developers.
(2) It's supposed to compile things 5-10 times faster than GCC.
(3) Very portable to new architectures; obviously a good thing for NetBSD which is ported to just about everything.
LLVM doesn't figure into this; perhaps it was unknown or not very capable back in 2007?
Source: http://marc.info/?l=netbsd-tech-toolchain&m=118961767521...
(1) BSD licensed, which was felt to be preferable to GCC (ie. GPL) for BSD developers.
(2) It's supposed to compile things 5-10 times faster than GCC.
(3) Very portable to new architectures; obviously a good thing for NetBSD which is ported to just about everything.
LLVM doesn't figure into this; perhaps it was unknown or not very capable back in 2007?
Source: http://marc.info/?l=netbsd-tech-toolchain&m=118961767521...
Although LLVM existed and was fairly well known, it was a middle/backend-only project until mid-2007 or so, and used gcc as the language frontend. Clang's first source release wasn't until July 2007, and I don't think it got much traction until 2008, and a 1.0 release in late 2009. So it seems plausible that a September 2007 discussion wouldn't have it on the radar.
Also in (3), very portable to old architectures. PCC is written in C, where LLVM/Clang is C++. This makes one less hurdle to bootstrapping a new compiler on some archs.
From experience in porting an OS, common porting scaffolding can include a cross compiler and a cross linker, and replacing an assembler with a compiler for compiling the assembly code for the new target box.
Getting a native build and a native C++ and a native assembler re-hosted can then proceed secondary to getting the basic OS pieces booted and rolling.
Getting a native build and a native C++ and a native assembler re-hosted can then proceed secondary to getting the basic OS pieces booted and rolling.
With regard to 2, I don't care so much about compile speed (within reason) as I do about the speed of the produced binary. How fast is the output?
Depends entirely on what particular optimizations apply to your code. Overall, pcc is probably within 10% for most code, but you'll also find examples where gcc or llvm is 10x faster. It all depends.
If your maintaining code on a VAX, you care a tad bit about compile speed.