OpenBSD Journal

Call for Testing: pcc AMD64 Support

Contributed by Michael Dexter on from the dept.

Anders Magnusson (ragge@) has been quietly hacking on pcc and has committed AMD64 support which is in need of testing. As always, please report any bugs in the pcc bug database. The best bug reports are of the form "this particular code snippet doesn't compile" or "this expression generates wrong the assembler output".

My sincere thanks to the nearly 75 donors who help fund this work. Please consider helping keep Anders going with a donation towards this work to produce a 1.0 release of this BSD-licensed compiler.

(Comments are closed)

Comments

  1. By Anonymous Coward (190.166.97.224) on

    Does pcc already compiles something bigger then 'hello world' scripts?

    Yay, now u can compile helloworlds under x64. Way to go, OpenBSD, way to go. Please keep bringing more and more bicycles into opensource community and complain that world will die without openbsd and nobody is willing to pay for it.

    Comments

    1. By Anonymous Coward (87.144.83.156) on

      I think your opinion sucks! So I modded you down - that will show you! Ha!
      Seriously... flamebaits these days.

      Comments

      1. By Anonymous Coward (128.171.90.200) on

        You can't get the trolls these days.

    2. By Anonymous Coward (198.175.14.5) on

      > Does pcc already compiles something bigger then 'hello world' scripts?
      >
      > Yay, now u can compile helloworlds under x64. Way to go, OpenBSD, way to go. Please keep bringing more and more bicycles into opensource community and complain that world will die without openbsd and nobody is willing to pay for it.

      OpenBSD doesn't fund PCC much, he gets his funding other ways. PCC compiles most of the OpenBSD system. Your worthless comments reflect your own personality.

    3. By Anonymous Coward (85.166.57.54) on

      > Does pcc already compiles something bigger then 'hello world' scripts?
      >
      > Yay, now u can compile helloworlds under x64. Way to go, OpenBSD, way to go. Please keep bringing more and more bicycles into opensource community and complain that world will die without openbsd and nobody is willing to pay for it.

      Who are you, and why are you taking up my oxygen?

    4. By Anonymous Coward (219.90.208.233) on

      I like bicycles. My one is red.

      Comments

      1. By Anonymous Coward (150.101.245.181) on

        > I like bicycles. My one is red.

        http://www.youtube.com/watch?v=rAOHhV1EFe4

    5. By Anonymous Coward (212.77.163.101) on

      > Does pcc already compiles something bigger then 'hello world' scripts?
      >
      > Yay, now u can compile helloworlds under x64. Way to go, OpenBSD, way to go. Please keep bringing more and more bicycles into opensource community and complain that world will die without openbsd and nobody is willing to pay for it.

      Another common user who has no clue about compiler but he or she is a master of posting.

    6. By Anonymous Coward (88.96.248.182) on

      > Does pcc already compiles something bigger then 'hello world' scripts?
      >
      > Yay, now u can compile helloworlds under x64. Way to go, OpenBSD, way to go. Please keep bringing more and more bicycles into opensource community and complain that world will die without openbsd and nobody is willing to pay for it.

      Sebastian Rother/Rembrandt, is that you? :)

    7. By Anonymous Coward (2002:c1bc:c00f:4:217:31ff:fedf:41c9) on

      > Does pcc already compiles something bigger then 'hello world' scripts?
      >
      > Yay, now u can compile helloworlds under x64. Way to go, OpenBSD, way to go. Please keep bringing more and more bicycles into opensource community and complain that world will die without openbsd and nobody is willing to pay for it.

      How does one compile scripts and what is an "x64"?

      Comments

      1. By Andre (194.19.42.130) on

        > > Yay, now u can compile helloworlds under x64.

        > How does one compile scripts and what is an "x64"?

        It's not "an x64". It means 64x helloworld, i.e. helloworld multiplied by 64. I believe this is the OPs next-gen helloworld-script called "helloworld64", which has the sole purpose of outputting "helloworld" no less than 64 times on the screen. It's still in beta, but the final version should have an optional switch to turn off linefeeds between helloworlds, since many displays are actually incapable of showing 64 lines of output at once.

        I have seen a handful of pre-compiled versions of this script, included one compiled with the -funrolloops flag. It looked something like this:

        #!/bin/sh
        echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld; echo helloworld

      2. By Simon Lundström (simmel) on

        > > Does pcc already compiles something bigger then 'hello world' scripts?
        > >
        > > Yay, now u can compile helloworlds under x64. Way to go, OpenBSD, way to go. Please keep bringing more and more bicycles into opensource community and complain that world will die without openbsd and nobody is willing to pay for it.
        >
        > How does one compile scripts and what is an "x64"?

        See http://en.wikipedia.org/wiki/x64

  2. By Renaud Allard (renaud) renaud@allard.it on

    I just donated, it's so nice if we have a BSD alternative to GCC..

    Comments

    1. By Anonymous Coward (24.21.221.209) on

      > I just donated, it's so nice if we have a BSD alternative to GCC..

      same here. more alternatives the better.

      thanks

      AC

    2. By Thomas Pfaff (tpfaff) on http://www.tp76.info

      > I just donated, it's so nice if we have a BSD alternative to GCC..

      ... and to have a compiler without a gazillion knobs for just about
      anything that you never really need.

      Comments

      1. By Tim Barber (dekernel) on

        > > I just donated, it's so nice if we have a BSD alternative to GCC..
        >
        > ... and to have a compiler without a gazillion knobs for just about
        > anything that you never really need.
        >

        Not sure why, but this make me bust out laughing for a second because it does have a gazillion options that me so little to me (not that they aren't important to others especially on different platforms).

    3. By Simon Lundström (simmel) on

      > I just donated, it's so nice if we have a BSD alternative to GCC..

      ++

    4. By Anonymous Coward (192.100.124.218) on

      > I just donated, it's so nice if we have a BSD alternative to GCC..

      This will surely mod me down to the lowest layers of hell, but hell, I donated, but, not because I want to have a "BSD alternative", but because I want a freaking "alternative". Look, the PCC compiler is vastly superior to GCC in my opinion, because of historical baggage the GCC carries, I mean, I get scared when I try to comprehend something about GCC. However I just don't get why the fact that it's more free than GCC has to be pointed out as the reason to have it? Just my 0.02EUR.

    5. By Anonymous Coward (118.110.172.147) on

      > I just donated, it's so nice if we have a BSD alternative to GCC..

      I had donated too. Looking forward to donate again when amd64 and other arches are supported for real.
      Still, this sure took a long time for "a compiler platform that makes porting to different processor architectures trivial".

      Comments

      1. By ragge (ragge) on

        > Still, this sure took a long time for "a compiler platform that makes porting to different processor architectures trivial".
        That is depending on the amount of time spent with porting it.
        Effective time for amd64 has been less than a week, but still someone need to do it.

      2. By Otto Moerbeek (otto) on http://www.drijf.net

        > I had donated too. Looking forward to donate again when amd64 and other arches are supported for real.
        > Still, this sure took a long time for "a compiler platform that makes porting to different processor architectures trivial".

        Even trivial tasks take sombody having the possibility to donate time.

        That one could have been you.

    6. By Terrell Prude', Jr. (151.188.247.104) tprude@cmosnetworks.com (this is a spamtrap address) on http://www.cmosnetworks.com/

      > I just donated, it's so nice if we have a BSD alternative to GCC..

      For me, it's fine if it's either GPL or BSD license. I actually like GCC, but I certainly agree that GCC could use a bit of competition, and if PCC gets popular (let's hope so!), then so much the better.

      Maybe this will be the impetus to get the GCC maintainers to finally wake up and include strlcat and strlcpy! :-)

      --TP

      Comments

      1. By tedu (udet) on

        > > I just donated, it's so nice if we have a BSD alternative to GCC..
        >
        > For me, it's fine if it's either GPL or BSD license. I actually like GCC, but I certainly agree that GCC could use a bit of competition, and if PCC gets popular (let's hope so!), then so much the better.
        >
        > Maybe this will be the impetus to get the GCC maintainers to finally wake up and include strlcat and strlcpy! :-)
        >
        > --TP

        gcc has nothing to do with strlcpy.

  3. By Anonymous Coward (212.77.163.101) on

    What are the efforts to include atmel-avr support into pcc ? Is it too early to ask about this ? I'm not good with compiler internals.

    Comments

    1. By Anonymous Coward (84.245.24.117) on

      > What are the efforts to include atmel-avr support into pcc ? Is it too early to ask about this ? I'm not good with compiler internals.

      i must say i thought about i too, would be very sweet!
      But the compiler is still in it's (new) infancy so maybe one day it will have AVR support but for the near future i think it's unlikely.

  4. By Anonymous Coward (151.61.219.53) on



    What about this new compiler by Ken Thompson?

    http://doc.cat-v.org/bell_labs/new_c_compilers/

    Comments

    1. By phessler (phessler) on http://theapt.org

      >
      >
      > What about this new compiler by Ken Thompson?
      >
      > http://doc.cat-v.org/bell_labs/new_c_compilers/
      >
      >

      what about it?

      also, how about an actual link to the code?

      Comments

      1. By Anonymous Coward (2001:960:719:0:20a:e4ff:fe36:23bc) on

        > what about it?
        >
        > also, how about an actual link to the code?

        http://code.google.com/p/inferno-os/source/browse/trunk/utils/
        (?a are the assemblers, ?c the c compilers, ?l the loaders)

        8 is 386, 5 arm, t thumb, 6 (preliminary) amd64, and there are some more.

        the man page:
        http://www.vitanuova.com/inferno/man/10/2c.html

        pretty much the same code, in plan 9:
        http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/

        i think the inferno version of the compilers is/was under a liberal licence, perhaps MIT. but it's all in google code as GPLv2 (google requires a single licence for a repository).

        the compilers don't generate elf though. there was a project (or several) to make them them emit elf binaries. one was for plan 9's google summer of code 2007. not sure what state that is in.

    2. By Anonymous Coward (189.187.24.38) on

      >
      >
      > What about this new compiler by Ken Thompson?
      >
      > http://doc.cat-v.org/bell_labs/new_c_compilers/
      >
      >

      Unnamed substructures are supported by both GCC and PCC as extensions, sans the automagic type promotion. (In fact, this feature is supported by almost all modern C compilers, including MSVC.)

      Structure displays and Initialization indexes are defined by C99 as "Compound literals" and "Named initializers", and both are supported by GCC and PCC.

    3. By David Chisnall (82.7.192.45) on

      > What about this new compiler by Ken Thompson?
      >
      > http://doc.cat-v.org/bell_labs/new_c_compilers/

      Did you read the linked paper. I can't imagine using that compiler for anything nontrivial. For example, it doesn't support volatile because it 'appears to have no meaning' which means you can't use multiple threads, variables in shared memory segments, setjmp()/longjmp() and so on reliably. The const keyword is also ignored. This is less important, because it just allows semantically invalid code to compile, rather than generating incorrect binaries from semantically valid code.

      It doesn't support #if, just #ifdef, which means pretty much all of the POSIX / SUS headers will fail to compile because they use standard version test macros.

      Also, 'new' is an interesting definition, since the page you linked to is from 1990.

      Comments

      1. By Anonymous Coward (150.101.245.181) on

        I have to agree with Ken regarding the volatile keyword (I read the paper, its a pity he doesn't elaborate on this idea). It seems to mean different things to different people. To me, it is a way to tell stupid vendor compilers not to be overzealous with optimisation. I would welcome a compiler that is smart enough not to need the volatile keyword.

        Comments

        1. By Anonymous Coward (85.164.133.231) on

          > I have to agree with Ken regarding the volatile keyword (I read the paper, its a pity he doesn't elaborate on this idea). It seems to mean different things to different people. To me, it is a way to tell stupid vendor compilers not to be overzealous with optimisation. I would welcome a compiler that is smart enough not to need the volatile keyword.

          Except that you can't; how can you tell a compiler to generate machine code that will fetch *only* those values from memory that need to be checked (e.g., locks) instead of cached in a register, without having a way to declare it?

          Sometimes, you really *do* know better than the compiler.

          Comments

          1. By Daniel (84.167.42.109) on

            The fact, that ken's compiler is used in plan9 indicates, that all theory and papers aside it actually works in practice.

            This post by Theo to the 9fans list documents, that inclusion into OpenBSD has even already been considered (the thought was later on dropped for licensing issues).

            Comments

            1. By Anonymous Coward (2a01:198:25d:0:20a:e4ff:fe32:17b2) on

              > The fact, that ken's compiler is used in plan9 indicates, that all theory and papers aside it actually works in practice.

              That was before it got released under MIT Licence as part
              of the Inferno operating system. Theo knows but doesn't
              seem to care, with no published reason.

              Comments

              1. By phessler (phessler) on http://theapt.org

                > > The fact, that ken's compiler is used in plan9 indicates, that all theory and papers aside it actually works in practice.
                >
                > That was before it got released under MIT Licence as part
                > of the Inferno operating system. Theo knows but doesn't
                > seem to care, with no published reason.

                so one version of it was released as MIT, but none of the fixes and changes are? Whoopie.

  5. By Anonymous Coward (131.177.240.34) on

    What about the LLVM / CLang combo that FreeBSD-8.0 is planning to include instead of GCC? Wouldn't it be a viable option too or was PCC chosen so there would be only a small optimized C-compiler and nothing else?

    Comments

    1. By Anonymous Coward (219.90.208.233) on

      I think the small code base of PCC was the main attraction (beyond licensing). Less is more.

    2. By Anonymous Coward (88.217.158.50) on

      > What about the LLVM / CLang combo that FreeBSD-8.0 is planning to include instead of GCC? Wouldn't it be a viable option too or was PCC chosen so there would be only a small optimized C-compiler and nothing else?

      LLVM is C++. That's first thing against it.

      Can LLVM/Clang compile itself? AFAIK Clang has limited support of C++,
      but what's that "limited" about? Does it mean that it can compile itself
      or not?

    3. By Michael Dexter (217.237.166.82) dexter@bsdfund.org on http://bsdfund.org/projects/pcc/

      > What about the LLVM / CLang combo...

      Have no fear, every such question has been raised and considered by everyone involved. The need for a lightweight, permissively-licensed C compiler remains.

      This call has brought in $505 to date.

      Excellent work everyone.

      Michael

    4. By David Chisnall (82.7.192.45) on

      > What about the LLVM / CLang combo that FreeBSD-8.0 is planning to include instead of GCC? Wouldn't it be a viable option too or was PCC chosen so there would be only a small optimized C-compiler and nothing else?

      I hack on clang, and it's a very different beast to PCC. Clang has a number of advantages over PCC:

      - Support for Objective-C, partial support for C++ (progressing well)
      - Massive optimisation back-end.
      - Commercial backing from a few companies and backing from a couple of universities.
      - Big static analysis framework.
      - Support for most GCC extensions (__builtin_apply() is about the only one missing and not planned for short-term implementation).
      - Library-based design intended to allow components to be easily reused in other projects (e.g. IDEs, other compilers).
      - Support for link-time optimisation and JIT compilation.

      PCC has a number of advantages over Clang:

      - Self-hosting (Clang is written in C++, so can't compile itself until C++ support is more finished).
      - Much simpler codebase (easier to review)
      - Simpler optimisation framework (easier to demonstrate correctness)
      - Pure C code (clang uses a 'tasteful subset' of C++. It's better than most C++ projects, but it's still a horrible language).
      - Very fast compilation.

      Both have some advantages over GCC:

      - Relatively easy code base for new developers (it took me under a week from first looking at clang to getting my first patch accepted).
      - BSD license (GCC is now GPLv3).
      - You don't have to deal with RMS.

      The elephant in the room for both is that there is still no replacement for GNU binutils, most importantly GNU ld. Both Clang and PCC still need GNU ld for linking and Clang needs gas for assembly (not sure about PCC).

      Comments

      1. By roman (89.173.82.36) on

        > The elephant in the room for both is that there is still no replacement for GNU binutils, most importantly GNU ld. Both Clang and PCC still need GNU ld for linking and Clang needs gas for assembly (not sure about PCC).

        there's elftoolchain project at sourceforge. clang wont need gas in a very short term (llvm-mc and the elfwriter project)

        I do agree that linker is missing

      2. By Medina Clavijo (ventejuy) on http://ventejuy.es

        Very good analisys. Thank you very much.

  6. By Anonymous Coward (84.250.94.207) on

    How about Randy Hyde's HLA?

    Comments

    1. By Anonymous Coward (150.101.245.181) on

      Haha. If you rewrite the entire OpenBSD tree, I'll port the HLA to the other supported architectures.

      Comments

      1. By Anonymous Coward (84.250.94.207) on

        > Haha. If you rewrite the entire OpenBSD tree, I'll port the HLA to the other supported architectures.
        Cynicism aside, this might be the way to go. If documentation is good enogh...

        Comments

        1. By Anonymous Coward (219.90.208.233) on

          Cynicism justified. UNIX used to be written in assembly, it has since been rewritten in a much more portable language. Most people appear happy with this new language....

          Comments

          1. By Anonymous Coward (84.250.94.207) on

            > Cynicism justified. UNIX used to be written in assembly, it has since been rewritten in a much more portable language. Most people appear happy with this new language....

            Well. Have a look of HLA. It has a quite huge macro library.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]