[sdcc-devel] [ sdcc-Bugs-828015 ] Syntax variation for _asm character constants

[SourceForge.net <no...@so...>]

Bugs item #828015, was opened at 2003-10-22 07:50
Message generated for change (Comment added) made by borutr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=828015&group_id=599

Category: C-Front End
>Group: fixed
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Josh Stone (cuviper)
Assigned to: Borut Razem (borutr)
Summary: Syntax variation for _asm character constants

Initial Comment:
Consider the following simple code:

int main() {
    _asm
        mov a,#'A
    _endasm ;
    return 0;
}

When you compile this for the mcs8051 (command: sdcc 
test.c), the following error comes back:

test.c:3:28: missing terminating ' character
?ASxxxx-Error-<q> in line 147 of test.asm
              <q> missing or improper operators, 
terminators, or delimiters
removing test.rel

So the C compiler doesn't like the #'A.  But apparantly 
the compiler "corrects" this anyway and the resulting 
asm file has that line as #'A'.  That's why ASxxx then 
throws an error - asx8051 wants a character constant 
to not have the closing quote, simply #'A as it was 
originally.

If you make it #'A' to begin with, then the C compiler 
doesn't complain, but of course the assembler still 
doesn't like it.


SDCC built fresh from cvs files, updated 10/21/03.
sdcc -v:
SDCC : 
mcs51/gbz80/z80/avr/ds390/pic14/pic16/TININative/xa51
/ds400/hc08 2.3.5 (Oct 21 2003) (UNIX)

----------------------------------------------------------------------

>Comment By: Borut Razem (borutr)
Date: 2003-10-30 23:06

Message:
Logged In: YES 
user_id=568035

The preprocessor skips over anything between _asm and 
_endasm.

Fixed in:
support/cpp2/cpphash.h 1.2
support/cpp2/cppinit.c 1.3
support/cpp2/cpplex.c 1.2
support/cpp2/cpplib.h 1.3
support/cpp2/cppmain.c 1.2



----------------------------------------------------------------------

Comment By: Josh Stone (cuviper)
Date: 2003-10-29 08:23

Message:
Logged In: YES 
user_id=234833

I think Borut's second recommendation is the most correct 
way to handle this -- the preprocessor should skip over 
anything between _asm and _endasm.  This would also take 
care of the z80 issue, and any other instances where the 
preprocessor doesn't agree with the assembler syntax.

----------------------------------------------------------------------

Comment By: Erik Petrich (epetrich)
Date: 2003-10-29 05:38

Message:
Logged In: YES 
user_id=635249

It has also been recently pointed out in a forum message
 
http://sourceforge.net/forum/forum.php?thread_id=922586&forum_id=1864
that this is also a problem with the z80 instruction
  ex af,af'

In this case, af' is the name of the alternate af register
and has nothing to do with character constants.


----------------------------------------------------------------------

Comment By: Borut Razem (borutr)
Date: 2003-10-27 22:38

Message:
Logged In: YES 
user_id=568035

This is actually preprocessor / assembler problem:
- The SDCC preprocessor doesn't know anything about _asm 
and _endasm keywords, but it checks the validity of all 
strings it founds. So in this case it throws the 
error "test.c:3:28: missing terminating ' character" and 
corrects the string
- The SDCC compiler doesn't process anything between _asm 
and _endasm. It merely pass it to the assembler
- The assembler receives the 'A' string, "corrected" by the 
preprocessor, and he is not satisfied with it, displaying the 
error "?ASxxxx-Error-<q> in line 147 of test.asm
<q> missing or improper operators, terminators, or delimiters
removing test.rel"

So I see 2 (or 3) possibilities:
- fix the preprocessor in the way that it doesn't complain 
about non-terminated strings and/or that it doesn't "correct" 
them
- fix the preprocessor that it skips everything between _asm 
and _endasm
- fix the assembler in the way that it accepts character 
constants in #'A' format

My opinion is, that the third option: fix in assembler, is the 
easiest one. The first option is problematic, because 
the "standard" behavior of the preprocessor will be changed, 
the second one would probably mean quite big changes in the 
preprocessor.

Borut


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=828015&group_id=599