Slashdot Mirror

← Back to Stories (view on slashdot.org)

GCC Compiler Finally Supplanted by PCC?

Posted by ScuttleMonkey on from the all-good-things-must-end dept.

Sunnz writes "The leaner, lighter, faster, and most importantly, BSD Licensed, Compiler PCC has been imported into OpenBSD's CVS and NetBSD's pkgsrc. The compiler is based on the original Portable C Compiler by S. C. Johnson, written in the late 70's. Even though much of the compiler has been rewritten, some of the basics still remain. It is currently not bug-free, but it compiles on x86 platform, and work is being done on it to take on GCC's job."

11 of 546 comments (clear)

  1. Kind of depends... by KingSkippus · · Score: 4, Insightful

    ...and most importantly, BSD Licensed...

    Kind of depends on who you ask, doesn't it?

  2. Interesting... by cromar · · Score: 4, Insightful

    I really don't see any point in implementing a new C compiler under the BSD lisence. There's no reason to duplicate effort: it's not like the compiled binaries would be under the GPL. And any GPL libraries you link to, you wouldn't need to distribute (thus avoiding the GPL). So, really, there's no point in duplicating effort on a BSD lisenced compiler. Correct me if I'm wrong.

    1. Re:Interesting... by everphilski · · Score: 4, Insightful

      Principle?

      I don't know, I'm not a BSD user, but as much as RMS likes to claim that 'linux' is GNU/linux, maybe BSD users want their OS to be self reliant?

      Would you like to compile Linux using a microsoft compiler? :)

    2. Re:Interesting... by Anonymous Coward · · Score: 5, Insightful

      Would you like to compile Linux using a microsoft compiler? :) If it produced the best code, why not? People already compile Linux using the Intel compiler.

    3. Re:Interesting... by Omnifarious · · Score: 4, Insightful

      The real reason that Stallman wants this is that he early on correctly perceived that Linus is totally ideology agnostic, and so he wanted to put the idea of GNU/Linux out there so people would talk about the ideology. I don't think this is bad or anything. I think the ideology needs to be heard more widely.

      It could also be argued that without the GNU project, Linus wouldn't have had a license ready to use for Linux, and I think that contribution by the GNU project weighs at least as much as all the userspace tools which someone would likely have eventually written anyway.

      --
      Need a Python, C++, Unix, Linux develop
    4. Re:Interesting... by Anonymous Coward · · Score: 5, Insightful

      I am the GPP, incidentally, and while I'm pleased I got modded up, I certainly wasn't going for funny :). I'm sorry, but C is just a poor choice for ensuring correctness.

      First of all, open up your copy of the C standard (any of them will do) and grep for the phrase "undefined behaviour". C was standardized in a time when everyone and their dog had their own C compiler. Each C compiler did things in a different way, often in contradictory ways. The C standard came along and said "hey, you know what? You're ALL right". I'm being facetious, and the C standard has done a great job in promoting C, but the C standard has really not evolved very far in terms of guaranteeing semantics.

      I don't mean to bring this up to say that "you can't write correct code" in C or such nonsense. Obviously it's easy with good habits (I recommend comp.lang.c as the best place to pick up these habits) to write conforming and well-defined code. But, if you're trying to verify code that's already been written, either by hand or via some automated tool like a static analyzer, it is painful.

      The second problem with C is that it allows a lot of features that make verification of semantics difficult. Pointer aliasing, global variables (even "extern" global variables!!), etc. make static analysis dreadful. If you want to perform static analysis properly on C programs, it's hard to get around whole-program analysis, which is why no one uses static analysis with C code :). Seriously, what does C have beyond lint? How many people even use lint? It's not very useful.

      Of course static analysis is not the end-all be-all of ensuring correct code. There's good coding habits and testing and profiling and whatnot too. But, I would argue that whatever effort can be put into verifying C code can be better put into code in other languages. The semantics of C are sometimes loosely defined, and very often far-reaching, preventing the use of modular reasoning. Whole-program analysis is not your friend.

      What would be really cool is to see from someone like the OpenBSD crowd, if they're so keen on C, develop some verification tools that maybe only work on a very, very restricted subset of C. Any code which does not conform to this restricted "more easily verifiable" subset of C in the core OS would be rejected. I don't know how practical it would be, but it would be cool to see :). I mean as an academic, obviously I think we should all be using Z, but I understand this doesn't make good sense in a lot of real-world projects. But you want to get serious about correctness, don't pussy foot around: get serious about correctness.

    5. Re:Interesting... by Nevyn · · Score: 4, Insightful

      Let's at least get RMS's position right:

      Better idea, let's just get history correct.

      The GNU project was founded in 1984 to create a free operating system.

      Ok, true enough.

      In 1991, they were almost completely finished - they had written every essential component of a Unix-like operating system except for a kernel.

      Sure, and I've almost created a free engery device ... I've done everything apart from this one bit that creates energy for free. Also, GNU did not "create" everything else apart from the kernel ... they created some pieces and were doing the distribution work, so other people "donated" their work.

      Linus came along, wrote the Linux kernel,

      True enough.

      combined it with the almost-complete GNU system, and called the whole thing Linux.

      Not even close to true, Linux has only ever distributed the kernel ... other people combined it and called the whole things like "Red Hat Linux" or "Slackware Linux", GNU should/could have done this but had not bothered to do the work to make a usable distribution (as more than a collection of tarballs) and were happily ignoring Linux and telling everyone else to ignore it and use GNU-Hurd when it would be ready "any time now". This was pretty obvious naming at the time, we didn't call Solaris "GNU/Solaris" when we installed GCC, GNU-tar etc. on it.

      The GNU people were rightly upset that they were getting no credit for their work (to build a complete Unix-like OS).

      They got a huge amount of credit, for the work they did. They just didn't get their name in lights ... because they refused to do the work required for that. Then they complained and wanted more recognition than anyone else got who'd done the same amount of work as they had (like Perl or Xorg etc.) ... this created a "slight" backlash by people who actually know what happened.

      --
      ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
  3. Stupid waste of time by th0mas.sixbit.org · · Score: 4, Insightful

    Seriously. Let's duplicate the wheel twice: once for GPL, once for BSD, and then bicker amongst ourselves. Stuff like this stands in the way of actual progress being made. Neither side is right, I don't have a solution, but this is just dumb.

    --
    twitter.com/gravitronic
  4. Re:Not for NetBSD for sure by TheRaven64 · · Score: 4, Insightful

    Actually, support for different architectures is one of the main reasons OpenBSD is looking at it. GCC has a habit of dropping architectures because 'nobody uses them,' which causes some OpenBSD (and NetBSD) ports to remain stuck with old versions of GCC. The x86 backend for PCC was written in three weeks by one person, so it seems reasonable to assume it should be possible to add support for the other required platforms relatively easily.

    It's worth remembering that in BSD-land, things are divided into the base system and third party packages. The base system needs a C compiler that is capable of compiling the userland (which PCC already does for OpenBSD), is small, portable, and easy to audit. Packages have quite different requirements; they need support for more languages, etc. PCC is likely to replace GCC in the BSD base systems, but that doesn't mean that people won't install GCC or LLVM for compiling other things.

    --
    I am TheRaven on Soylent News
  5. Re:The licence is just the top of the iceberg by Anonymous+Conrad · · Score: 5, Insightful

    The whole design of GCC is perverted so that someone cannot easily extract a front-end or back-end. This is broken by design, as the GPL people do believe this would make it easier for commercial entities to `steal' a front-end or back-end and attach it to a proprietary code-generator (or language). That's entirely wrong. RMS has been worried about this, and he (through the FSF who own the copyright) have previously objected to any patches that serialize the GCC's intermediate state for just this reason. (Although GCC's new link-time optimization work will change this.)

    GCC's intermediate formats GIMPLE and GENERIC are based on a research compiler, not a deliberate perversion. There's no technical steps to stop reuse, and indeed it has been done - Sun distribute the GCC 4.0.4 front-end altered to use their own SPARC code generator as a back-end.
  6. Pure ISO C99 has limitations when writing a kernel by tepples · · Score: 4, Insightful

    That's not a good test, given that Linux depends on gcc-isms. It's not written in any standardised form of C, which would be a far fairer test. How can a kernel be written in a standardized form of the C language? The C language does not specify any mechanism for alignment, struct packing, code sections, CPU-specific function calling conventions, or any of the various other attributes, nor does it allow for the kinds of inline assembly language needed to talk to the memory mapper or the I/O hardware.