From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: Craig Burley Cc: martynas@nm3.ktu.lt, alan@spri.levels.unisa.edu.au, gcc2@cygnus.com, egcs@cygnus.com, gas2@cygnus.com Subject: Re: ASM_COMMENT_START and gas divide operator Date: Thu, 14 May 1998 13:08:00 -0000 Message-id: <7019.895176289@hurl.cygnus.com> References: <199805141715.NAA21358@melange.gnu.org> X-SW-Source: 1998/msg00185.html 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