Menu
▾
▴
#147 Inline assembler won't work with C99
When I try to compile
_asm
_endasm;
using sdcc -mz80 --std-c99
I get an error.
I think this is a bug since this is not analogous to
the other sdcc-specific keywords (where "word" is not a
keyword with --std-c99, but "_word" is).
sdc --version gives:
SDCC :
mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08
2.5.6 #4190 (May 26 2006) (UNIX)
Philipp
Logged In: YES
user_id=1270801
From the manual...
Compliant equivalents of these keywords are always available in a form that
begin with two underscores, f.e. ’__data’ instead of ’data’.
(end of section 8.2)
So try __asm (two underscore characters) and __endasm
Regards,
Steven
Logged In: YES
user_id=888171
Only double underscore keywords are reserved in C99 for
the compiler. Unfortunately there is no __asm defined yet.
I will move this to Feature Requests.
Logged In: YES
user_id=589052
I do not understand the condition:
if (!options.std_sdcc && yytext[1] != '_')
return check_type();
in line 71 (and 79) of SDCC.lex. Shouldn't it be:
if (options.std_sdcc && yytext[1] != '_')
there?
Logged In: YES
user_id=888171
The condition is correct. If sdcc language extensions are
not enabled and this keyword does not start with double
underscore then treat it as a normal identifier / keyword
and thus call check_type. Otherwise start accepting the
asm.
This also means that __asm is defined, just poorly
documented. It's in the index but nowhere in the text. The
chapter about ANSI compliance does explain the general
rules however.
Logged In: YES
user_id=589052
Thank you for clarifying!)
So this probably means all occurrences of _asm and _endasm
within the library sources of SDCC could/should be changed
to their "__" versions?
Logged In: YES
user_id=1201677
Originator: NO
Sorry for the dummy question: What feature is requested here exactly?
JW
Logged In: YES
user_id=888171
Originator: NO
Well, Philipp posted this as a bug but I reasoned there is none.
However there are some minor issues like:
* the documentation could be improved.
* the library sources could be changed so they don't need --std-sdcc89 or --std-sdcc99 or the corresponding pragma.
I could have closed and rejected it, but then we would not have the reminder for the developers anymore.
Maarten
Logged In: YES
user_id=1201677
Originator: NO
> * the documentation could be improved.
Hummmm. :-)
> * the library sources could be changed so they don't need --std-sdcc89 or
> --std-sdcc99 or the corresponding pragma.
I thought it's the other way round - my impression was, that if you USE --std-sdcc99, they will fail, as they use the single-underscore version (_asm) ... ?
Jan
Logged In: YES
user_id=888171
Originator: NO
This is properly documented in the manual.
--std-c89 : follow the C89 standard, do not allow sdcc language extensions like xdata, etc. The standard only leaves room for compiler extended keywords that start with two underscores like __xdata.
--std-sdcc89 : follow C89, but do allow language extensions.
Same for --std-c99 and --std-sdcc99.
Logged In: YES
user_id=1201677
Originator: NO
Ah, uh, shame on me...
Nevertheless, this sounds to me as a pretty simple task - just to add an underscore to each _asm and _endasm in the library, isn't it? Sounds like an ideal task for a newbie... but is it worth, a submitted patch (set of patches?) would need to be applied by one of the "old wolves" anyway, it's about as much work as if they would add the underscore themselves isn't it...?
JW
Logged In: YES
user_id=888171
Originator: NO
I´ve changed all special keywords to their double underscore equivalent in the library sources so now they compile with --std-c99. This includes that all _asm/_endasm are replaced with __asm/__endasm. All that remains is that both versions need to be documented in the manual.
Maarten
Logged In: YES
user_id=888171
Originator: NO
Thanks to Jan the documentation is updated too.