This is the mail archive of the gas2@sourceware.cygnus.com mailing list for the gas2 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: ASM_COMMENT_START and gas divide operator



  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