Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?)

[Pegasus Mc Cleaft]

----- Original Message ----- 
From: "O. Hartmann" <ohartman at zedat.fu-berlin.de>
To: "Anton Shterenlikht" <mexas at bristol.ac.uk>
Cc: <freebsd-current at 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