Date: Fri, 16 Jan 2009 11:46:29 -0000 From: "Pegasus Mc Cleaft" <ken@mthelicon.com> To: "O. Hartmann" <ohartman@zedat.fu-berlin.de>, "Anton Shterenlikht" <mexas@bristol.ac.uk> Cc: freebsd-current@freebsd.org Subject: Re: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) Message-ID: <B37B6C09E4B94843AC71CECE3B32CB1E@PegaPegII> In-Reply-To: <497064C6.5070807@zedat.fu-berlin.de> References: <de2964020901141507m5a30c466ta1e05694d220ce0b@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----
From: "O. Hartmann" <ohartman@zedat.fu-berlin.de>
To: "Anton Shterenlikht" <mexas@bristol.ac.uk>
Cc: <freebsd-current@freebsd.org>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B37B6C09E4B94843AC71CECE3B32CB1E>