Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Russ Allbery]

Tim Riker <Tim@Rikers.org> writes:

> Agreed. C99 does not replace all the needed gcc features. We should
> start using the ones that make sense, and push for
> standardization/documentation on the rest.

> I'm perfectly happy with this as a long term goal. I'll put what effort
> I can into moving that direction without breaking the existing world as
> we know it.

May I tentatively suggest that one point at which your resources could
productively be applied is towards improving the C99 compliance in gcc?
Clearly for the near to medium future the compiler that everyone will use
to build the Linux kernel will be gcc, which means that in order to use
any C99 syntax, it first has to be solid in gcc.  That means the best way
of introducing such things into the Linux kernel is to *first* get the C99
support solid, reliable, and efficient in gcc, then once a version of gcc
is released with that support, help get Linux compiling with that version
of gcc.

*Then*, when that version of gcc can be made a prerequisite for the
kernel, you can start switching constructs over to the C99 syntax that gcc
supports.

This is obviously a slow and drawn-out process, but in the end the free
software community not only gets a better-documented syntax in the Linux
kernel code that's more likely to be clearly supported and not broken by
gcc in the future, but the broader community also gets a more closely
conforming compiler that supports the latest C features.

<http://gcc.gnu.org/c99status.html> has the current status of the
development versions of gcc.  There are a lot of items listed as Broken or
Missing that I'm sure the gcc developers would welcome volunteer help
with.

(Note that there is not and quite likely never will be any standard syntax
for in-line assembly, as the standardization committee considers it to be
outside their scope, so I doubt you'll ever be completely successful.  But
I think your goal is one that can reap benefits even when only partially
accomplished.)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Michael Meissner]

On Fri, Nov 03, 2000 at 10:19:12PM -0800, Russ Allbery wrote:
> Tim Riker <Tim@Rikers.org> writes:
> 
> > Agreed. C99 does not replace all the needed gcc features. We should
> > start using the ones that make sense, and push for
> > standardization/documentation on the rest.
> 
> > I'm perfectly happy with this as a long term goal. I'll put what effort
> > I can into moving that direction without breaking the existing world as
> > we know it.
> 
> May I tentatively suggest that one point at which your resources could
> productively be applied is towards improving the C99 compliance in gcc?
> Clearly for the near to medium future the compiler that everyone will use
> to build the Linux kernel will be gcc, which means that in order to use
> any C99 syntax, it first has to be solid in gcc.  That means the best way
> of introducing such things into the Linux kernel is to *first* get the C99
> support solid, reliable, and efficient in gcc, then once a version of gcc
> is released with that support, help get Linux compiling with that version
> of gcc.
> 
> *Then*, when that version of gcc can be made a prerequisite for the
> kernel, you can start switching constructs over to the C99 syntax that gcc
> supports.

Hmmmmm.  Last month the compiler related thread on the kernel list was the
kernel couldn't move to newer versions of the compiler because the compiler had
changed things (where newer might mean either the latest snapshot de jour, or a
tested/appropriately patched version based off of the snapshots, or even 2.95).
Now people seem to be advocating moving the kernel to use features from C99
that haven't even been coded yet (which mean when coded using the latest
codegen as well).  Note, I seriously doubt Linus will want a flag day (ie,
after a given kernel release, you must use revision n of the compiler, but
before that release, you must use revision n-1 of the compiler), so you still
have to maintain support for the old GCC way of doing things, in addition to
the C99 way of doing things probably for a year or so.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Russ Allbery]

Michael Meissner <meissner@spectacle-pond.org> writes:
> On Fri, Nov 03, 2000 at 10:19:12PM -0800, Russ Allbery wrote:

>> May I tentatively suggest that one point at which your resources could
>> productively be applied is towards improving the C99 compliance in gcc?
>> Clearly for the near to medium future the compiler that everyone will
>> use to build the Linux kernel will be gcc, which means that in order to
>> use any C99 syntax, it first has to be solid in gcc.  That means the
>> best way of introducing such things into the Linux kernel is to *first*
>> get the C99 support solid, reliable, and efficient in gcc, then once a
>> version of gcc is released with that support, help get Linux compiling
>> with that version of gcc.

>> *Then*, when that version of gcc can be made a prerequisite for the
>> kernel, you can start switching constructs over to the C99 syntax that
>> gcc supports.

> Hmmmmm.  Last month the compiler related thread on the kernel list was
> the kernel couldn't move to newer versions of the compiler because the
> compiler had changed things (where newer might mean either the latest
> snapshot de jour, or a tested/appropriately patched version based off of
> the snapshots, or even 2.95).

That's why I have the bit above about "help get Linux compiling with that
version of gcc."  My understanding is that the Linux core developers want
to support newer versions of gcc as they come out, but that it's a slow
process and relies on volunteers tracking down what's changed in gcc and
updating the kernel to either use coding constructs that work better with
a newer gcc or to use appropriate flags to turn off new gcc features that
don't work well with the kernel (like strict-aliasing).

Clearly people who have a strong interest in being able to use newer
versions of gcc for kernel compiles (such as people who want to
*eventually* be able to use some C99 features) are the best people to help
do this work since they'll be scratching their own itch, so to speak.

> Now people seem to be advocating moving the kernel to use features from
> C99 that haven't even been coded yet (which mean when coded using the
> latest codegen as well).

People may be advocating that, but I think that in my message above, I'm
pretty clearly *not* advocating this.  I'm saying that if the goal is to
eventually be able to use C99 syntax in the Linux kernel, the obvious
first step that has to be accomplished before that goal is even remotely
possible is to make sure that the compiler that the kernel uses has good
C99 support.  And that achieving this goal has many benefits for the
community as a whole at the same time.

We have to get to point A before we can get to point H.  That doesn't mean
that point A leads directly to point H without the intervening B-G.  :)

> Note, I seriously doubt Linus will want a flag day (ie, after a given
> kernel release, you must use revision n of the compiler, but before that
> release, you must use revision n-1 of the compiler), so you still have
> to maintain support for the old GCC way of doing things, in addition to
> the C99 way of doing things probably for a year or so.

It depends on the time scale.  I don't believe compilers older than 2.7.2
are really supported any more, are they?  And I would expect that before
*too* much longer, compilers older than egcs 1.1 won't be supported any
more, since some of the bugs in 2.7.2 are already raising their heads.

With time, the kernel does eventually change its minimum supported gcc
version number.  As soon as that minimum supported version number reaches
a version of gcc that supports a C99 feature, that feature can then
reasonably be used in the kernel.  It's quite possible, even likely, that
having the C99 feature isn't enough reason to move the minimum supported
version number by itself, but with enough patience it will creep forward
anyway.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Horst von Brand]

Michael Meissner <meissner@spectacle-pond.org> said:

[...]

> Now people seem to be advocating moving the kernel to use features from C99
> that haven't even been coded yet (which mean when coded using the latest
> codegen as well).  Note, I seriously doubt Linus will want a flag day (ie,
> after a given kernel release, you must use revision n of the compiler, but
> before that release, you must use revision n-1 of the compiler), so you still
> have to maintain support for the old GCC way of doing things, in addition to
> the C99 way of doing things probably for a year or so.

The recommended compiler is changing, it is now up to egcs-1.1.2. There is
a long lag, to be sure.

In any case, C99 _will_ come, so it is worthwhile to rewrite gcc-isms that
C99 does differently and egcs-1.1.2 supports *if* it doesn't impose a
penalty of some other sort. The point is that many gcc extensions are
poorly documented and moreover their semantics have changed over time (The
kernel is one of the main users of gcc extensions, other software has to
cater for being compiled with other compilers, and is thus more restricted
here. I'd guess glibc is second here. Little used extensions tend to be
broken or wobbly.). C99 is well documented, but the implementation of its
features might not be solid yet...

Named structure initializers and varargs macros come to mind. The code
should also be checked for possible use of restrict parameters.
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[yodaiken]

On Tue, Nov 07, 2000 at 01:52:59PM -0700, Tim Riker wrote:
> As was mentioned before, there are nonproprietary compilers around as
> well that might be good choices. My point is that the ANSI C steering
> committee is probably a more balanced forum to determine C syntax than
> the gcc team. We should adopt c99 syntax where feasible, for example. I
> am not asking anyone to use a proprietary compiler of they do not choose
> to do so.

The two problems with your "point" are (1) there is no evidence in its 
favor and (2) you have an alternative reason for making such an 
argument and by not either making it explicit or explicitly denying
it, you appear to be simply trying to disguise a marketing strategy 
in a pseudo-technical argument.  

-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[David Lang]

Dick Johnson,
  earlier in the discussion there was a post of the 'incompatabilities'
that were noted and one of the replies to that listed several c99 tools
available to do the same job with the c99 syntax, so there are at least
some cases where things are done the gcc-only way instead of the c99 way.

nobody is suggesting that the kernel loose functionality to achieve
portability, the suggestion was mearly to be portable where possible and
clearly mark the places where gcc-isms are used and why.

David Lang




 On Tue, 7 Nov 2000, Richard B. Johnson wrote:

> Date: Tue, 7 Nov 2000 16:06:28 -0500 (EST)
> From: Richard B. Johnson <root@chaos.analogic.com>
> To: Tim Riker <Tim@Rikers.org>
> Cc: Jes Sorensen <jes@linuxcare.com>,
>      Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Subject: Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)
> 
> On Tue, 7 Nov 2000, Tim Riker wrote:
> 
> > Jes,
> > 
> > Hey how's Itanium been lately?
> > 
> > As was mentioned before, there are nonproprietary compilers around as
> > well that might be good choices. My point is that the ANSI C steering
> > committee is probably a more balanced forum to determine C syntax than
> > the gcc team. We should adopt c99 syntax where feasible, for example. I
> > am not asking anyone to use a proprietary compiler of they do not choose
> > to do so.
> > 
> 
> But we __do__ use c99 syntax wherever possible. However, not all
> of the kernel can be written strictly in 'C'. We need to use some
> assembly language for the hardware-specific stuff. Gcc provides
> those capabilities. We also need to control the alignment of
> some structure members because networking, SCSI, and a few other
> links to the outside world count on that. Gcc provides this
> capability also. It's a damn good tool.
> 
> 
> Cheers,
> Dick Johnson
> 
> Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
> 
> "Memory is like gasoline. You use it up when you are running. Of
> course you get it all back when you reboot..."; Actual explanation
> obtained from the Micro$oft help desk.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Richard B. Johnson]

On Tue, 7 Nov 2000, David Lang wrote:

> Dick Johnson,
>   earlier in the discussion there was a post of the 'incompatabilities'
> that were noted and one of the replies to that listed several c99 tools
> available to do the same job with the c99 syntax, so there are at least
> some cases where things are done the gcc-only way instead of the c99 way.
> 
> nobody is suggesting that the kernel loose functionality to achieve
> portability, the suggestion was mearly to be portable where possible and
> clearly mark the places where gcc-isms are used and why.
> 
> David Lang

Sure, but certain c99 things, like `pragma` tend to be global to
a file so they look like they might work, but then tend to have
other unwanted side effects (pack comes to mind).


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Richard B. Johnson]

On Tue, 7 Nov 2000, Tim Riker wrote:

> Jes,
> 
> Hey how's Itanium been lately?
> 
> As was mentioned before, there are nonproprietary compilers around as
> well that might be good choices. My point is that the ANSI C steering
> committee is probably a more balanced forum to determine C syntax than
> the gcc team. We should adopt c99 syntax where feasible, for example. I
> am not asking anyone to use a proprietary compiler of they do not choose
> to do so.
> 

But we __do__ use c99 syntax wherever possible. However, not all
of the kernel can be written strictly in 'C'. We need to use some
assembly language for the hardware-specific stuff. Gcc provides
those capabilities. We also need to control the alignment of
some structure members because networking, SCSI, and a few other
links to the outside world count on that. Gcc provides this
capability also. It's a damn good tool.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Tim Riker]

Jes,

Hey how's Itanium been lately?

As was mentioned before, there are nonproprietary compilers around as
well that might be good choices. My point is that the ANSI C steering
committee is probably a more balanced forum to determine C syntax than
the gcc team. We should adopt c99 syntax where feasible, for example. I
am not asking anyone to use a proprietary compiler of they do not choose
to do so.

Jes Sorensen wrote:
> 
> >>>>> "Tim" == Tim Riker <Tim@Rikers.org> writes:
> 
> Tim> Alan Cox wrote:
> >>  > 1. There are architectures where some other compiler may do
> >> better > optimizations than gcc. I will cite some examples here, no
> >> need to argue
> >>
> >> I think we only care about this when they become free software.
> 
> Tim> This may be your belief, but I would not choose to enforce it on
> Tim> everyone. Thank you for you opinion.
> 
> Then don't try to enforce proprietary compilers on the kernel
> developers either. It's the developers who write the kernel and they
> use gcc extensions. There is no reason to cripple the kernel to
> satisfy people who wants to use proprietary software to compile it -
> not our problem.
> 
> Jes
-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Jes Sorensen]

>>>>> "Tim" == Tim Riker <Tim@Rikers.org> writes:

Tim> Alan Cox wrote:
>>  > 1. There are architectures where some other compiler may do
>> better > optimizations than gcc. I will cite some examples here, no
>> need to argue
>> 
>> I think we only care about this when they become free software.

Tim> This may be your belief, but I would not choose to enforce it on
Tim> everyone. Thank you for you opinion.

Then don't try to enforce proprietary compilers on the kernel
developers either. It's the developers who write the kernel and they
use gcc extensions. There is no reason to cripple the kernel to
satisfy people who wants to use proprietary software to compile it -
not our problem.

Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Ralf Baechle]

On Sat, Nov 04, 2000 at 12:34:23AM -0500, Aaron Sethman wrote:

> > SGI's pro64 is free software and AFAIK is able to compile a kernel on IA64.
> > It is also not clear if gcc will ever produce good code on IA64.
> 
> Well if its compiling the kernel just fine without alterations to the
> code, then fine. If not, if the SGI compiler is GPL'd pillage its sources
> and get that code working in gcc. Otherwise, trying to get linux to work
> with other C compilers doesn't seem worth the effort. 

Pro64 is gcc derived and intended to be 100% source compatible with gcc.
Past experience with new optimizations in gcc is they they frequently
triggered bugs in the kernel source which simply was relying on the code
generation working in a certain way.  Given that and assuming that the
degree of Pro64's optimizations is somewhat revolutionary when compared
to gcc I would expect that we'll hit a number of kernel bugs.  I'm not
even thinking about actual Pro64 bugs itself.

  Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Kai Henningsen]

meissner@spectacle-pond.org (Michael Meissner)  wrote on 04.11.00 in <20001104222835.A27549@munchkin.spectacle-pond.org>:

> On Sat, Nov 04, 2000 at 02:24:00PM +0200, Kai Henningsen wrote:
> > ak@suse.de (Andi Kleen)  wrote on 02.11.00 in
> > <20001102212124.A15054@gruyere.muc.suse.de>:
> >
> > > again with a different syntax than gcc [I guess it would have been too
> > > easy to just use the gcc syntax]
> >
> > One of the big problems in C99 was that there was nobody on the committee
> > who really understood gcc well, so the committee had problems using gcc
> > solutions given that nobody would be able to really describe them.
>
> Or the GCC syntax was too limited to do all of what the committee wanted.

Well, what I wrote was a paraphrase from what committee members said in  
comp.std.c.

> > And the reason no such expert was there was that the FSF didn't send
> > anyone, because they seem to think standards tend to ignore what they want
> > to do.
>
> Actually, RMS had quite a lot of influence on the original standard, even
> though he didn't attend the meetings.  His replies to the public comment
> period were fairly long and real insightful.  Even if some of his issues
> were voted down, they were discussed over quite a few meetings.

And what I wrote here was another paraphrase - from memory - of what a gcc  
guy said on the same group.

Deja will show the context, in case that's not beyond its current event  
horizon.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Michael Meissner]

On Sat, Nov 04, 2000 at 02:24:00PM +0200, Kai Henningsen wrote:
> ak@suse.de (Andi Kleen)  wrote on 02.11.00 in <20001102212124.A15054@gruyere.muc.suse.de>:
> 
> > again with a different syntax than gcc [I guess it would have been too easy
> > to just use the gcc syntax]
> 
> One of the big problems in C99 was that there was nobody on the committee  
> who really understood gcc well, so the committee had problems using gcc  
> solutions given that nobody would be able to really describe them.

Or the GCC syntax was too limited to do all of what the committee wanted.

> And the reason no such expert was there was that the FSF didn't send  
> anyone, because they seem to think standards tend to ignore what they want  
> to do.

Actually, RMS had quite a lot of influence on the original standard, even
though he didn't attend the meetings.  His replies to the public comment period
were fairly long and real insightful.  Even if some of his issues were voted
down, they were discussed over quite a few meetings.

I was on the original ANSI C committee from its founding, through the C89
standard, and for a year or two afterwards as the initial changes for C99 were
discussed, for a total of 10 1/2 years (representing first Data General, then
for OSF, though the early Data General years were before I switched over to
GCC).  Towards the end, I was rather burned out by the process, and didn't push
too hard at Cygnus to go to the meetings, and nobody seemed willing to step in
(at the time Cygnus only had 4 GCC engineers, and like now there was always
more GCC work to do than bodies to do work).  The trouble is it takes a lot of
time from your paying job to actively participate (figure 4 week long meetings
a year, plus the time to read documents, wordsmith, etc.).

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Kai Henningsen]

ak@suse.de (Andi Kleen)  wrote on 02.11.00 in <20001102212124.A15054@gruyere.muc.suse.de>:

> again with a different syntax than gcc [I guess it would have been too easy
> to just use the gcc syntax]

One of the big problems in C99 was that there was nobody on the committee  
who really understood gcc well, so the committee had problems using gcc  
solutions given that nobody would be able to really describe them.

And the reason no such expert was there was that the FSF didn't send  
anyone, because they seem to think standards tend to ignore what they want  
to do.

It's a classic vicious circle.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Kai Henningsen]

alan@lxorguk.ukuu.org.uk (Alan Cox)  wrote on 02.11.00 in <E13rRk1-0001ut-00@the-village.bc.nu>:

> > How can I insure that the largest possible amount of my efforts benefit
> > the community at large? Hopefully this will make it easier to move to
> > C99 or any other future compiler porting project.
>
> The asm I dont know - its a hard problem.

Anyone interested in looking at the asm problem, the Free Pascal Compiler  
(GPL) seems to be able to read several different Pascal inline asm  
variants and translate them into several different output asm variants,  
but only for Intel code. That should at least give some hints about the  
problem.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Kai Henningsen]

hch@caldera.de (Christoph Hellwig)  wrote on 02.11.00 in <200011022106.WAA18428@ns.caldera.de>:

> In article <3A01D463.9ADEF3AF@Rikers.org> you wrote:
> > As is being discussed here, C99 has some replacements to the gcc syntax
> > the kernel uses. I believe the C99 syntax will win in the near future,
> > and thus the gcc syntax will have to be removed at some point. In the
> > interim the kernel will either move towards supporting both, or a
> > quantum jump to support the new gcc3+ compiler only. I am hoping a
> > little thought can get put into this such that this change will be less
> > painful down the road.
>
> BTW: the C99 syntax for named structure initializers is supported from
> gcc 2.7.<something> on. But a policy decision has been take to use
> gcc synta in kernel.

Just so everyone knows what we're talking about, some examples from C99:

33 EXAMPLE 9 Arrays can be initialized to correspond to the elements of an  
enumeration by using designators:

enum { member_one, member_two };
const char *nm[] = {
        [member_two] = "member two",
        [member_one] = "member one",
};

34 EXAMPLE 10 Structure members can be initialized to nonzero values  
without depending on their order:

div_t answer = {
        .quot = 2,
        .rem = -1
};

35 EXAMPLE 11 Designators can be used to provide explicit initialization  
when unadorned initializer lists might be misunderstood:

struct { int a[3], b; }
w[] = {
        [0].a = {1},
        [1].a[0] = 2
};


MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Kai Henningsen]

Tim@Rikers.org (Tim Riker)  wrote on 02.11.00 in <3A01B8BB.A17FE178@Rikers.org>:

> 1. C++ style comments
>
> Occurs in over 4000 lines of source and header files. :-( Should be
> converted to ansi c comments? We will probably want to just skirt this
> issue for now as the next rev of ANSI C is likely to include ANSI C++
> style comments.

I don't know about the *next* ANSI C, but the *current* ANSI C is ISO C 99  
(ISO/IEC 9899:1999 (E)) and *does* have C++ style comments.

ANSI at least will happily sell you a PDF.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Aaron Sethman]

On Thu, 2 Nov 2000, Andi Kleen wrote:

> On Thu, Nov 02, 2000 at 07:07:12PM +0000, Alan Cox wrote:
> > > 1. There are architectures where some other compiler may do better
> > > optimizations than gcc. I will cite some examples here, no need to argue
> > 
> > I think we only care about this when they become free software.
> 
> SGI's pro64 is free software and AFAIK is able to compile a kernel on IA64.
> It is also not clear if gcc will ever produce good code on IA64.

Well if its compiling the kernel just fine without alterations to the
code, then fine. If not, if the SGI compiler is GPL'd pillage its sources
and get that code working in gcc. Otherwise, trying to get linux to work
with other C compilers doesn't seem worth the effort. 

Aaron

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Martin Dalecki]

Tim Riker wrote:
> 
> ok, a very valid point. The "C++ kernel code" reference is very telling.
> (ouch). ;-)
> 
> Obviously the changes to support non-gcc compilers should have the goal
> of minimal impact on gcc users lives. I recognize that the mainstream
> will still use gcc.
> 
> Q: Why should we help you make it possible to use a proprietary C
> compiler?
> 
> This is right on the money. I hope to show that is is all part of "World
> Domination". ;-) I can easily see other paths to get there though, so
> why this one?
> 
> As is being discussed here, C99 has some replacements to the gcc syntax
> the kernel uses. I believe the C99 syntax will win in the near future,
> and thus the gcc syntax will have to be removed at some point. In the
> interim the kernel will either move towards supporting both, or a
> quantum jump to support the new gcc3+ compiler only. I am hoping a

No I think that there will be just a switch for gcc along the lines of
gcc --forget-our-extensions-use-c99-for-this-file. Gnu code is common
enough to
justify this. And nothing will change in old code ;-).
It's only recently that the G++ people got around to throw away some
extensions (on the C++ part).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Thomas Pornin]

In article <3A01B8BB.A17FE178@Rikers.org> you write:
> There are two immediate reasons I can come up with for this:

I do not quite follow you on these two reasons. I daily work on an
Alpha machine, which runs under Linux, and I use the Compaq C compiler
since it gives better code on the applications I am developping (I am
a student in cryptography; I gain 30% speed on MD5 code, for instance,
compared to any version of gcc/egcs).

I think that some small parts of the kernel might take advantage of
the better code (/dev/urandom for instance) but, overall, this is not
critical.

However, using two different compilers is a great way to exhibit bugs.
I was told that some of the code in the kernel makes assumptions about
how gcc optimizes code, which on time to time leads to some problems
when a new version of gcc implements a different strategy. I am not
(yet) an optimizer god, therefore I will not comment any further on this
issue; but I think that it is sane practice, if one wants to remain on
the light side of the code (the one that is specified and does not rely
on not-very-well-documented features), to stress-test portability with
different sets of tools.


Anyway, among the points you talked about:

> 1. C++ style comments

Those ones are in C99. All modern compilers know them, or are doomed to
know them in near future since they are a requirement of the standard.

> 7. Macros with variable numbers of arguments

C99 knows them, with the following syntax: the macro is defined with an
ellipsis (...) as last argument, that represents all extra arguments
(possibly none). The arguments are accessed through the identifier
__VA_ARGS__, which contains all of them (with separating commas).

At least gcc-2.95.2 knows this syntax.



If one wants to build a Linux kernel with another compiler, I would
say that the more critical points are:

** inline assembly (must be almost completely rewritten for each new
compiler -- yuck)

** generalized lvalues (the result of a comma operator being a lvalue
if its last operand is a lvalue)

** compound statements (statement blocks inside expressions)


Other features are likely to be implemented in modern compilers, maybe
with a slightly different syntax, that could be adressed through macros,
or an enhanced preprocessing (put some perl script or smart C parser
between cpp and the compiler itself).



All this is only my opinion. But if I were to design a new OS kernel
right now, I would take special care to isolate and document extensions
as much as possible, so that I could ease portability and find bugs more
easily.


	--Thomas Pornin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Tim Riker]

Ted

Agreed. C99 does not replace all the needed gcc features. We should
start using the ones that make sense, and push for
standardization/documentation on the rest.

I'm perfectly happy with this as a long term goal. I'll put what effort
I can into moving that direction without breaking the existing world as
we know it.

Tim

"Theodore Y. Ts'o" wrote:
> 
>    Date: Thu, 02 Nov 2000 13:53:55 -0700
>    From: Tim Riker <Tim@Rikers.org>
> 
>    As is being discussed here, C99 has some replacements to the gcc syntax
>    the kernel uses. I believe the C99 syntax will win in the near future,
>    and thus the gcc syntax will have to be removed at some point. In the
>    interim the kernel will either move towards supporting both, or a
>    quantum jump to support the new gcc3+ compiler only. I am hoping a
>    little thought can get put into this such that this change will be less
>    painful down the road.
> 
> That's reasonable as a long-term goal.  Keep in mind that though there
> have been questions in the past about code correctness assumptions of
> kernel versus specific GCC versions.  This has been one place where GCC
> has tended to blame the kernel developers, and kernel developers have
> pointed out (rightly, in my opinion) that the GCC documentation of some
> of these features has been less than stellar --- in fact, some would say
> non-existent.  If it's not documented, then you don't have much moral
> ground to stand upon when people complain that the changes you made
> breaks things.
> 
> So moving to a C99 syntax is useful simply from the point of view that
> it's well documented (unlike the register constraints for inline
> functions, which still give me a headache whenever I try to look at the
> GCC "documentation").  The problem here is that C99 doesn't (as far as I
> know) give us everything we need, so simply moving to C99 syntax won't
> be sufficient to support propietary C compilers.
> 
> There will also be work needed to make sure that a kernel compiled with
> gcc 3.x (whenever it's ready) will actually omit code which was intended
> by the kernel developers.  So we're definitely looking at a 2.5+

omit? did you mean emit?

> project, and one which may actually be fairly high risk; it's certainly
> not a trivial task.
> 
>                                                 - Ted

-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Theodore Y. Ts'o]

   Date: Thu, 02 Nov 2000 13:53:55 -0700
   From: Tim Riker <Tim@Rikers.org>

   As is being discussed here, C99 has some replacements to the gcc syntax
   the kernel uses. I believe the C99 syntax will win in the near future,
   and thus the gcc syntax will have to be removed at some point. In the
   interim the kernel will either move towards supporting both, or a
   quantum jump to support the new gcc3+ compiler only. I am hoping a
   little thought can get put into this such that this change will be less
   painful down the road.

That's reasonable as a long-term goal.  Keep in mind that though there
have been questions in the past about code correctness assumptions of
kernel versus specific GCC versions.  This has been one place where GCC
has tended to blame the kernel developers, and kernel developers have
pointed out (rightly, in my opinion) that the GCC documentation of some
of these features has been less than stellar --- in fact, some would say
non-existent.  If it's not documented, then you don't have much moral
ground to stand upon when people complain that the changes you made
breaks things.

So moving to a C99 syntax is useful simply from the point of view that
it's well documented (unlike the register constraints for inline
functions, which still give me a headache whenever I try to look at the
GCC "documentation").  The problem here is that C99 doesn't (as far as I
know) give us everything we need, so simply moving to C99 syntax won't
be sufficient to support propietary C compilers.

There will also be work needed to make sure that a kernel compiled with
gcc 3.x (whenever it's ready) will actually omit code which was intended
by the kernel developers.  So we're definitely looking at a 2.5+
project, and one which may actually be fairly high risk; it's certainly
not a trivial task.

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Andi Kleen]

On Thu, Nov 02, 2000 at 09:17:44PM +0000, Alan Cox wrote:
> > How can I insure that the largest possible amount of my efforts benefit
> > the community at large? Hopefully this will make it easier to move to
> > C99 or any other future compiler porting project.
> 
> The asm I dont know - its a hard problem. Things like C99 initializers for 2.5
> seem quite a reasonable change. There are also things like partial structure
> packing with __attribute((packed)) that can be hard to port

All non toy compilers[1] I've seen so far had some equivalent of __attribute__((packed)).
It just always has a different syntax, usually even non macro friendly (#pragma) 

-Andi

[1] ok and the TenDRA one
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Alan Cox]

> How can I insure that the largest possible amount of my efforts benefit
> the community at large? Hopefully this will make it easier to move to
> C99 or any other future compiler porting project.

The asm I dont know - its a hard problem. Things like C99 initializers for 2.5
seem quite a reasonable change. There are also things like partial structure
packing with __attribute((packed)) that can be hard to port

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Christoph Hellwig]

In article <3A01D463.9ADEF3AF@Rikers.org> you wrote:
> As is being discussed here, C99 has some replacements to the gcc syntax
> the kernel uses. I believe the C99 syntax will win in the near future,
> and thus the gcc syntax will have to be removed at some point. In the
> interim the kernel will either move towards supporting both, or a
> quantum jump to support the new gcc3+ compiler only. I am hoping a
> little thought can get put into this such that this change will be less
> painful down the road.

BTW: the C99 syntax for named structure initializers is supported from
gcc 2.7.<something> on. But a policy decision has been take to use
gcc synta in kernel.

	Christoph


-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Tim Riker]

Alan,

Alan Cox wrote:
> 
> > > That need to run Linux - name one ? Why try to solve a problem when it hasn't
> > > happened yet. Let whoever needs to solve it do it.
> >
> > We have proposals here all under NDA. So I won't mention one of them.
> > Perhaps there are some of these folk on the list that would like to
> > comment?
> 
> Then I think it will be up to you to achieve the non gcc build or to teach
> your compiler gcc extensions (which may or may not be easier). The kernel also
> tends to know a few things about how gcc optimises code which shouldn't matter
> if your compiler is good enough to optimise nicely anyway.

This is completely reasonable. I guess what I'm asking is:

How can I insure that the largest possible amount of my efforts benefit
the community at large? Hopefully this will make it easier to move to
C99 or any other future compiler porting project.

> 
> AFAIK the only non gcc port of Linux isnt exactly a port but was ELKS done using
> bcc86 (Bruce Evans compiler)

I have not looked at this project. Thank you for the pointer. I hope to
learn form their experiences.

> 
> Alan

PS, while I'm writing to you. I reread my earlier reply to you and Ben
was right about chewing me out for it. My bad.
-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Tim Riker]

ok, a very valid point. The "C++ kernel code" reference is very telling.
(ouch). ;-)

Obviously the changes to support non-gcc compilers should have the goal
of minimal impact on gcc users lives. I recognize that the mainstream
will still use gcc.

Q: Why should we help you make it possible to use a proprietary C
compiler?

This is right on the money. I hope to show that is is all part of "World
Domination". ;-) I can easily see other paths to get there though, so
why this one?

As is being discussed here, C99 has some replacements to the gcc syntax
the kernel uses. I believe the C99 syntax will win in the near future,
and thus the gcc syntax will have to be removed at some point. In the
interim the kernel will either move towards supporting both, or a
quantum jump to support the new gcc3+ compiler only. I am hoping a
little thought can get put into this such that this change will be less
painful down the road.

I hope that I can lend some time to this project and save the rest of
the community time in the long run. Benefit our projects in the short
term. And impact the rest of the linux-kernel community as little as
possible in the short term.

How does that sound for a way forward?

"Theodore Y. Ts'o" wrote:
> 
>    Date:        Thu, 02 Nov 2000 12:31:51 -0700
>    From: Tim Riker <Tim@Rikers.org>
> 
>    Me or Alan? I did not mean this as a dig. I feel strongly that one
>    should have the choice here. I do not choose to enforce my beliefs on
>    anyone else. I am suggesting only that others should provide the same
>    courtesy. I truly meant "Thank you for you opinion". I feel the
>    community benefits from the differing opinions contained within it.
> 
> Yes, but that argument doesn't hold once you start asking the everyone
> to work on making that choice available.  The question that some part of
> the community may ask is --- why should we help you make it possible to
> use a propietary C compiler?
> 
> Choice also implies a choice not to work on things which help some
> particular person's pet cause, whether that is C++ kernel code, or
> propietary C compilers.  If it makes the code harder to maintain or more
> complex, it impacts everyone, and it's fair to ask the question whether
> or not the feeling "one should have the choice here" is worth the cost
> which you're asking everyone to bear.
> 
>                                         - Ted

-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Alan Cox]

> > That need to run Linux - name one ? Why try to solve a problem when it hasn't
> > happened yet. Let whoever needs to solve it do it.
> 
> We have proposals here all under NDA. So I won't mention one of them.
> Perhaps there are some of these folk on the list that would like to
> comment?

Then I think it will be up to you to achieve the non gcc build or to teach
your compiler gcc extensions (which may or may not be easier). The kernel also
tends to know a few things about how gcc optimises code which shouldn't matter
if your compiler is good enough to optimise nicely anyway.

AFAIK the only non gcc port of Linux isnt exactly a port but was ELKS done using
bcc86 (Bruce Evans compiler)

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Theodore Y. Ts'o]

   Date: 	Thu, 02 Nov 2000 12:31:51 -0700
   From: Tim Riker <Tim@Rikers.org>

   Me or Alan? I did not mean this as a dig. I feel strongly that one
   should have the choice here. I do not choose to enforce my beliefs on
   anyone else. I am suggesting only that others should provide the same
   courtesy. I truly meant "Thank you for you opinion". I feel the
   community benefits from the differing opinions contained within it.

Yes, but that argument doesn't hold once you start asking the everyone
to work on making that choice available.  The question that some part of
the community may ask is --- why should we help you make it possible to
use a propietary C compiler?  

Choice also implies a choice not to work on things which help some
particular person's pet cause, whether that is C++ kernel code, or
propietary C compilers.  If it makes the code harder to maintain or more
complex, it impacts everyone, and it's fair to ask the question whether
or not the feeling "one should have the choice here" is worth the cost
which you're asking everyone to bear.

					- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Christoph Hellwig]

In article <20001102212124.A15054@gruyere.muc.suse.de> you wrote:
> You also forgot named structure initializers, but C99 supports them 
> again with a different syntax than gcc [I guess it would have been too easy
> to just use the gcc syntax]

The named initializers syntax in C99 is from plan9, besides beeing probably
older, it is from the C creators and more logic ;)

I think that are enough reasons for the ANSI people to not choose the GCC
syntax.

	Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Andi Kleen]

On Thu, Nov 02, 2000 at 11:55:55AM -0700, Tim Riker wrote:
> 1. C++ style comments
> 
> Occurs in over 4000 lines of source and header files. :-( Should be
> converted to ansi c comments? We will probably want to just skirt this
> issue for now as the next rev of ANSI C is likely to include ANSI C++
> style comments.

First C99 includes C++ comments and it is more or less the "ANSI-C" now.

I also have my doubts that it is a real portability problem in practice,
it is such a common extension that most compilers I know have some switch
to enable it and even if they didn't it would be trivial to write a small
wrapper to remove them.

> 
> 2. Inline assembly statements
> 
> mostly in arch/ tree. Frequently used in macros as well. Much of this
> will incur performance penalties if moved to external assembly files.
> Some would require moving supported C code over as well. Hence many of
> these will probably translate into conditional compilation based on the
> compiler to avoid and performance hit for the mainstream case.

That will not work out.  Linux without some form of inline assembly
sounds very unlikely. In theory you could maybe write wrappers for some
common inline assembly idioms, but in the end you'll likely need to duplicate
some files in asm/ and arch/

> 7. Macros with variable numbers of arguments
> 
> no recommendation yet.

ISO C99 has a replacement, unfortunately not gcc compatible. gcc3+ supports
it, but you would drop compatibility to older gcc releases [which would
not make you very popular..]

You also forgot named structure initializers, but C99 supports them 
again with a different syntax than gcc [I guess it would have been too easy
to just use the gcc syntax]


-Andi (who would much like to use C99 mixed statements/declarations in the kernel,
but not even gcc3 supports it yet)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Tim Riker]

Ben Ford wrote:
> 
> Tim Riker wrote:
> 
> > Alan Cox wrote:
> > >
> > > > 1. There are architectures where some other compiler may do better
> > > > optimizations than gcc. I will cite some examples here, no need to argue
> > >
> > > I think we only care about this when they become free software.
> >
> > This may be your belief, but I would not choose to enforce it on
> > everyone. Thank you for you opinion.
> 
> No need to be so flip about it.  I believe that most of us feel that way.

Me or Alan? I did not mean this as a dig. I feel strongly that one
should have the choice here. I do not choose to enforce my beliefs on
anyone else. I am suggesting only that others should provide the same
courtesy. I truly meant "Thank you for you opinion". I feel the
community benefits from the differing opinions contained within it.

> 
> -b
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/

-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Ben Ford]

Tim Riker wrote:

> Alan Cox wrote:
> >
> > > 1. There are architectures where some other compiler may do better
> > > optimizations than gcc. I will cite some examples here, no need to argue
> >
> > I think we only care about this when they become free software.
>
> This may be your belief, but I would not choose to enforce it on
> everyone. Thank you for you opinion.

No need to be so flip about it.  I believe that most of us feel that way.


-b


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Andi Kleen]

On Thu, Nov 02, 2000 at 07:07:12PM +0000, Alan Cox wrote:
> > 1. There are architectures where some other compiler may do better
> > optimizations than gcc. I will cite some examples here, no need to argue
> 
> I think we only care about this when they become free software.

SGI's pro64 is free software and AFAIK is able to compile a kernel on IA64.
It is also not clear if gcc will ever produce good code on IA64.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Tim Riker]

Alan Cox wrote:
> 
> > 1. There are architectures where some other compiler may do better
> > optimizations than gcc. I will cite some examples here, no need to argue
> 
> I think we only care about this when they become free software.

This may be your belief, but I would not choose to enforce it on
everyone. Thank you for you opinion.

> > 2. There are architectures where gcc is not yet available, but vendor C
> > compilers are.
> 
> That need to run Linux - name one ? Why try to solve a problem when it hasn't
> happened yet. Let whoever needs to solve it do it.

We have proposals here all under NDA. So I won't mention one of them.
Perhaps there are some of these folk on the list that would like to
comment?

> 
> Alan

-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Alan Cox]

> 1. There are architectures where some other compiler may do better
> optimizations than gcc. I will cite some examples here, no need to argue

I think we only care about this when they become free software.

> 2. There are architectures where gcc is not yet available, but vendor C
> compilers are.

That need to run Linux - name one ? Why try to solve a problem when it hasn't
happened yet. Let whoever needs to solve it do it. 

Alan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Tim Riker]

All,

Alright, I've been lurking long enough on this thread. What say we
consider the option of building the kernel with a compiler other than
gcc? This would imply a slightly different structure to the makefiles
and code.

There are two immediate reasons I can come up with for this:

1. There are architectures where some other compiler may do better
optimizations than gcc. I will cite some examples here, no need to argue
out the point unless you disagree with the POSSIBILITY that this may be
true on at least one architecture. Anyway, possibilities include
Compaq's compiler on alpha, HP's compiler on hppa, Intel's compiler (or
rather plugins to another vendors compiler) on ia64, Metrowerk's
compiler on PPC, etc.

2. There are architectures where gcc is not yet available, but vendor C
compilers are.

I suggest that we avoid gcc extensions as much as possible, barring
performance hits. When there is an ANSI way of doing things we should
choose that route. Where there is not, then isolate the gcc way such
that compiler vendors can either:

1. implement the gcc way and conditional compile that code.

2. implement some other way and easily add that conditional code.

I've been looking into this here at Lineo for some of these vendors.
Here is a brief list of things I've come across:

1. C++ style comments

Occurs in over 4000 lines of source and header files. :-( Should be
converted to ansi c comments? We will probably want to just skirt this
issue for now as the next rev of ANSI C is likely to include ANSI C++
style comments.

2. Inline assembly statements

mostly in arch/ tree. Frequently used in macros as well. Much of this
will incur performance penalties if moved to external assembly files.
Some would require moving supported C code over as well. Hence many of
these will probably translate into conditional compilation based on the
compiler to avoid and performance hit for the mainstream case.

3. Declaring attributes of functions

The __attribute__ options: noreturn, const, format, section,
constructor, destructor, unused, and  weak. weak and section are needed.
The rest can be ignored? These might want to be converted to #defines
such that alternative compilers can implement them differently.

4. Specifying attributes of variables

The __attribute__ options: aligned, packed, section and weak. As above
these will likely be #defines to handle different compiler syntax.

5. Conditionals with omitted operands

The missing operands should just be added into the mainstream source.

6. Referring to a type with typeof

no recommendation yet.

7. Macros with variable numbers of arguments

no recommendation yet.

8. Inquiring on alignment of types or variables (__alignof__)

no recommendation yet.

Well, I got a bit more long winded than I planned, but there it is.
Thoughts?

"H. Peter Anvin" wrote:
> 
> Followup to:  <200011020011.QAA20585@pizda.ninka.net>
> By author:    "David S. Miller" <davem@redhat.com>
> In newsgroup: linux.dev.kernel
> >
> > We already know we are a bunch of pinheads wrt. the userland compiler
> > issue, full stop.  It need not be restated several hundred more times.
> > Believe me, after such a large fiasco, we have listened :-)
> >
> > But, on the other hand, to say that "kgcc" comceptually is something
> > only Red Hat has ever done is a factual error, that is all I am trying
> > to state, nothing more.
> >
> 
> I think at least supporting a "kgcc" compiler makes sense,
> conceptually (although it probably should have been called "kcc", but
> it's too late now.)
> 
> The kernel uses a lot of gcc extensions, and history shows that these
> extensions aren't as stable as the compiler system as a whole.
> 
>         -hpa
-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/