After having released FreeBSD 7.2 just a few days ago, the FreeBSD project now sends out a new quarterly status report, with information about development projects in progress. This report contains news on Clang replacing GCC, VirtualBox improvements, upcoming support for an NVIDIA 64-bit driver, some DTrace news, and more.
The most interesting bit in this status report is of course the progress made on replacing GCC with Clang, a compiler front-end for C, C++, and Objective-C which uses LLVM as its backend. Despite progress being made, Clang isn’t quite there yet to replace GCC for FreeBSD. “The last 3-4 months we’ve been working together with the LLVM developers to discuss any bugs and issues we are experiencing with their Clang compiler frontend. The FreeBSD project is looking at the possibility to replace GCC with Clang as a system compiler,” the status report reads, “It can compile 99% of the FreeBSD world and can compile booting kernel on i386/amd64 but it still contains bugs and its C++ support is still immature.”
They say that there currently are some blocker bugs, but that the LLVM developers are very helpful in trying to fix the bugs found by the FreeBSD team.
Another interesting tidbit is the port of VirtualBox to FreeBSD. “6 Days was needed to get virtualbox to start with over 20 patches. We’d like to say thanks to Alexander Eichner all vbox developers, Gustau Perez and Ulf Lilleengen. If you like to play with the current port you can checkout the port here.”
Be sure to take a look at the status report, there’s some interesting stuff in there.
YES! I cant wait until this comes into fruition, and I will be checking it out!
You may like this too:
http://www.nvnews.net/vbulletin/showthread.php?t=41545&page=27#td_p…
Just saw that actually, its good to see nvidia was actually interested in making it happen and not just paying lip service.
… Indeed.
Now if only they can add 64bit Linux binary support (and finish the FreeBSD qemu-kvm port), FreeBSD might find a place along side Linux on my main workstation. (As opposed to a play-testing VM under qemu-kvm)
– Gilboa
Step aside GCC, LLVM has a new backer
I’ve just had a look at FreeBSD throwing their weight behind it; couple that with Adobe and Apple – things are getting really interesting in the unsexy world of compilers 
I wondering whether we’ll see more people jump on the LLVM bandwagon – Linux? maybe even OpenSolaris? lots of cool stuff on the burner.
The mmap() extensions look cool, hopefully they get back on track with their scalability/smp effort given the rise of multi-core, the return of hyper-threading and rise of large multi-processor/multi-core monsters.
Can someone ‘sell’ me on LLVM? I’ve been reading about it for a while and gather that it is something that has the potential to be awesome, but I’ve never really understood why. Why should I as a Linux and BSD user and casual C++ developer be excited by LLVM? In what way is it better than gcc?
http://en.wikipedia.org/wiki/LLVM
The Wikipedia article gives a rather good impression about the project and its goals.
A compilation strategy designed to enable effective program optimization across the entire lifetime of a program. LLVM supports effective optimization at compile time, link-time (particularly interprocedural), run-time and offline (i.e., after software is installed), while remaining transparent to developers and maintaining compatibility with existing build scripts.
Source: http://llvm.org/
If that isn’t reason enough to be excited, please turn in your geek card now.
and don’t forget:
a) llvm’s and clang’s framework – like architecture that can be leveraged at the IDE level to provide much better integration for code checking, highlighting, refactoring and profiling
(ie the IDE could use the actual language front end -or the evaluation and AST- creation functions the language frontend too, uses- instead of a surrogate parser – OTOH the language frontend could update the actual AST in real time while user is typing)
b) llvm’s common cross – language IR and type system, and the inter-assembly optimizations that this makes possible…
😉
Etoile ( http://www.etoileos.com ) is using the second feature to create an object system that is language-agnostic. This allows Smalltalk to use classes from C-based libraries bound to Objective-C (and reference their instances) — and vice versa.
dagw wrote:
–“Why should I as a Linux and BSD user and casual C++ developer be excited by LLVM? In what way is it better than gcc?”
Well, unlike GCC which has been around for ages, LLVM which started around 2000 is more modern in it’s overall design and as such I gather it’s alot easier to try out/implement different optimizations (aswell as other architectural improvements). As for the current difference between the compilers, I’ve done some tests using the llvm-gcc-frontend and gcc and in the last two versions I’ve tried (4.3-4.4 vs 2.4-2.5) gcc still generates faster code (I used some of the shootout examples: nbody, fannkuch etc and also zlib). Also, I used ‘-march=native -o3 -fomit-frame-pointer -mfpmath=sse -msse3’ for my tests, other optimization levels/options might have rendered different results. If anyone has other tests/results/options I’m very interested!
However which one is on top in code speed at any given time is not the important thing here in my opinion, instead it is the fact that we got healthy competition in the open source compiler field. This will benefit end users of both compilers. And please let’s not drag this down to licence advocacy and instead stick to the technical pro’s and con’s.
Edited 2009-05-08 15:44 UTC
Python seems to be entering the game with this Google project:
http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
What? Compiler weren’t sexy? I didn’t get that memo.
Clang is already usable and competitive for C, but they are far away from having a usable C++ front end. Check out
http://clang.llvm.org/cxx_status.html
These are not obscure features that are missing; there are major holes. It’s going to be several person-years of intensive work. And then they’ll still rely on the GNU libstdc++.
In the meantime, it appears Apple is using a hybrid approach, with the GCC front ends and the LLVM back end. It will take them years to be GNU-free.
You do realise that the status can be (and most likely) out of date? you also realise that there is a heck of alot of working going on outside that of the community which will be merged at a later date?
Yes, there is still alot of work to be done but realise that there are now going to be more programmers jumping onboard and you’ll find that Clang will be feature complete quicker than you expected.
…now THIS is one of what I’ve been waiting to see. Great job!
The LLVM bitcode format, assuming you don’t use conditional compilation for your platform specifics nor your compiler implementation using macros rather than functions for the sizeof() and offsetof(), can generate code for any supported processor regardless of what processor it was compiled on. This means that packages compiled on Intels can be installed to PowerPC or ARM without the overhead of a separate binary. It also opens the door to closed-source software on POSIX platforms. With some work it even means that packagers will be able to create 64-bit apps from 32-bit packages.
For details see the -march flag on the LLC command. http://llvm.org/cmds/llc.html .
That VirtualBox port may not be necessary for long unless you’re running non-posix code.
Looking at the way FreeBSD is going it is looking like i will find a nice platform in the event that Oracle end up borking OpenSolaris
Awesomeness ensues!
I’ve been praying for a port of virtualbox to make the switch. Now my problem is that I’ve moved on to a laptop, away from my desktop system. Gardangit!!
Ah well, if and when I get another table-top system FreeBSD is going on that bugger. I ran the 5.x branch and absolutely loved it as a server and an every day system.
It seems BSD people does not care others. It always insist to occupy one primary partition without any real reason. My machine has a few OSes installed already and the free spaces are only at logical partitions, hmm, the refusal to address this problem has blocked lot of potential users. I am not sure how difficult it is, but from my understanding of partitions, it should not be that difficult given the capability of BSD people.