From owner-freebsd-current@FreeBSD.ORG Fri Jan 16 11:48:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CF0710656D6 for ; Fri, 16 Jan 2009 11:48:19 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id B022C8FC22 for ; Fri, 16 Jan 2009 11:48:18 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from PegaPegII (93-152-14-233.daisydsl.managedbroadband.co.uk [93.152.14.233]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n0GBkTcY004371; Fri, 16 Jan 2009 11:46:31 GMT (envelope-from ken@mthelicon.com) Message-ID: From: "Pegasus Mc Cleaft" To: "O. Hartmann" , "Anton Shterenlikht" References: <20090115084515.GA91157@freebsd.org><496FBFCD.6010302@FreeBSD.org> <7d6fde3d0901152315y7c6ce36fqe137519bd73e3e@mail.gmail.com><20090116100932.GB36588@mech-cluster238.men.bris.ac.uk> <497064C6.5070807@zedat.fu-berlin.de> In-Reply-To: <497064C6.5070807@zedat.fu-berlin.de> Date: Fri, 16 Jan 2009 11:46:29 -0000 Organization: Feathers MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-15"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 X-Antivirus: avast! (VPS 090115-0, 15/01/2009), Outbound message X-Antivirus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pegasus Mc Cleaft List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 11:48:20 -0000 ----- Original Message ----- From: "O. Hartmann" To: "Anton Shterenlikht" Cc: Sent: Friday, January 16, 2009 10:43 AM Subject: Re: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) > Anton Shterenlikht wrote: >> On Thu, Jan 15, 2009 at 11:15:52PM -0800, Garrett Cooper wrote: >>> the end. Take Gentoo Linux: it's a Linux distribution riddled with >>> choices -- so many bloody choices that one has to make to get a >>> working system, that just one library going south with the wrong >>> option can set you back hours or days in order to get up and going >>> again... we shouldn't go down that road or we'll just be begging for >>> pain, if not from a support end, then from a user endpoint because >>> we'll be more efficient manufacturers of rope than ever before, and >>> users will be isolated from folks trying to reproduce their issues. >> >> As a FBSD user I'm really happy with the current balance between >> freedom of choice and order. This was the thing that attracted me >> first to FBSD (v 4.9), after being thoroughly confused by linux anarchy. >>>From my point of view this is the ideal balance, and this is what makes >> FBSD stand apart from linux and other BSDs. >> >> Too much choice is not always a good thing. >> >> yours >> anton >> > > .. but having NO or a very RESTRICTED choice could lead to a dead end, see > performance, modern parallel techniques (OpenMP) and new > built-in-silica -features. If the 'dictated choice' of the compiler leads > also development of the OS's interna (by taking care of having no specific > features like SSE3/4/4.1/4.2 for basic libc-features like memcopy etc due > to the danger the compiler/binutils will not target this in all cases or > whilst the development of the compiler stagnated and therefore those > features could not be used), this could also be the end for the OS. > > Switching back to an hopeless outdated relict from the past (pcc) means > having years of development and invention bringing those compiler suits > back to the recent state of the art and this means the OS that relies on > those strange political directions could end up behind competitors. This > may sound stupid for several people here, but Within the 13 years with > FreeBSD now, I saw many departments switching from FreeBSD to Linux and > moneyflow is in most cases directed towards expected profit. Since BSD > isn't developed as an academic approach of an OS, it is highly dependend > on a pseudo-commercial success finding new donations hiring developer (not > scientists, what a pitty). Hello Everyone, Perhapse i'm missing something. I have to admit that I dont know much about how something like a complete OS is compiled, most of the stuff I do is in userland with the occational driver here and there, but I wonder how much "direction" is actually given in source to utilize various CPU options/instructions/registers, etc. I know there is a need in assembly to do this for low-level things, but aside from that, I would think its up to the C compiler to make the choice based on what it knows, optimizations set, vectorizing, etc.. In my, probably ill informed opinnion, the problem we are facing is not a C compiler problem, its an assembler problem. We can install a better C compiler of our choice through the ports, but its the base assembler & linker that lets us down because it dosent know about modern CPU opcodes and registers (IE: SSE4.x). So, even if you have a better/more recent compiler, you still cant use the latest options. Building, for instance, gcc43 is fairly painless through the ports, but this is of limited use as it will use the base assembler, linker, et al. Even if you install, as I have, the latest binutils from GNU, it will locate /usr/bin/as before /usr/local/bin/as. If you set all the enviroment varables (AR, AS, NM, ...) before you do the build, you run into other problems with finding the bootstrap files later due to the naming problems between "x86_64-obrien-freebsd" and the auto-generated "x86_64-unknown-freebsd8.0" from the GNU configure. In short, I found upgrading the dev-chain a real nightmare. What I personally think should be done is keep gcc4.2 as the standard "base" compiler (and binutils 2.15) being only accessable through the standard "cc" command. Make binutils a port that is updated and plays nice with the gcc4.x (and later) port. Make CPUTYPE in /etc/make.conf a familty variable (ie: AMD64, 386, arm, sparc....) and have another variable CPUARCH that is a pass through to the compiler so you can specify -march=[core2][bakedpotato][bananna],etc. Have the base "generic" kernel compiled agaisnt the lowest common denominator for a perticular family and let the admins build the tools and recompile for the latest and greatest as specified by the CPUARCH variable (not so different then how it is done now, in a way). I do realize this will make BSD run sub-optimally until the admin recompiles the kernel and world for his machine. Would this be opening up a huge can of worms if done this way? ~Peg