Re: non-gcc linux?

Re: non-gcc linux?

[Russ Allbery]

Tim Riker <Tim@Rikers.org> writes:

> I understand "will not", but "can not"? There is nothing stopping
> anyone, let's say SGI for example, from branching a separate gcc which
> would include copyrights assigned to FSF and other parties. Let's say
> this happens and a new sgigcc source base is created. Presumably then
> any defense of gcc code could be met with the argument that the code
> used came from sgigcc. This being the case what has the FSD gained by
> the current policy?

I'm unclear on how you're defining your terms, but were someone to have
violated the GPL license on gcc, I don't understand how the existence of
sgigcc would allow them to mount a defense.  The point of the copyright
assignments is to make the copyright holder clear for legal purposes in
the event of an attempt to violate the license.  You *seem* to be saying
that somehow one could claim that gcc code wasn't actually owned by the
FSF because it might have come from sgigcc (?), but of course that
wouldn't be the case because all gcc code has copyright assignments.

> I suppose that this is even the case today as one could argue that code
> came from intel-gcc if they used the Intel patches for ia64 or any other
> non-FSF copyrighted patches including patches made by the same company
> that the FSD might be in legal action with.

> In short, I do not see any enforceable advantages to the current FSF
> policies.

I can see a whole bunch of advantages, and I'm afraid that your paragraphs
above don't make any semantic sense to me.  Could you please clarify what
you mean?

I think that the copyright assignment requirement is to some degree legal
paranoia; sure, it's not *necessary* under copyright law, and in theory
one could successfully defend the license without it.  But I can also very
readily believe the advice of lawyers on the subject, namely that
enforcement of the copyright is significantly easier in real court if one
entity owns all of the rights.

-- 
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?

[Tim Riker]

My understand of the argument for assigning all gcc copyright to the FSF
is that this make 'gcc' easier to defend. My example of an sgi-gcc shows
that sgi-gcc would have different criteria in a defense. This is solely
because both SGI and FSF would hold copyrights.

Now Marc Lehmann claims that this dual copyright code would be
"impossible" to defend. I merely pointed out that if that is truly the
case, gcc would also be indefensible because any GPL violator could
claim they took the source not from gcc, but from sgi-gcc which Marc
claims is indefensible.

I therefore assert that the fictitious sgi-gcc IS defensible and then by
conclusion that the current FSF position is not required to defend gcc
GPL. I am merely trying to assert what you stated as a given below:

> I think that the copyright assignment requirement is to some degree legal
> paranoia; sure, it's not *necessary* under copyright law, and in theory
> one could successfully defend the license without it.  But I can also very
> readily believe the advice of lawyers on the subject, namely that
> enforcement of the copyright is significantly easier in real court if one
> entity owns all of the rights.

In short the impact of adding code to gcc that is not copyright FSF is
minimal. Only the FSF copyrighted code would be defensible by the FSF.
Any other code GPL violations would be the responsibility of the
copyright owners to defend.

As before IANAL. ;-)

Russ Allbery wrote:
> 
> Tim Riker <Tim@Rikers.org> writes:
> 
> > I understand "will not", but "can not"? There is nothing stopping
> > anyone, let's say SGI for example, from branching a separate gcc which
> > would include copyrights assigned to FSF and other parties. Let's say
> > this happens and a new sgigcc source base is created. Presumably then
> > any defense of gcc code could be met with the argument that the code
> > used came from sgigcc. This being the case what has the FSD gained by
> > the current policy?
> 
> I'm unclear on how you're defining your terms, but were someone to have
> violated the GPL license on gcc, I don't understand how the existence of
> sgigcc would allow them to mount a defense.  The point of the copyright
> assignments is to make the copyright holder clear for legal purposes in
> the event of an attempt to violate the license.  You *seem* to be saying
> that somehow one could claim that gcc code wasn't actually owned by the
> FSF because it might have come from sgigcc (?), but of course that
> wouldn't be the case because all gcc code has copyright assignments.
> 
> > I suppose that this is even the case today as one could argue that code
> > came from intel-gcc if they used the Intel patches for ia64 or any other
> > non-FSF copyrighted patches including patches made by the same company
> > that the FSD might be in legal action with.
> 
> > In short, I do not see any enforceable advantages to the current FSF
> > policies.
> 
> I can see a whole bunch of advantages, and I'm afraid that your paragraphs
> above don't make any semantic sense to me.  Could you please clarify what
> you mean?
> 
> 
> --
> 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/

-- 
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?

[Adam Sampson]

On Sun, Nov 05, 2000 at 06:01:29PM -0700, Tim Riker wrote:
> In short the impact of adding code to gcc that is not copyright FSF is
> minimal. Only the FSF copyrighted code would be defensible by the FSF. Any
> other code GPL violations would be the responsibility of the copyright
> owners to defend.

Just as a minor point: pro64 _does_ use GCC code. It's effectively the GCC
frontend stuck together with the SGI backend, with a translation layer in
the middle to translate between the intermediate code formats that the two
compilers use. There are some fairly entertaining "this is a gruesome hack"
comments in the source code.

-- 

Adam Sampson
azz@gnu.org

-
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?

[Tim Riker]

This is also a nice thought, but there is an obstacle.

The Pro64 tools are Open Source and GPLed:

http://oss.sgi.com/projects/Pro64/

SGI retains the copyright to the code.

As far as I know, the FSF owns the copyright to all code in the gcc
suite. If improvements were taken from the Pro64 tools the copyright to
said code would have to remain.

>From what I understand the FSF will not allow any code to be added to
gcc that is not copyright by the FSF. Intel has offered direct patches
to gcc to support better optimizations for Itanium. Some of there
patches improve performance on other platforms. As far as I know the gcc
team has not even looked at the patches but has required that full
copyright be transferred to the FSF first.

I understand there are other hardware vendors who have written patches
only to be met by this same adamant position taken by the FSF.

Others that are commenting on the slow progress of some features in gcc
should consider for themselves whether this position benefits the Open
Source community or not.

Note: it _is_ clear that this position _could_ be of _some_ benefit to
the Free Software community as it places the FSF in a more defensible
position if there were ever a legal dispute on pirated sections of the
FSF copyrighted code.

Aaron Sethman wrote:
> 
> 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
-- 
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?

[Alan Cox]

> This is also a nice thought, but there is an obstacle.
> The Pro64 tools are Open Source and GPLed:
> 
> http://oss.sgi.com/projects/Pro64/
> 
> SGI retains the copyright to the code.
> 
> As far as I know, the FSF owns the copyright to all code in the gcc
> suite. If improvements were taken from the Pro64 tools the copyright to
> said code would have to remain.

Pro64 is free software and Pro64 understands gcc syntax. No problem at all.

-
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?

[Tim Riker]

Alan,

Perhaps I did not explain myself, or perhaps I misunderstand your
comments. I was responding to a comment that we could just copy some of
the optimizations from Pro64 over into gcc. Whether Pro64 understands
gcc syntax is immaterial to this question is it not?

Tim

Alan Cox wrote:
> 
> > This is also a nice thought, but there is an obstacle.
> > The Pro64 tools are Open Source and GPLed:
> >
> > http://oss.sgi.com/projects/Pro64/
> >
> > SGI retains the copyright to the code.
> >
> > As far as I know, the FSF owns the copyright to all code in the gcc
> > suite. If improvements were taken from the Pro64 tools the copyright to
> > said code would have to remain.
> 
> Pro64 is free software and Pro64 understands gcc syntax. No problem at all.
> 
> -
> 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?

[Jakub Jelinek]

On Sun, Nov 05, 2000 at 01:52:24PM -0700, Tim Riker wrote:
> Alan,
> 
> Perhaps I did not explain myself, or perhaps I misunderstand your
> comments. I was responding to a comment that we could just copy some of
> the optimizations from Pro64 over into gcc.

That's hard to do, because the whole gcc has copyright assigned to FSF,
which means that either gcc steering committee would have to make an
exception from this for SGI, or SGI would have to be willing to assign some
code to FSF.

	Jakub
-
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?

[Tim Riker]

yes, exactly what my comments stated.

Jakub Jelinek wrote:
> 
> On Sun, Nov 05, 2000 at 01:52:24PM -0700, Tim Riker wrote:
> > Alan,
> >
> > Perhaps I did not explain myself, or perhaps I misunderstand your
> > comments. I was responding to a comment that we could just copy some of
> > the optimizations from Pro64 over into gcc.
> 
> That's hard to do, because the whole gcc has copyright assigned to FSF,
> which means that either gcc steering committee would have to make an
> exception from this for SGI, or SGI would have to be willing to assign some
> code to FSF.
> 
>         Jakub

-- 
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?

[Marc Lehmann]

On Sun, Nov 05, 2000 at 04:06:37PM -0500, Jakub Jelinek <jakub@redhat.com> wrote:
> That's hard to do, because the whole gcc has copyright assigned to FSF,
> which means that either gcc steering committee would have to make an
> exception from this

Which can not and will not happen.

> for SGI, or SGI would have to be willing to assign some code to FSF.

Which is the standard procedure that the FSF requires for all it's
programs to be able to defend them - incorporating non-assigned code into
gcc creates some intractable problems (i.e.: make it impossible) when the
FSD ever wanted to go to court to defend the freedom of gcc.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |
-
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?

[Tim Riker]

Marc Lehmann wrote:
> 
> On Sun, Nov 05, 2000 at 04:06:37PM -0500, Jakub Jelinek <jakub@redhat.com> wrote:
> > That's hard to do, because the whole gcc has copyright assigned to FSF,
> > which means that either gcc steering committee would have to make an
> > exception from this
> 
> Which can not and will not happen.

I understand "will not", but "can not"? There is nothing stopping
anyone, let's say SGI for example, from branching a separate gcc which
would include copyrights assigned to FSF and other parties. Let's say
this happens and a new sgigcc source base is created. Presumably then
any defense of gcc code could be met with the argument that the code
used came from sgigcc. This being the case what has the FSD gained by
the current policy?

I suppose that this is even the case today as one could argue that code
came from intel-gcc if they used the Intel patches for ia64 or any other
non-FSF copyrighted patches including patches made by the same company
that the FSD might be in legal action with.

In short, I do not see any enforceable advantages to the current FSF
policies.

> > for SGI, or SGI would have to be willing to assign some code to FSF.
> 
> Which is the standard procedure that the FSF requires for all it's
> programs to be able to defend them - incorporating non-assigned code into
> gcc creates some intractable problems (i.e.: make it impossible) when the
> FSD ever wanted to go to court to defend the freedom of gcc.

Statements above are my own, and I am not a lawyer.

-- 
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?

[Marc Lehmann]

On Sun, Nov 05, 2000 at 04:05:05PM -0700, Tim Riker <Tim@Rikers.org> wrote:
> > Which can not and will not happen.
> 
> I understand "will not", but "can not"? There is nothing stopping

As I explained three lines below the mail, if you care to read.

> would include copyrights assigned to FSF and other parties. Let's say
> this happens and a new sgigcc source base is created. Presumably then

We recently saw that creating a new, probably incompatible compiler is a
very bad thing. If sgi would split the compiler that would be a problem
for the community at large.

> any defense of gcc code could be met with the argument that the code
> used came from sgigcc

YANAL and IANAL, but to defend code you must own it or have authored it.
Since the FSF would, in your example, neither own the code nor be the
author of it they couldn't defend that version of gcc.

> This being the case what has the FSD gained by

Well, simply this is _not_ the case ;)

> In short, I do not see any enforceable advantages to the current FSF

You don't. Lawyers do (certainly the FSD lawyer does), and probably the
law does, also ;)

> Statements above are my own, and I am not a lawyer.

Yepp.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |
-
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?

[Thomas Pornin]

In article <3A05E7A1.C97B85D9@Rikers.org> you write:
> In short, I do not see any enforceable advantages to the current FSF
> policies.

As a sidenote, this transfer of intellectual property of code is not
doable, according to French law (and other non-anglo-saxon countries).
In France, the author of a an "intellectual production" cannot give
away this authorship; all he can give is the ability to reproduce,
reuse and redistribute his work.

However, this intellectual property, which is eternal (it does not stop
with the death of the author, and yet may not be transfered to other
people even in such an occurence), is not bound by any scriptural glyph
such as '(c)'. I can add '(c) Free Software Fundation' in all my source
files, and they will remain mine.

So, where I live, the point is moot.


	--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?

[Ion Badulescu]

On Sun, 5 Nov 2000 23:42:25 +0100, Marc Lehmann <pcg@goof.com> wrote:
> On Sun, Nov 05, 2000 at 04:06:37PM -0500, Jakub Jelinek <jakub@redhat.com> wrote:

>> for SGI, or SGI would have to be willing to assign some code to FSF.
> 
> Which is the standard procedure that the FSF requires for all it's
> programs to be able to defend them

... or sell them under a different license. Not that they would, but they
could, if they really wanted to.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.
-
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?

[Eric W. Biederman]

Ion Badulescu <ionut@moisil.cs.columbia.edu> writes:

> On Sun, 5 Nov 2000 23:42:25 +0100, Marc Lehmann <pcg@goof.com> wrote:
> > On Sun, Nov 05, 2000 at 04:06:37PM -0500, Jakub Jelinek <jakub@redhat.com>
> wrote:
> 
> 
> >> for SGI, or SGI would have to be willing to assign some code to FSF.
> > 
> > Which is the standard procedure that the FSF requires for all it's
> > programs to be able to defend them
> 
> ... or sell them under a different license. Not that they would, but they
> could, if they really wanted to.

The wording of the standard copyright assignment to the FSF binds the
FSF so that it can only release the code under a free software
license.

Eric
-
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?

[Alan Cox]

> That's hard to do, because the whole gcc has copyright assigned to FSF,
> which means that either gcc steering committee would have to make an
> exception from this for SGI, or SGI would have to be willing to assign some
> code to FSF.

Or a third party decides its a silly situation and does it anyway
-
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?

[Alan Cox]

> Perhaps I did not explain myself, or perhaps I misunderstand your
> comments. I was responding to a comment that we could just copy some of
> the optimizations from Pro64 over into gcc. Whether Pro64 understands
> gcc syntax is immaterial to this question is it not?

If gcc is architecturally unable to do ia64 well, pro64 is free software and
both understand the same syntax Im at a bit of a loss why that is productive ?
-
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?

[Tim Riker]

Alan Cox wrote:
> 
> > Perhaps I did not explain myself, or perhaps I misunderstand your
> > comments. I was responding to a comment that we could just copy some of
> > the optimizations from Pro64 over into gcc. Whether Pro64 understands
> > gcc syntax is immaterial to this question is it not?
> 
> If gcc is architecturally unable to do ia64 well, pro64 is free software and
> both understand the same syntax Im at a bit of a loss why that is productive 

Alan Cox wrote in another message:
> Or a third party decides its a silly situation and does it anyway

A definite possibility.
-- 
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?

[Kai Henningsen]

Tim@Rikers.org (Tim Riker)  wrote on 04.11.00 in <3A03D466.738ED67@Rikers.org>:

> Others that are commenting on the slow progress of some features in gcc
> should consider for themselves whether this position benefits the Open
> Source community or not.

Slow progress in gcc?

You know, I currently have a daily CVS of gcc at work, with an automatic  
diff mailed to me, and the amount of daily changes is simply incredible.  
Practically no day passes without at least one big pach, and about half a  
dozen patches from different people at least, going into the CVS.

I don't know how much faster you can get and still hope to deliver a  
stable product at the end.

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/

non-gcc linux?

[Bryan Sparks]

Let me see if I understand you correctly. Metrowerks (Motorola) makes a 
twenty something million dollar investment in your little company, and as 
part of the agreement (not to mention Metrowerk's sole motivation) you are 
required to create a version of Linux that compiles under their ANSI c tool 
chain. Furthermore, you are attempting to lobby the community into helping 
your effort under the pretense that it is for the good of Linux? Survey 
says...bzzzsst. Wrong answer Chuck, but for your consolation prize you get 
your own non-standard, divergent Linux.

Thanks for playing!
Bryan


Tim Riker wrote:

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/

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.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?)

[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?

[Tim Riker]

Do you or anyone else on the list recall why this decision was made? Can
you recall around when it was made so I can dig out the history from the
archives?

I would be eager to convert everything over to the C99 syntax, test the
heck out of it and submit the patch. Obviously this is wasted effort if
there is a good reason to continue using the gcc syntax.

Christoph Hellwig wrote:
> 
> 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 syntax in kernel.

-- 
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]

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?)

[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?)

[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?

[Tim Riker]

#pragma is a particularly difficult problem to deal with because it is
non macro friendly. =(

Sounds like C99 initializers are a likely first target for integration.

I'll keep plugging away at other stuff here as well.

Andi Kleen wrote:
> 
> 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

-- 
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?

[Andi Kleen]

On Thu, Nov 02, 2000 at 02:27:35PM -0700, Tim Riker wrote:
> #pragma is a particularly difficult problem to deal with because it is
> non macro friendly. =(

When you assume C99 it is no problem, because C99 has _Pragma()



-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?

[Tim Riker]

Excellent. I guess I really need to get a copy of the C99 spec
and dig through it.

http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI%2FISO%2FIEC+9899%2D1999

Thanx!

GCC does have a table of what's been implemented so far:

http://www.gnu.org/software/gcc/c99status.html

Which indicates gcc all ready supports this? I have not yet dug into
which pragmas though... ;-)

Andi Kleen wrote:
> 
> On Thu, Nov 02, 2000 at 02:27:35PM -0700, Tim Riker wrote:
> > #pragma is a particularly difficult problem to deal with because it is
> > non macro friendly. =(
> 
> When you assume C99 it is no problem, because C99 has _Pragma()
> 
> -Andi

-- 
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?

[Gábor Lénárt]

On Thu, Nov 02, 2000 at 02:27:35PM -0700, Tim Riker wrote:
> #pragma is a particularly difficult problem to deal with because it is
> non macro friendly. =(
> 
> Sounds like C99 initializers are a likely first target for integration.
> 
> I'll keep plugging away at other stuff here as well.

I've been coding C for some years ... But I don't know too much these
features (even don't know about named initializers found in this list
some weeks ago, I don't know only the name of this thing ? ;-)
So where can I read about these ?

Thanx, Gabor
-
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?

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1033 bytes --]

lgb@viva.uti.hu (Gábor Lénárt)  wrote on 03.11.00 in <20001103082142.A22729@viva.uti.hu>:

> On Thu, Nov 02, 2000 at 02:27:35PM -0700, Tim Riker wrote:
> > #pragma is a particularly difficult problem to deal with because it is
> > non macro friendly. =(
> >
> > Sounds like C99 initializers are a likely first target for integration.
> >
> > I'll keep plugging away at other stuff here as well.
>
> I've been coding C for some years ... But I don't know too much these
> features (even don't know about named initializers found in this list
> some weeks ago, I don't know only the name of this thing ? ;-)
> So where can I read about these ?

In the standard, available for example from ANSI. Someone gave an URL.

Old drafts may be available on the web, but will obviously differ in some  
details (and give no indication which details that are).

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/

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/

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/

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?

[Tim Riker]

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.
> 
> -Andi

A grand example I should have included. Thanx! Last I knew the status
was that SGI had built the kernel with thier compiler, by adding gcc
syntax into it, but had not reached the point where the kernel would
run. Perhaps they have gotten past this. Since I'm no longer involved in
the Trillian (read ia64 Linux Project) mailing lists or weekly phone
calls I have been out of this loop for a month or so.
-- 
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?

[Andrea Arcangeli]

On Thu, Nov 02, 2000 at 12:17:33PM -0700, Tim Riker wrote:
> [..] by adding gcc
> syntax into it [..]

I think that's the right path. How much would be hard for you to add gcc syntax
into your compiler too instead of feeding us kernel patches? Note that it would
be a big advantage also for userspace (not only kernel uses inline asm and
other gcc extensions). And probably it would be an improvement to your
compiler too (since I don't know of other compilers that are as smart as
gcc in the inline asm syntax :).

Andrea
-
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?

[Tim Riker]

Andrea Arcangeli wrote:
> 
> On Thu, Nov 02, 2000 at 12:17:33PM -0700, Tim Riker wrote:
> > [..] by adding gcc
> > syntax into it [..]
> 
> I think that's the right path. How much would be hard for you to add gcc syntax
> into your compiler too instead of feeding us kernel patches? Note that it would
> be a big advantage also for userspace (not only kernel uses inline asm and
> other gcc extensions). And probably it would be an improvement to your
> compiler too (since I don't know of other compilers that are as smart as
> gcc in the inline asm syntax :).
> 
> Andrea

I agree there is much that can be done by taking this path. Lineo is
also pursuing this with the compiler vendors. Along the same lines, a
vendor may choose to implement a gcc front end that translates gcc
syntax. All these options have merit.

However, it makes me a bit nervous to take this route. It assumes that
the way gcc does things is the "best way". A more formal route of adding
to the ANSI C standard would involve more eyes and therefore hopefully
add to the quality of what has been done solely for gcc.

This started off with some comments from the group (hpa in particular)
that even between gcc releases, the gcc extensions have been much less
stable that the standard compiler features. The danger of implementing
gcc extensions in another compiler is that these feature are solely
under the control of the gcc team. They are to a large degree
"documented as implemented" and as such can be difficult to determine
the Right Way to implement. The Good Things that are in gcc, that we
believe are implemented the Right Way should probably be added to the
ANSI C spec. The others should be avoided, especially when there is an
existing ANSI C way to do them.
-- 
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?

[Andrea Arcangeli]

On Thu, Nov 02, 2000 at 01:00:13PM -0700, Tim Riker wrote:
> This started off with some comments from the group (hpa in particular)
> that even between gcc releases, the gcc extensions have been much less
> stable that the standard compiler features. The danger of implementing

Given how the thread started I'm uncertain if with "stable" he meant "bug-free"
or "same API". You certainly mean "same API" and I see your point, OTOH
supporting gcc extensions still looks like the best solution to me - even if we
lack the standardization - because: 1) if you try to change the kernel I think
you'll get even more mainteinance troubles :), 2) the stable kernels never get
compiled with the bleeding edge gcc, so you would have plenty of time to
catchup any potential change in the gcc extensions.

Andrea
-
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?

[D. Hugh Redelmeier]

| From: Tim Riker <Tim@Rikers.org>

| However, it makes me a bit nervous to take this route. It assumes that
| the way gcc does things is the "best way". A more formal route of adding
| to the ANSI C standard would involve more eyes and therefore hopefully
| add to the quality of what has been done solely for gcc.
| 
| This started off with some comments from the group (hpa in particular)
| that even between gcc releases, the gcc extensions have been much less
| stable that the standard compiler features. The danger of implementing
| gcc extensions in another compiler is that these feature are solely
| under the control of the gcc team. They are to a large degree
| "documented as implemented" and as such can be difficult to determine
| the Right Way to implement. The Good Things that are in gcc, that we
| believe are implemented the Right Way should probably be added to the
| ANSI C spec. The others should be avoided, especially when there is an
| existing ANSI C way to do them.

I strongly support Tim's direction here.

I've found that code improves when you port it to different compilers
(unless you are in a hurry -- then it grows warts).

Being GCC-dependent is rather parochial.  Being GCC-version-dependent
is downright embarrassing.

Summary: spurious GCC-isms are a bad thing.

Earlier, Tim gave quite a good outline of how to address GCCisms.
My summary:

- use ISO C 89 when possible (without undue pain)

- use IOS C 99 when advantageous

- use GCCisms for the remainder of appropriate things BUT embed them
  in macros defined in header so that they can be systematically
  replaced.  Using these macros probably makes the code more readable.
  Use of any GCCism should probably be justified in commentary.

This would improve the code *and* make it more portable.

The important advantages accrue to everyone, including those who never
use a different compiler.

Hugh Redelmeier
hugh@mimosa.com  voice: +1 416 482-8253

PS: I don't agree with all that ISO SC22 WG14 does, but I think that
its work is valuable.  I attended their meeting in Toronto a couple of
weeks ago.

PPS: my own C compiler is not a toy and does not implement "packed".
I've not even thought of trying it on the linux kernel, but experience
shows that putting a program through my compiler does point to places
to improve the code.  Ask Miguel de Icaza, for example.

-
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?

[Jeff Garzik]

"D. Hugh Redelmeier" wrote:
> Being GCC-dependent is rather parochial.  Being GCC-version-dependent
> is downright embarrassing.
> 
> Summary: spurious GCC-isms are a bad thing.

Summary:  You have no clue about kernel<->gcc interdependencies and
issues.


> - use ISO C 89 when possible (without undue pain)
> 
> - use IOS C 99 when advantageous
> 
> - use GCCisms for the remainder of appropriate things BUT embed them
>   in macros defined in header so that they can be systematically
>   replaced.  Using these macros probably makes the code more readable.
>   Use of any GCCism should probably be justified in commentary.
> 
> This would improve the code *and* make it more portable.

Why does this improve the code?  It gets slower and uglier and more
difficult to maintain.

Why does this make the code more portable?  gcc is already highly
portable, and so it the kernel.  This too gains us nothing.

Removing gcc-isms without a pragmatic reason -- and no, ISO C compliancy
is not a pragmatic reason -- is silly, extra work for little or no
value.

	Jeff


-- 
Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
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?

[D. Hugh Redelmeier]

| From: Jeff Garzik <jgarzik@mandrakesoft.com>
| Subject: Re: non-gcc linux?
| 
| "D. Hugh Redelmeier" wrote:
| > Being GCC-dependent is rather parochial.  Being GCC-version-dependent
| > is downright embarrassing.
| > 
| > Summary: spurious GCC-isms are a bad thing.
| 
| Summary:  You have no clue about kernel<->gcc interdependencies and
| issues.

Not a very informative summary.  It may be true, but you ought to
help the reader learn.  A pointer is welcome.

| > - use ISO C 89 when possible (without undue pain)
| > 
| > - use IOS C 99 when advantageous
| > 
| > - use GCCisms for the remainder of appropriate things BUT embed them
| >   in macros defined in header so that they can be systematically
| >   replaced.  Using these macros probably makes the code more readable.
| >   Use of any GCCism should probably be justified in commentary.
| > 
| > This would improve the code *and* make it more portable.
| 
| Why does this improve the code?

In any environment, there are things that accidentally work.  Porting
the code finds those accidents and forces you to make them
intentionally work.

For example, my compiler is intended to find questionable code.  It
finds lots of things that GCC doesn't (or didn't use to -- I haven't
checked recently).  A few years ago, I pushed Midnight Commander
through my compiler and fed a number of suggestions back to Miguel.

|  It gets slower and uglier and more
| difficult to maintain.

I never asked for slower.  If a GCCism is faster, in a way that
matters (and lots of manual optimizations are not worthwhile), then
that is a justification.  So my suggestion allows it.

Well-designed macros improve maintainability.  They make the code more
readable.  And macro expansion happens at compile time, not run time.

| Why does this make the code more portable?  gcc is already highly
| portable, and so it the kernel.  This too gains us nothing.

The word "portable" has several meanings.  Tim clearly would not be
doing this if Lineo didn't think that it would get the kernel
somewhere that GCC didn't go, or at least didn't go as well as some
other compiler.

In the C standard, "maximally portable" is a higher level of language
conformance.

When I use portable, I also mean "avoiding exploitation of arbitrary
characteristics of the particular environment".  This kind of
portability increases robustness in the face of change.
w
Even though the vast majority of LINUX systems run on the x86
architecture, don't you think that we've all been enriched by what has
been learned porting to SPARC, Power PC, 68k, Alpha, HPPA, 390, ARM,
etc.?

Similarly, we'd all benefit by the changes suggested by the experience
of porting the kernel to another compiler.

If you think that the kernel is welded to GCC, it really ought to be
called the GNU/LINUX kernel-and-C-compiler :-)

| Removing gcc-isms without a pragmatic reason -- and no, ISO C compliancy
| is not a pragmatic reason -- is silly, extra work for little or no
| value.

Why?  Conforming to a standard is a Good Thing.  The ISO process of
making a standard is normally more careful, far sighted, and inclusive
than the extensions a particular implementor puts in their compiler.
A standard is a contract between language implementors and users.  We
don't have such a contract with GCC.

There are many resources for C programmers that don't cover GCC
extensions.  For example, course, books, and the ISO Standard itself.
Oh, and other compilers.

As HPA alluded to, the GCC extensions are not the most exercised parts
of the compiler.  They are thus more likely to contain bugs.

Hugh Redelmeier
hugh@mimosa.com  voice: +1 416 482-8253


-
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/