Re: inline asm string/line break rules change

Re: inline asm string/line break rules change

[Andi Kleen]

Joel Sherrill <joel@OARcorp.com> writes:
> 
> If there was a discussion on this, I must not have missed
> it or not realized the potential impact.  I sure don't want 
> to begin to modify other code bases until I know the intention.

It's also a big problem for the linux kernel and for various other packages.

 Even if there should be good reasons to discourage multi line string
I think it shouldn't be warned until an alternative inline assembly
syntax that doesn't rely on strings exists. Currently it is discouraging
one practice with no good replacement. 

-Andi

Re: inline asm string/line break rules change

[Franz Sirl]

On Saturday 13 April 2002 21:31, Andi Kleen wrote:
> Joel Sherrill <joel@OARcorp.com> writes:
> > If there was a discussion on this, I must not have missed
> > it or not realized the potential impact.  I sure don't want
> > to begin to modify other code bases until I know the intention.
>
> It's also a big problem for the linux kernel and for various other
> packages.

kernel is fixed for a long time and there are only a few packages out there 
using inline assembly heavily.

>  Even if there should be good reasons to discourage multi line string
> I think it shouldn't be warned until an alternative inline assembly
> syntax that doesn't rely on strings exists. Currently it is discouraging
> one practice with no good replacement.

Please? A warning is there since gcc-3.0! And adding the 3 chars \n\ to each 
multiline isn't that hard, with Joel's example:

 asm volatile(" movw %%ds,%0  
                movw %, %%es" 
               : "=r" (tmp_segment) :
               : "0" (tmp_segment) );


would turn into

 asm volatile(" movw %%ds,%0  \n\
                movw %, %%es" 
               : "=r" (tmp_segment) :
               : "0" (tmp_segment) );

Seems easy enough to me (did it to the ppc assmbly in glibc for example).

Franz.

Re: inline asm string/line break rules change

[Andi Kleen]

On Sat, Apr 13, 2002 at 11:03:04PM +0200, Franz Sirl wrote:
> On Saturday 13 April 2002 21:31, Andi Kleen wrote:
> > Joel Sherrill <joel@OARcorp.com> writes:
> > > If there was a discussion on this, I must not have missed
> > > it or not realized the potential impact.  I sure don't want
> > > to begin to modify other code bases until I know the intention.
> >
> > It's also a big problem for the linux kernel and for various other
> > packages.
> 
> kernel is fixed for a long time and there are only a few packages out there 
> using inline assembly heavily.

It is still a big issue when older kernels are compiled for example.

Same when the other packages are compiled.

> 
> >  Even if there should be good reasons to discourage multi line string
> > I think it shouldn't be warned until an alternative inline assembly
> > syntax that doesn't rely on strings exists. Currently it is discouraging
> > one practice with no good replacement.
> 
> Please? A warning is there since gcc-3.0! And adding the 3 chars \n\ to each 
> multiline isn't that hard, with Joel's example:

It isn't hard, but it makes the assembly completely unreadable and worse
it is an endless source of editing errors (it is very error prone and with
longer assembly statements usually needs another edit-fix cycle to get it right)

I would call it syntatic vinegar. 

> Seems easy enough to me (did it to the ppc assmbly in glibc for example).

I guess you didn't do actual development on the assembly though 
(= frequent changes).

-Andi

Re: inline asm string/line break rules change

[David S. Miller]

   From: Andi Kleen <ak@suse.de>
   Date: Sat, 13 Apr 2002 23:56:42 +0200

   On Sat, Apr 13, 2002 at 11:03:04PM +0200, Franz Sirl wrote:
   > kernel is fixed for a long time and there are only a few packages out there 
   > using inline assembly heavily.
   
   It is still a big issue when older kernels are compiled for example.
   
   Same when the other packages are compiled.
   
Andi, don't use modern compilers with old broken source bases.
I think you're being HIGHLY unreasonable about this.

   > Seems easy enough to me (did it to the ppc assmbly in glibc for example).
   
   I guess you didn't do actual development on the assembly though 
   (= frequent changes).
   
Andi, now that's just plain rude.

It's easy enough to me to fix this kind of stuff up, maybe you'll
accuse me of not doing actual development on the assembly too, huh?

Re: inline asm string/line break rules change

[Tim Hollebeek]

> Andi, don't use modern compilers with old broken source bases.

Or: if you do, ignore any warnings you get.

-Tim

Re: inline asm string/line break rules change

[Andi Kleen]

On Sun, Apr 14, 2002 at 01:28:43AM -0400, Tim Hollebeek wrote:
> 
> > Andi, don't use modern compilers with old broken source bases.
> 
> Or: if you do, ignore any warnings you get.

That's not an option if you need the other warnings. 
And unfortunately this warning cannot be turned off.

-Andi

Re: inline asm string/line break rules change

[David S. Miller]

   From: Andi Kleen <ak@suse.de>
   Date: Sun, 14 Apr 2002 10:46:29 +0200

   On Sun, Apr 14, 2002 at 01:28:43AM -0400, Tim Hollebeek wrote:
   > 
   > > Andi, don't use modern compilers with old broken source bases.
   > 
   > Or: if you do, ignore any warnings you get.
   
   That's not an option if you need the other warnings. 
   And unfortunately this warning cannot be turned off.
   
Here is the real interesting part, the fact that it would take you but
5 or 10 minutes to write a script in sed/awk/perl/whatever to fix up
the multiline string literals.

You have undoubtedly wasted in excess of that amount of time
typing in emails complaining about the warnings.

Re: inline asm string/line break rules change

[Tim Hollebeek]

On Sun, Apr 14, 2002 at 10:46:29AM +0200, Andi Kleen wrote:
> On Sun, Apr 14, 2002 at 01:28:43AM -0400, Tim Hollebeek wrote:
> > 
> > > Andi, don't use modern compilers with old broken source bases.
> > 
> > Or: if you do, ignore any warnings you get.
> 
> That's not an option if you need the other warnings. 
> And unfortunately this warning cannot be turned off.

grep is your friend.

Re: inline asm string/line break rules change

[Andi Kleen]

On Sun, Apr 14, 2002 at 05:08:35AM -0400, Tim Hollebeek wrote:
> On Sun, Apr 14, 2002 at 10:46:29AM +0200, Andi Kleen wrote:
> > On Sun, Apr 14, 2002 at 01:28:43AM -0400, Tim Hollebeek wrote:
> > > 
> > > > Andi, don't use modern compilers with old broken source bases.
> > > 
> > > Or: if you do, ignore any warnings you get.
> > 
> > That's not an option if you need the other warnings. 
> > And unfortunately this warning cannot be turned off.
> 
> grep is your friend.

Well, assuming this functionality is really removed as the warning 
threatens to do then this won't help in gcc 3.2, no ?  If it is not 
removed then the warning is completely pointless.

-Andi

Re: inline asm string/line break rules change

[Joel Sherrill]

Andi Kleen wrote:
> 
> On Sun, Apr 14, 2002 at 05:08:35AM -0400, Tim Hollebeek wrote:
> > On Sun, Apr 14, 2002 at 10:46:29AM +0200, Andi Kleen wrote:
> > > On Sun, Apr 14, 2002 at 01:28:43AM -0400, Tim Hollebeek wrote:
> > > >
> > > > > Andi, don't use modern compilers with old broken source bases.
> > > >
> > > > Or: if you do, ignore any warnings you get.
> > >
> > > That's not an option if you need the other warnings.
> > > And unfortunately this warning cannot be turned off.
> >
> > grep is your friend.
> 
> Well, assuming this functionality is really removed as the warning
> threatens to do then this won't help in gcc 3.2, no ?  If it is not
> removed then the warning is completely pointless.

The funtionality is really removed.  And gcc 3.0 did not work well
enough to get extensive use in the RTEMS community, so the warnings
were ignored.  We were more worried about getting all the target
CPUs we cared about working again.

Sounds like the bottom line is that newlib and RTEMS need to change
their
source.

If a script to fix this is so trivial, does someone already have one. :)

> -Andi

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: inline asm string/line break rules change

[Andi Kleen]

On Sat, Apr 13, 2002 at 08:13:18PM -0700, David S. Miller wrote:
>    I guess you didn't do actual development on the assembly though 
>    (= frequent changes).
>    
> Andi, now that's just plain rude.

I'm sorry, but this stuff really annoyed me while writing the x86-64
assembly functions.

It is clearly a step backwards for gcc I think. In C the macros with
line continuation are worse enough (but at least emacs has some 
convenient functions to not make it as painful), but maintaining
\n\t" and " or \n\  at each line ending is much worse and somewhat
of a shame for something not designed in the 60ies.

I'll shut up on this issue now and perhaps think about a better
gcc assembly syntax. gcc inline assembly is far too much of a black art
currently and I think this doesn't really need to be the case.

-Andi

Re: inline asm string/line break rules change

[Jamie Lokier]

Andi Kleen wrote:
> I'll shut up on this issue now and perhaps think about a better
> gcc assembly syntax. gcc inline assembly is far too much of a black art
> currently and I think this doesn't really need to be the case.

I think a better syntax would remove the need to provide asm delimiters
(i.e. newlines or ";") altogether.

How about this syntax, which is very C-like, backward compatible and
also friendly for asm programmers:

	__asm__ ("movw %%ds,%0",
		 "movw %0,%%es"
		 : "=r" (tmp_segment));

Note the comma separation between instructions.

cheers,
-- Jamie

Re: inline asm string/line break rules change

[Joel Sherrill]

Jamie Lokier wrote:
> 
> Andi Kleen wrote:
> > I'll shut up on this issue now and perhaps think about a better
> > gcc assembly syntax. gcc inline assembly is far too much of a black art
> > currently and I think this doesn't really need to be the case.
> 
> I think a better syntax would remove the need to provide asm delimiters
> (i.e. newlines or ";") altogether.
> 
> How about this syntax, which is very C-like, backward compatible and
> also friendly for asm programmers:
> 
>         __asm__ ("movw %%ds,%0",
>                  "movw %0,%%es"
>                  : "=r" (tmp_segment));
> 
> Note the comma separation between instructions.

It doesn't matter what it changes to, the problem is that it changed at 
all.  gcc 3.0.x was really not stable enough for most embedded
development.
Consequently, not many people saw the warning.  It isn't in mainstream
UNIX based code one finds the bulk of inline assembly -- it is in
embedded
programs, device drivers, and operating systems.

> cheers,
> -- Jamie

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: inline asm string/line break rules change

[Zack Weinberg]

On Sun, Apr 14, 2002 at 08:16:47PM -0500, Joel Sherrill wrote:
> 
> It doesn't matter what it changes to, the problem is that it changed
> at all.  gcc 3.0.x was really not stable enough for most embedded
> development.  Consequently, not many people saw the warning.  It
> isn't in mainstream UNIX based code one finds the bulk of inline
> assembly -- it is in embedded programs, device drivers, and
> operating systems.

Multiline strings are still present (with the warning) in 3.1; they
were only removed in 3.2.

zw

Re: inline asm string/line break rules change

[Joel Sherrill]

Zack Weinberg wrote:
> 
> On Sun, Apr 14, 2002 at 08:16:47PM -0500, Joel Sherrill wrote:
> >
> > It doesn't matter what it changes to, the problem is that it changed
> > at all.  gcc 3.0.x was really not stable enough for most embedded
> > development.  Consequently, not many people saw the warning.  It
> > isn't in mainstream UNIX based code one finds the bulk of inline
> > assembly -- it is in embedded programs, device drivers, and
> > operating systems.
> 
> Multiline strings are still present (with the warning) in 3.1; they
> were only removed in 3.2.

I understand that.  So far, no one has presented a solid technical
argument for their removal but only stated the fact that support will
be removed.  What is the rationale for their removal?  

What really bothers me is that this breaks assembly code which by its
very nature is something you don't want to touch.

I am protesting their removal.

> zw

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: inline asm string/line break rules change

[Joel Sherrill]

Franz Sirl wrote:
> 
> On Saturday 13 April 2002 21:31, Andi Kleen wrote:
> > Joel Sherrill <joel@OARcorp.com> writes:
> > > If there was a discussion on this, I must not have missed
> > > it or not realized the potential impact.  I sure don't want
> > > to begin to modify other code bases until I know the intention.
> >
> > It's also a big problem for the linux kernel and for various other
> > packages.
> 
> kernel is fixed for a long time and there are only a few packages out there
> using inline assembly heavily.
> 
> >  Even if there should be good reasons to discourage multi line string
> > I think it shouldn't be warned until an alternative inline assembly
> > syntax that doesn't rely on strings exists. Currently it is discouraging
> > one practice with no good replacement.
> 
> Please? A warning is there since gcc-3.0! 

But for all practical purposes, gcc 3.0.x was unuseable for embedded
targets.
Many of the targets that worked with 2.95.x were broken in the 3.0
transition
so the embedded community tended to ignore 3.0.x.  My efforts have been
focused
on getting problems reported so they can be fixed.  gcc wouldn't even
build 
itself and newlib on many embedded targets for C and C++ much less the
full
language suite. 

Unfortunately, (I suspect) the embedded community is where most of this
type 
of code is going to be found.  A spot check of newlib's CVS shows that
no effort
has been put into this.  I have been emailing with someone fighting the
xscale
specific code and that's all the activity I know of. 

What about *BSD, gdb stubs, libraries with hand optimized insertions 
(e.g. in_cksum routines in TCP/IP stacks or C libraries)?  How many 
pieces of code are impacted?

In fact, a quick check like this:

find . -type f | xargs -e grep "asm volatile" | wc -l

found 4 in gdb 5.0, 18 in newlib 1.10, and 479 in RTEMS.
But search for "asm " and the numbers shoot up to
381 in gdb and 135 in newlib.

Try "asm(" and you get 71 more for newlib and 167 for gdb.

That sums up to over 500 places to check in gdb and 
about 250 in newlib. 

> And adding the 3 chars \n\ to each
> multiline isn't that hard, with Joel's example:
> 
>  asm volatile(" movw %%ds,%0
>                 movw %, %%es"
>                : "=r" (tmp_segment) :
>                : "0" (tmp_segment) );
> 
> would turn into
> 
>  asm volatile(" movw %%ds,%0  \n\
>                 movw %, %%es"
>                : "=r" (tmp_segment) :
>                : "0" (tmp_segment) );
> 
> Seems easy enough to me (did it to the ppc assmbly in glibc for example).

I am not contesting that it is hard -- just that it is a change to
fragile
code.  And that there is a lot more code of this sort around than was
able
to be compiled with gcc 3.0.

No one has answered the question which would convince me this is a 
warranted change.  What is the real technical merit for doing this?
If there is a valid technical reason, then I will suck it up and
start to modify code.  

But I don't see the technical reason yet.
I only see busy work modifying code that is easy to break. :(

> Franz.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: inline asm string/line break rules change

[Jim Wilson]

>No one has answered the question which would convince me this is a 
>warranted change.  What is the real technical merit for doing this?
>If there is a valid technical reason, then I will suck it up and
>start to modify code.  

The multi-line strings feature resulted in confusing and incorrect error
messages.  This problem was difficult to solve.

Consider this testcase:

char *a = "a
        ";
char *b = "b
char *c = "c";
char *d = "d";

The error is on line 3.  Gcc 2.96 gives this output:
tmp.c:5:13: missing terminating " character
tmp.c:1:11: possible start of unterminated string literal

There is no mention of line 3.  It is impossible for gcc to know when you
have intentionally used a multi-line string, and when you have accidentally
used a multi-line string, so it can't know which multi-line string is the
wrong one.  For a 5 line testcase it is easy to spot the error, but if this
is a 5000 line file, and gcc gives you useless line numbers, then you have a
big problem.  The multi-line strings feature doesn't add any expressiveness
to the language.  It only lets you avoid typing a few characters.  Thus it
isn't strictly necessary for any program.  And since the feature creates
problems, the best solution is to eliminate the problematic feature.

You are right that there is now a problem with extended asms, but as others
have mentioned, that is probably best solved by improving the syntax of
extended asms.

Jim

Re: inline asm string/line break rules change

[Joel Sherrill]

Thanks Jim. All I wanted was a technical reason. :)

I am in the process of testing/fixing newlib with 3.2 CVS source and
will use that in turn to test/fix RTEMS.

--joel

Jim Wilson wrote:
> 
> >No one has answered the question which would convince me this is a
> >warranted change.  What is the real technical merit for doing this?
> >If there is a valid technical reason, then I will suck it up and
> >start to modify code.
> 
> The multi-line strings feature resulted in confusing and incorrect error
> messages.  This problem was difficult to solve.
> 
> Consider this testcase:
> 
> char *a = "a
>         ";
> char *b = "b
> char *c = "c";
> char *d = "d";
> 
> The error is on line 3.  Gcc 2.96 gives this output:
> tmp.c:5:13: missing terminating " character
> tmp.c:1:11: possible start of unterminated string literal
> 
> There is no mention of line 3.  It is impossible for gcc to know when you
> have intentionally used a multi-line string, and when you have accidentally
> used a multi-line string, so it can't know which multi-line string is the
> wrong one.  For a 5 line testcase it is easy to spot the error, but if this
> is a 5000 line file, and gcc gives you useless line numbers, then you have a
> big problem.  The multi-line strings feature doesn't add any expressiveness
> to the language.  It only lets you avoid typing a few characters.  Thus it
> isn't strictly necessary for any program.  And since the feature creates
> problems, the best solution is to eliminate the problematic feature.
> 
> You are right that there is now a problem with extended asms, but as others
> have mentioned, that is probably best solved by improving the syntax of
> extended asms.
> 
> Jim

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

inline asm string/line break rules change

[Joel Sherrill]

Hi,

The cvs trunk seems to be newly picky on inline assembly
 
Something like this (contrived):

 asm volatile(" movw %%ds,%0  
                movw %, %%es" 
               : "=r" (tmp_segment) :
               : "0" (tmp_segment) );

Must now the quote closed on each line like this:

 asm volatile(" movw %%ds,%0\n\t"
  	      "movw %, %%es" 
               : "=r" (tmp_segment) :
               : "0" (tmp_segment) );

Was this intentional?  Was there a good reason?  It seems
to effect all target CPUs and I assume a great deal of 
packages that use gcc's inline asm.  I have already spotted
code in newlib's libgloss and RTEMS that trips this.  The
potential set of packages that this might break must be
enormous.

If there was a discussion on this, I must not have missed
it or not realized the potential impact.  I sure don't want 
to begin to modify other code bases until I know the intention.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985