ASM_COMMENT_START and gas divide operator

ASM_COMMENT_START and gas divide operator

[Alan Modra]

There is a problem with using "/" to start comments, such as those
emitted by gcc's -fverbose-asm.  If gas needs to support "/" meaning
the start of a comment anywhere on a line, then the gas division
operator is killed, sometimes silently.  For instance:
  asm("pushl $FOO/2")
is treated as if the programmer wrote
  asm("pushl $FOO")

Of course, this is only a problem with hand-coded assembly, but it
would be nice to fix gas and gcc.  At least on linux, where the only
assembler used with gcc is gas, we should be able to make the
following change without causing too many problems.

	* config/linux.h (ASM_COMMENT_START): Define as "#"
	* config/linux-aout.h (ASM_COMMENT_START): Likewise

--- gcc/config/linux.h~	Sun Apr  5 03:08:45 1998
+++ gcc/config/linux.h	Fri May  1 10:54:14 1998
@@ -34,6 +34,9 @@
 #define MULTIBYTE_CHARS 1
 #endif
 
+#undef ASM_COMMENT_START
+#define ASM_COMMENT_START "#"
+
 #undef ASM_APP_ON
 #define ASM_APP_ON "#APP\n"
 
--- gcc/config/linux-aout.h~	Sun Dec  7 03:54:04 1997
+++ gcc/config/linux-aout.h	Fri May  1 10:54:14 1998
@@ -36,6 +36,9 @@
 #undef STARTFILE_SPEC
 #define STARTFILE_SPEC  "%{pg:gcrt0.o%s} %{!pg:%{p:gcrt0.o%s} %{!p:crt0.o%s}} %{static:-static}"
 
+#undef ASM_COMMENT_START
+#define ASM_COMMENT_START "#"
+
 #undef ASM_APP_ON
 #define ASM_APP_ON "#APP\n"
 

Re: ASM_COMMENT_START and gas divide operator

[Jeffrey A Law]

  In message <Pine.LNX.3.96.980501124359.28262A-100000@mullet.Levels.UniSA.Edu.ou write:
  > There is a problem with using "/" to start comments, such as those
  > emitted by gcc's -fverbose-asm.  If gas needs to support "/" meaning
  > the start of a comment anywhere on a line, then the gas division
  > operator is killed, sometimes silently.  For instance:
  >   asm("pushl $FOO/2")
  > is treated as if the programmer wrote
  >   asm("pushl $FOO")
  > 
  > Of course, this is only a problem with hand-coded assembly, but it
  > would be nice to fix gas and gcc.  At least on linux, where the only
  > assembler used with gcc is gas, we should be able to make the
  > following change without causing too many problems.
  > 
  > 	* config/linux.h (ASM_COMMENT_START): Define as "#"
  > 	* config/linux-aout.h (ASM_COMMENT_START): Likewise
Thanks.  I've installed this into egcs.

It's possible we'll get some ASM_COMMENT_START redefinitions because
of this.  If so, we'll have to squash 'em.

jeff

Re: ASM_COMMENT_START and gas divide operator

[Andreas Schwab]

Jeffrey A Law <law@cygnus.com> writes:

|>   In message <Pine.LNX.3.96.980501124359.28262A-100000@mullet.Levels.UniSA.Edu.ou write:
|>   > There is a problem with using "/" to start comments, such as those
|>   > emitted by gcc's -fverbose-asm.  If gas needs to support "/" meaning
|>   > the start of a comment anywhere on a line, then the gas division
|>   > operator is killed, sometimes silently.  For instance:
|>   >   asm("pushl $FOO/2")
|>   > is treated as if the programmer wrote
|>   >   asm("pushl $FOO")
|>   > 
|>   > Of course, this is only a problem with hand-coded assembly, but it
|>   > would be nice to fix gas and gcc.  At least on linux, where the only
|>   > assembler used with gcc is gas, we should be able to make the
|>   > following change without causing too many problems.
|>   > 
|>   > 	* config/linux.h (ASM_COMMENT_START): Define as "#"
|>   > 	* config/linux-aout.h (ASM_COMMENT_START): Likewise
|> Thanks.  I've installed this into egcs.

This is wrong, it breaks m68k-linux, and perhaps all other non-intel linux
port.  It must be moved to config/i386/linux.h.  There is no such thing as
a universal comment character.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org

Re: ASM_COMMENT_START and gas divide operator

[Alan Modra]

On 7 May 1998, Andreas Schwab wrote:

> Jeffrey A Law <law@cygnus.com> writes:
> 
> |>   In message <Pine.LNX.3.96.980501124359.28262A-100000@mullet.Levels.UniSA.Edu.ou write:
> |>   > There is a problem with using "/" to start comments, such as those
> |>   > emitted by gcc's -fverbose-asm.  If gas needs to support "/" meaning
> |>   > the start of a comment anywhere on a line, then the gas division
> |>   > operator is killed, sometimes silently.  For instance:
> |>   >   asm("pushl $FOO/2")
> |>   > is treated as if the programmer wrote
> |>   >   asm("pushl $FOO")
> |>   > 
> |>   > Of course, this is only a problem with hand-coded assembly, but it
> |>   > would be nice to fix gas and gcc.  At least on linux, where the only
> |>   > assembler used with gcc is gas, we should be able to make the
> |>   > following change without causing too many problems.
> |>   > 
> |>   > 	* config/linux.h (ASM_COMMENT_START): Define as "#"
> |>   > 	* config/linux-aout.h (ASM_COMMENT_START): Likewise
> |> Thanks.  I've installed this into egcs.
> 
> This is wrong, it breaks m68k-linux, and perhaps all other non-intel linux
> port.  It must be moved to config/i386/linux.h.  There is no such thing as
> a universal comment character.

OK, you're right.  Just as well I said "without causing too many
problems" rather than "no problems" :-)  What about ASM_APP_ON and
ASM_APP_OFF defined on the next few lines down?  Do these really
belong in config/i386/linux.h too?

Re: ASM_COMMENT_START and gas divide operator

[Andreas Schwab]

Alan Modra <alan@spri.levels.unisa.edu.au> writes:

|> On 7 May 1998, Andreas Schwab wrote:

|>> Jeffrey A Law <law@cygnus.com> writes:
|>> 
|>> |>   In message <Pine.LNX.3.96.980501124359.28262A-100000@mullet.Levels.UniSA.Edu.ou write:
|>> |>   > There is a problem with using "/" to start comments, such as those
|>> |>   > emitted by gcc's -fverbose-asm.  If gas needs to support "/" meaning
|>> |>   > the start of a comment anywhere on a line, then the gas division
|>> |>   > operator is killed, sometimes silently.  For instance:
|>> |>   >   asm("pushl $FOO/2")
|>> |>   > is treated as if the programmer wrote
|>> |>   >   asm("pushl $FOO")
|>> |>   > 
|>> |>   > Of course, this is only a problem with hand-coded assembly, but it
|>> |>   > would be nice to fix gas and gcc.  At least on linux, where the only
|>> |>   > assembler used with gcc is gas, we should be able to make the
|>> |>   > following change without causing too many problems.
|>> |>   > 
|>> |>   > 	* config/linux.h (ASM_COMMENT_START): Define as "#"
|>> |>   > 	* config/linux-aout.h (ASM_COMMENT_START): Likewise
|>> |> Thanks.  I've installed this into egcs.
|>> 
|>> This is wrong, it breaks m68k-linux, and perhaps all other non-intel linux
|>> port.  It must be moved to config/i386/linux.h.  There is no such thing as
|>> a universal comment character.

|> OK, you're right.  Just as well I said "without causing too many
|> problems" rather than "no problems" :-)  What about ASM_APP_ON and
|> ASM_APP_OFF defined on the next few lines down?  Do these really
|> belong in config/i386/linux.h too?

No, these are correct.  There are two types of comments, one that start on
column 1 and the other that do not.  ASM_APP_* are only written at the
start of the line, and here # is used as comment universally.  For inline
comments every port has different conventions.  For example, on m68k the #
is used to denote immediate operands, thus it cannot start a comment.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org

Re: ASM_COMMENT_START and gas divide operator

[Martynas Kunigelis]

Alan Modra wrote:
> 
> There is a problem with using "/" to start comments, such as those
> emitted by gcc's -fverbose-asm.  If gas needs to support "/" meaning
> the start of a comment anywhere on a line, then the gas division
> operator is killed, sometimes silently.  For instance:
>   asm("pushl $FOO/2")
> is treated as if the programmer wrote
>   asm("pushl $FOO")
> 
> Of course, this is only a problem with hand-coded assembly, but it
> would be nice to fix gas and gcc.  At least on linux, where the only
> assembler used with gcc is gas, we should be able to make the
> following change without causing too many problems.
> 

I would suggest hacking gas to treat '/' as the comment _only_ when it
is the first character in the line. This does not break gcc/egcs and
does not interfere with the division operator or the opcode prefix
separator syntax.

Martynas

Re: ASM_COMMENT_START and gas divide operator

[Jeffrey A Law]

  In message < 355A9E38.8C82D78B@nm3.ktu.lt >you write:
  > I would suggest hacking gas to treat '/' as the comment _only_ when it
  > is the first character in the line. This does not break gcc/egcs and
  > does not interfere with the division operator or the opcode prefix
  > separator syntax.
Actually I would recommend against that -- I've had the pleasure of
writing a gas port (HPPA) where certain characters had different
meanings depending on their exact placement in a line.  To this day
it still doesn't work 100% correctly -- the grammar is inherently
ambigious.  In my case the character is a '!', and is used in
comparison operations, as a gas built-in operator *and* as a line
continuation character.

jeff

Re: ASM_COMMENT_START and gas divide operator

[Craig Burley]

>Actually I would recommend against that -- I've had the pleasure of
>writing a gas port (HPPA) where certain characters had different
>meanings depending on their exact placement in a line.  To this day
>it still doesn't work 100% correctly -- the grammar is inherently
>ambigious.  In my case the character is a '!', and is used in
>comparison operations, as a gas built-in operator *and* as a line
>continuation character.

Oh, that's easy to handle.  It's a built-in operator if it isn't
the first character in the line, otherwise it's a line-continuation
character if the line being continued would be syntactically and
semantically correct, also produced faster code, than if it was
interpreted as a line-comment character, otherwise it's a line-
comment character.

Yes, I'm being sarcastic.  Especially regarding HPPA assembler
syntax as provided by HP, which was designed by someone who
should not have been let near a language-design project like
that, too often "little languages", whether assemblers, tools,
or C++, are designed by people who are unaware of, or give little
thought to, the outright readability of code written in the
language, in the sense that the basic semantics should be fairly
obvious *without* the reader having to memorize lots of semantic
information.

(In HPPA assembler's case, one glaring stupidity was the
nullified branches, which have completely different semantics
depending on whether the label being branched to happens to assemble
to a negative or positive offset!  A smarter design would have
required the programmer to specify whether such a branch was
a "forward" or "backward" branch explicitly, then the assembler
and/or linker would complain if reality didn't match the programmer's
specification.  I've never looked into whether GNU's HPPA as fixes
this botch; I gather GNU as fixes many botches, though, so it
wouldn't surprise me if it did, even though that might make
for some compatibility problems with existing HP as code.)

As far as characters meaning something special only when they're
in column 1: sometimes that's barely reasonable (C's "#" directives,
excluding #pragma), but most often it really just makes the
little language look more like the bad old days of Fortran,
in the sense that even *Fortran* no longer has such a weird
syntax in its modern incarnation (Fortran 90's "free" format).

        tq vm, (burley)

Re: ASM_COMMENT_START and gas divide operator

[Jeffrey A Law]

  In message < 199805141715.NAA21358@melange.gnu.org >you write:
  > Oh, that's easy to handle.  It's a built-in operator if it isn't
  > the first character in the line, otherwise it's a line-continuation
  > character if the line being continued would be syntactically and
  > semantically correct, also produced faster code, than if it was
  > interpreted as a line-comment character, otherwise it's a line-
  > comment character.
If it were only that easy :-)  The obvious problem is you have to
scan ahead (potentially a long way!) to determine what the '!'
character means. And I bet I could write (contrived) code which
is syntatically correct, but has multiple meanings for the PA.


  > Yes, I'm being sarcastic.  Especially regarding HPPA assembler
  > syntax as provided by HP, which was designed by someone who
  > should not have been let near a language-design project like
Absolutely.  The assembler syntax (and HP's implementation) leave
much to be desired.  I *really* disliked the "feature" that you
could omit operands and the HP assembler would fill them in as
zeros for you.  This caused quite a few bugs over the years in
hand written code -- much of it in HP's own kernel & library code).

  > (In HPPA assembler's case, one glaring stupidity was the
  > nullified branches, which have completely different semantics
  > depending on whether the label being branched to happens to assemble
  > to a negative or positive offset!
I've never found this to be strange or stupid at all.  The behavior
clearly matches the hardware.

What is horrible is that the next linear instruction is actually
a backwards branch as far as the hardware is concerned.  This leads
to the infamous "empty if/else block bug" on the PA with gcc-2.7.*.

  > specification.  I've never looked into whether GNU's HPPA as fixes
  > this botch; I gather GNU as fixes many botches, though, so it
  > wouldn't surprise me if it did, even though that might make
  > for some compatibility problems with existing HP as code.)
It fixes many botches, but not this one (cuz I never considered it
a botch :-)

jeff

Re: ASM_COMMENT_START and gas divide operator

[Craig Burley]

>  > (In HPPA assembler's case, one glaring stupidity was the
>  > nullified branches, which have completely different semantics
>  > depending on whether the label being branched to happens to assemble
>  > to a negative or positive offset!
>I've never found this to be strange or stupid at all.  The behavior
>clearly matches the hardware.

Matching the hardware directly is *not* a wise way to design a
language, including "low-level" assembly language.  Besides,
if you look at what I'm asking for here, it's an *explicit*
(IMO s/b required) specification of the sign bit on a
conditionally nullified branch, instead of letting the sign bit
of the assembler-calculated offset govern (instead they'd be
checked against each other).

That is, for a conditionally nullified branch, you'd (IMO have to)
write either "bcond,nf label" to branch *forward* on condition cond
or "bcond,nb label" to branch *backward* on that condition.  (I
think HP uses 'n', SPARC uses 'a', but I've lost track.)

Instead what programmers must *think* is "this will be a forward
branch" and yet they can only *write* "this will be a branch in
some direction", and hope the knowledge of the direction, which
crucially affects the semantics (in that it governs under what
conditions the subsequent instruction is nullified), is "properly"
encoded via the relative placement of the target label!  Blecch.
That means they can't comfortably write serial code and fill in
target labels later on as they see fit, for example.

In short, the sign bit of the offset field performs two duties
in the hardware.  One is the normal duty vis-a-vis the current PC,
for which the calculated offset is, of course, a fine source.

The other is the rather distinct duty that bit performs when it
comes to determining whether the next instruction is to be annulled.

Since the programmer has to know what that bit's value is going to
be when writing the relevant instructions, a properly designed
assembler language would require that explicit specification,
rather than relying on subsequent assembler/linker arithmetic
done on the target label -- which the programmer *cannot*, to
my knowledge, constrain in any direct way.

After all, if you try a thought-exercise whereby you assume
the two functions were *separately encoded* -- one bit for
annull "direction", one for offset sign -- you'd realize pretty
quickly that a) such a separation would be quite useful, if
the ISA had room for it, and b) the current syntax doesn't
support the separation, even optionally.

This might seem like a minor nit, but, coming from a 128-bit VLIW
background, I know firsthand how important it is to work with a
reliable assembler *and* assembly language.  Having the language
"help" by guessing at what you *must* know you mean is bad enough
(as you point out regarding the silently-zero-filled fields),
but having it *refuse* any direct, coherent specification of what
you *must* know you mean is a classic example of bad language design.

>What is horrible is that the next linear instruction is actually
>a backwards branch as far as the hardware is concerned.  This leads
>to the infamous "empty if/else block bug" on the PA with gcc-2.7.*.

I have no problem with how the hardware works, but maybe I'm
not aware of the problem to which you're referring.  In fact,
maybe we're discussing two different things!

What I *do* have a problem with is that code like this (and I'm
probably going to get the basic instruction mnemonics wrong,
because I haven't done HPPA RISC coding for well over a year now)...

	...
	ret			; Unconditional return, no fall-through

mylabel:
	ld	...
	...
	b	finishup	; Unconditional branch, no fall-through

othercode:
	...

...can work just fine.

Then you decide "hmm, for I-cache or whatever reasons, I'd like
to move the clearly distinct block at mylabel somewhere else".

This is just the sort of code movement that's often done in any
decent programming language, including pretty much every
assembler I've ever worked with, where the worst thing that
can *normally* happen is that the assembler or linker complains
that a label is now "out of range" of a branch's offset field.

(Imagine how you'd feel if, instead of "out of range", all
the assemblers and linkers we used silently truncated the
offset to fit!  That's roughly the kind of problem I'm talking
about here.)

And, from every examination of the code an assembly programmer
is likely to make to verify that such a move is okay, there's
no way to realize that the code *breaks* because some *other*
code does a conditionally nullified branch to it, and the
reason that branch is now broken because:

  -  mylabel used to be a backward branch, but now is forward,
     or vice versa, so the semantics of the conditionally
     nullified *branch* have changed, in terms of deciding
     at run time whether the next instruction is nullified, and

  -  The stupid assembler syntax gave the programmer *no way*
     to directly encode that knowledge he *did* have at the
     moment he wrote that now-broken branch -- namely, whether
     the branch was forward or backward!

(IMO, the knowledge should be *required*, but at least *allowing*
it would be a huge improvement, assuming the assembler and linker
error-checked it.)

In other words, an apparently innocuous change in one part of a
module breaks code in a completely different part of the module.

If you think silently filling in zeros leads to subtle and
hard-to-grep-for bugs, try coping with the even rarer, even
more subtle bugs *this* kind of thing leads to, when "grep"
is of limited help (since it can't read your mind about what
directions were intended, and can't complain about "missing
fields" when you're not even *allowed* to fill in the fields
by the assembler!).

I'm not in any way advocating "assembler for dummies", since
tracking things like register usage can confuse almost anyone
(though at least they can use long "mangled" names to avoid some
such problems; in short, such problems result from non-local
context and thus are not the fault of local syntax).

What I am advocating is "no more assembler language design *by* dummies".

;-)

In this case, I'd say the summary of the linguistic bug is that
a crucial bit of semantic knowledge that applies purely locally
is derived from a combination of local and remote information.

That is, it's the relationship between the branch instruction and
its (perhaps distant in the source code) target that determines
how that branch instruction will behave *locally*, e.g. even if
it never jumps to the remote target of the branch!  It's okay
that the *hardware* behaves that way, because bits is bits, but
the assembly *language* must give the programmer a way to specify
the knowledge he must have in his head using entirely *local*
syntax (to correspond to the local semantics).

And, I'm nearly 100% sure that, if a "flag day" happened whereby
all HPPA RISC assemblers started requiring these forward/backward
notations, and every bit of code was modified to include the
*expected* direction, assuming a 100% success rate reading the
minds of the original programmer, there'd be a non-zero number of
existing bugs discovered in code in production right now.

If I had to do any development on an HP-PA RISC machine, I'd
first fix this bug in the assembler and disassembler.  Or,
at least, if I wasn't coding in assembler for the project, in
the disassembler, so gdb output would be clearer.  I wouldn't
let anyone on a project of mine write assembler code without
writing it in a fixed assembly language.  There's no point
having programmers waste time by knowing a thing, having no
way to tell the computer what they know, then going through
a long debugging session only to find out that they (or someone
else) "forgot" that thing when moving some other chunk of code
around, and *still* have no way to tell the computer what
they learned!  Especially since we're talking about one
character per relevant instruction, though you can tell by
now I must not mind typing much.

(Of course, the hacker's solution to this would be to write
tools to look at any changes to assembly source, via diff
for example, then assemble the old and new sources and make
sure that no *other* diffs vis-a-vis sign bits of offsets
appeared in the assembled code.  ;-)

        tq vm, (burley)