about gcc >=4.2 in base

GCC 4.2.1 supports OpenMP, as slow as the generated executable is. Would this be something that the replacement compiler should support since SMP is so important now more than ever?
 
oliverh said:
What production? Probably userland in OpenBSD.
You can compile kernel as well if you apply couple patches which I think are already in current:). In my understanding the only thing in the base of the OpenBSD which can not be compiled is obviously Groff since PCC is C only compiler and Groff is C++.
There is a lengthy discussion on undeadly.org/ about Groff "problem". It is too bad that Heirloom Troff has CDDL license but Nroff used by Minix has BSD license. There is also
MirBSD version of Nroff which has BSD license. I have also heard of one of your fellow Germans working on the Troff "problem" for OpenBSD as we speak;)
 
I waited a few days and there are no comments regarding my question about OpenMP support. See 2 comments above.

Thanks
 
Which is that new compiler

Oko said:
...hand OpenBSD/NetBSD are developing new compiler;)

May i know the name of that new compiler please. (OR is it PCC itself ? )
Any URL or project home page.

Thanks in advance
 
estrabd said:
GCC 4.2.1 supports OpenMP, as slow as the generated executable is. Would this be something that the replacement compiler should support since SMP is so important now more than ever?
The short answer is I do not know.

The longer one is that if I have to guess support for OpenMP is
very, very low priority. The most important thing from the point of view of OpenBSD/NetBSD community is for PCC to generate correct, efficient, and small machine serial code. It is also very important that PCC is very portable as well that it has clear separation of front and back ends which will enable creation of some very interesting new tools for debbuging and code analysis. One of high priorities of PCC is to create so
efficient machine code that it could be executed theoretically on
PDP-11 as well as on the newest SUN blade.

Generating parallel machine code would add another layer of complexity and insecurity. SMP support is only moderately important at least for OpenBSD and it will remain like that probably for the very long time. Multi core CPUs are still very buggy and in some sense even dangerous from the security point of view.

I hope that somebody with greater technical knowledge of the issues would comment on your interesting question.
 
Interesting developments on CURRENT:

&quot said:
Hi,


Clang is a new frontend for C-like languages for LLVM. It's modern, BSD
licensed compiler that produces roughly the same code quality or better
as GCC. It's still in its development phase but quite mature. It includes
static analyzer as well.

And yes, it can compile FreeBSD kernel that actually boots and works. Not
as stable as GCC yet but the Clang team is working on that. The userland
needs some more work but a lot works already.

You can try yourself, the details are described here:


http://wiki.freebsd.org/BuildingFreeBSDWithClang


basically you just install devel/llvm-devel port, compile the kernel with -O1
and boot. Don't forget to try out the static analysis.

We'd like to encourage you to try this out and test stuff. We can't test
everything. In a case of problems (there sure will be) please contact me or
Pawel.

thank you!

your clang@freebsd team

Roman Divacky, Pawel Worach and Brooks Davis
 
trasz@ said:
... We are not developing the compiler. We don't want to... .

If we are not developing the compiler (PCC) but OpenBSD/NetBSD, which have a lot less resources than we do are ... what's the really good reason we are not pitching in?

OpenBSD/NetBSD are working on PCC
DragonFlyBSD is working on HAMMER and dma
OpenBSD keeps working on OpenSSH and is working on OpenSMTPD, OpenNTPD, OpenCVS, etc ..

and while they, with the limited resources they have (special mention goes to DragonFlyBSD) keep pushing the limits of Computer Science .. we are porting ZFS and Dtrace ...?

I think I'll be cancelling my FreeBSD subscription and start buying OpenBSD CDs and donating money to DragonFlyBSD ...

They make Computer Science keep walking and they need my money a lot more than Sun does ...
 
gnemmi said:
DragonFlyBSD is working on HAMMER and dma
If Matt Dillon can really pull up native kernel support for clustering DragonFly will by far the most interesting Open Source project.
 
If Dillon can pull that .. he would be taking CS to the next step ...

BTW ... I just found out that:
As you may have read some days ago, work has started to make the FreeBSD base system compile better with clang, the BSD licensed C compiler from the LLVM project.

and that:

After some talking on IRC, I think the best solution would be to rename all functions in libmp. Even though this may sound very awful at first, it seems the competition has done this as well:
http://docs.sun.com/app/docs/doc/819-2246/mp-3mp?a=view

Here's the original: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-February/027833.html

So .. I guess we seem to be competing with SUN instead of contributing to the development of BSDs ..

If I wanted to use Microsoft Word/IE/OutLook, or play games on my PC .. I'd be using Microsoft Windows ...

If I wanted to use Quick Look, iChat, Safari or benefit from Time Machine or Finder .. I'd be using Mac OS X

... and just in case I wasn't clear enough .. if I wanted to use OpenSolaris .. I would be using OpenSolaris ... not FreeBSD

I just want to use and contribute to the development of BSD systems in order to keep pushing the limits of CS ... instead of economically contributing to the cooking of a new product.

If FreeBSD chooses to turn into a SUN competitor instead of a BSD contributor, then I guess there's no more room for me amongst it's lines.
 
Reinventing the wheel is pushing the borders of CS? Uhm, what?
The Dragonfly clustering work might be impressive (we'll see when it becomes usable), but it' not exactly a new idea. As examples, there are VMS clusters out there that have uptimes comparable to the age of the FreeBSD project, and plan 9 can share the oddest things over the network. I do hope it will work out; it would be a nice addition. But it's not taking anything to "the next level".

FreeBSD needed a new better FS. We found a good tested one developed by someone with an interest in getting it right, and imported it. Huge value for the time spent.
The main focus of recently seems to have been on scaling nicely over many cores on a single computer. It doesn't sound as impressive, but it's no less useful for that.
 
Djn said:
there are VMS clusters out there that have uptimes comparable to the age of the FreeBSD project, and plan 9 can share the oddest things over the network. I do hope it will work out; it would be a nice addition. But it's not taking anything to "the next level".
On AIX as well. Do you have five million dollars for a solid IBM server? I didn't think so. Of course the most thing we are talking about were done or started 20 years ago on proprietary Unix. The problem is that in the mean time most of them went bankrupt and people are reinventing the wheel all the time on i386.

Tell me a single innovation that came out of Linux. Nothing, absolutely nothing after so much money spend by major corporations. In the mean time SUN made some major innovations. Like DTrace or ZFC for instance and SUN is dying.
 
That's a reasonable summary, yes. And that's why I'm quite happy that FreeBSD is adopting technologies from Sun - they're good solid ideas that it would be a shame to see die.

How is the clustering support in solaris, by the way? I don't mean that we should import it from them (clustering sounds like the kind of technology that's far too integrated to easily separate & port), but it would be a cheaper alternative to AIX/OpenVMS/the like if it's any good.
 
Coming in late - I only see idealistic arguments against FreeBSD's course, "contributing to *BSD's", "pushing the limits of CS", "C++ in an OS is crap".
While these are valid points, they shouldn't be a deciding factor in any OS that wants to be used in production environments. While a lot of donations to FreeBSD come from embedded products, it's usage ranges from desktop, webserver, storage unit to firewall/router. In those environments, nobody cares about the footprint of an install CD, language used for a compiler, or whether new innovations have been made. The important points are SMP, network and IO throughput, disk management, ease of software and OS maintenance and mainstream hardware support. Of these, only the last has declined.
In the end, I wouldn't care if FreeBSD shipped a binary compiler by default and kept the sources in perforce, saves me quite a few stages during buildworld. I also don't care if my filesystem is a "lame port" or "impressive innovation", ultimately, I need my data to be safe, read and written fast and resistant to hardware failures.

I certainly welcome a new compiler, if it means faster code and it's license doesn't restrict my usage of it (in that order). Yet, it's not on my FreeBSD wish list as I can get by without one on production machines, by using freebsd-update and pkg_add or a buildserver and nfs. And there's far more pressing issues (usb2, anyone sick of Xorg yet?, lagg(4)+WPA+hostap, to name a few).
 
Oko said:
The short answer is I do not know.

The longer one is that if I have to guess support for OpenMP is
very, very low priority. The most important thing from the point of view of OpenBSD/NetBSD community is for PCC to generate correct, efficient, and small machine serial code. It is also very important that PCC is very portable as well that it has clear separation of front and back ends which will enable creation of some very interesting new tools for debbuging and code analysis. One of high priorities of PCC is to create so
efficient machine code that it could be executed theoretically on
PDP-11 as well as on the newest SUN blade.

Generating parallel machine code would add another layer of complexity and insecurity. SMP support is only moderately important at least for OpenBSD and it will remain like that probably for the very long time. Multi core CPUs are still very buggy and in some sense even dangerous from the security point of view.

I hope that somebody with greater technical knowledge of the issues would comment on your interesting question.

I agree that one needs to crawl before he walks. I would like to point out that OpenMP is a standard supported by all of the major HW snf compiler vendors (often one and the same), and GNU supports this.

http://openmp.org/wp/openmp-compilers/

For example, IBM's XL suite has provided a "thread safe" version (*_r) if their compilers (as well as their own MPI libraries for distributed memory environments) by default on their power series machines for sometime; granted, my experience in seeing this has been isolated to HPC environments; so it's a virtually a requirement to provde this.

*However*, OpenMP is only one threading library that IBM's XL suite does (or intends) to support - *so,* given IBM's approach (i.e., a distinclty separate "thread safe" version of each compiler), maybe the same approach can be taken /once/ an initial switch is made - there is no immediate reason that any new base compiler needs to support these things. It could be a concurrent effort once things are settled. After all, I would assume that GCC >= 4.2.1 will most likely still be available via packages. That said, a thread-safe version of any base compiler would be nice - not only for testing base SMP installations, but also for eventual (and fairly easy) utilization of such capabilities in the base code itself.

I would also like to note that I am playing around with a couple of simple codes that are meant to help me evaluate FreeBSD's SMP progress, and they all use OpenMP as supported by the current base compiler - GCC 4.2.1. I think it is incredible that the base compiler does support OpenMP, so it makes sense to center some basic testing around it.
Cheers
 
Oko said:
OpenBSD will have entire tool chain based on its own code hopefully within next two years.

What do you mean "entire tool chain" ? OpenBSD's own as(assembler) instead gas ? OpenBSD's own ld(link editor) instead GNU's version? Or just PCC instead gcc ?
 
Back
Top