PCC builds OpenBSD kernel (4.6 -current) | Hacker News Reader

PCC builds OpenBSD kernel (4.6 -current)

undeadly.org

44 pointsFixnum19 comments

It would be interesting to see how kernels compiled with pcc and gcc compare, size-wise and performance-wise.

I am curious: what is it about GCC that BSD folks want to get rid of it so bad? I don't really follow GCC development, but on a multiple occasions I've heard people wishing there was something else.

I've used C component of it and it was fine. Their C++ implementation is lacking compared to Visual C++ (especially in generated code size and template-related error messages). What else do people dislike about it?

BSD people tend to like BSD licensed things.

I think it's more the bugs, which tend to show up in kernel code, and the ability to extend the compiler with security features, which is difficult in the rather hairy gcc code. OpenBSD used a custom gcc 2.95 derived compiler for ages because of bug fixes and their security extensions.

An other problem is when GCC drops architecture support -- say some old arch which Linux doesn't run on but which the BSDs do -- then the BSDs are forced to maintain multiple old versions of GCC...

Which architectures are those? And this is a FreeBSD announcement, which has a much more limited port list than NetBSD.

OpenBSD != FreeBSD. Very different beasts.

Here are the hardware platforms that OpenBSD runs on (http://openbsd.org/plat.html). Not as many as NetBSD, but several.

Porting a program that was written primarily with (say) i386 Debian Linux in mind to other platforms is a great way to find bugs due to incorrect assumptions. They may be asymptomatic on systems with 32-bit processors, the same endian-ness, etc., but they're just lying dormant. Patches from porting and the OpenBSD security audits are contributed upstream, too.

Once upon a time Theo was considering the Plan9 tool chain for the OpenBSD project. Sadly Lucent's lawyers proved not too adept and writing software licenses in what was a brave new world of OSS.

http://groups.google.com/group/comp.os.plan9/browse_thread/t...

The previous license was worse, it had a "make any modifications and you have to send them back to Lucent" clause.

Theo was right and the world was robbed and the now the compilers are available in either GPL, LGPL, Lucent or MIT license form from the Vita Nuova Inferno project.

http://www.vitanuova.com/inferno/downloads.html http://www.vitanuova.com/inferno/contents.html

And a hybrid license through Plan9Ports

http://swtch.com/plan9port/

What a fuck up.

Compiler licensing is not enough to supersede the BSDs' pragmatism. We've been using GCC for years.

If you've had to maintain GCC for your platform -- or worse yet, tried to add even small improvements -- you'd understand why momentum is building to replace it.

Not that switching to GPLv3 helped GCC any. That's one reason among many that Apple stopped GCC development and put their weight behind LLVM.

You mean simple things. The preamble to the GPL is longer than the entire ISC license... by like 5 times. GCC is like 100 times more complex than PCC. BSD folks like simple, secure things.

To add some numbers to that, PCC appears to be about 20,000 lines of code [1] and LLVM+clang together about 550,000 lines [2]. I can't immediately find a figure for GCC, but I wouldn't be surprised if it was significantly more than LLVM+clang.

[1] http://www.openbsd.org/papers/magnusson_pcc.pdf [2] http://blog.llvm.org/2009/12/clang-builds-llvm.html

Not that LOC necessarily says anything on code complexity or design, but here's sloccount on gcc42:

  ansic:       869244 (70.89%)
  ada:         150280 (12.26%)
  cpp:         114629 (9.35%)
  f90:          34164 (2.79%)
  sh:           18588 (1.52%)
  objc:         13047 (1.06%)
  exp:           8821 (0.72%)
  fortran:       7139 (0.58%)
  asm:           4422 (0.36%)
  ml:            2485 (0.20%)
  perl:          1080 (0.09%)
  awk:            842 (0.07%)
  lex:            589 (0.05%)
  yacc:           587 (0.05%)
  pascal:         105 (0.01%)
  haskell:         98 (0.01%)
  lisp:            59 (0.00%)

Working on GCC is like taking a big step back into the dark ages of programming. Unless you've been tracking its development for years, it's next to impossible to dive into the code and get anything done. Little to no documentation on how to build your own backends, how to build optimizations, etc. Even once you figure out how to actually write code for the project, you end up looking things up at every turn just to get things working. If you need to make a serious change to the compiler (e.g. using SSA), you end up touching effectively every part of the compiler to make it work, hence why this change took so long.

It honestly amazes me that GCC is as far along as it is; it says something about the developers' dedication to free software. However, with compilers like LLVM+Clang becoming better and better by the day (largely due to the fantastic design facilitating efficient development), I doubt we'll be seeing much of GCC in a few years.

GCC's was intentionally designed to be so convoluted to keep anyone from developing out-of-tree code that interfaces with any of it's internal representations, all for ideological reasons -- Stallman wanted to make sure noone would write any non-GNU features: IDE integration, language frontends, optimizers, target architectures, etc.

You either have to treat it as an executable black box, or fork the whole damn project -- which actually happened back in the day when the FSF's sole paid developer refused all public involvement with RMS's blessing.

Any source on that? I'm not arguing that gcc isn't a convoluted mess and that modifying it in any way is far harder than it perhaps should be. But I've always been under the impression that it just evolved that way due to lack of over all design. Do you have anything to back up that it was actively designed to be convoluted and obfuscated?

I've heard stories about this for years, there are some choice comments about it by Thomas Lord in this recent thread: http://lambda-the-ultimate.org/node/3696

I can't find it right now, but there was also an old flamewar (can't remember if it was public or just a public recounting) between RMS and Steve Jobs over NeXT's Objective-C frontend.

It uses the GNU GPL version 3, which is incompatible with the use cases of many of BSD's "customers". Notably, Apple has refused to use the GPLv3 versions of GCC in Mac OS X, and FreeBSD has followed suit by staying with GCC 4.2 until clang is considered finished. It also tends to have problems on less popular architectures that Net/OpenBSD still consider important.

What are those use cases?

Reply on news.ycombinator.com