??? 11/18/08 09:41 Read: times |
#160105 - thanks, but... Responding to: ???'s previous message |
Thanks for the suggestion, but how many times do we have to write it in the manual? Wouldn't it be better if users read the manual twice instead of us writing everything twice in it?
On the very same page that Dan referenced, at the top in the first paragraph 3.4.1.1, it is already explained that both data/near and __data/__near can be used synonymously. This could set some expectations. It is also mentioned in the chapter about ANSI-Compliance 8.2 http://sdcc.sourceforge.net/doc/sdccm...de181.html. SDCC manual said:
Certain words that are valid identifiers in the standard may be reserved words in SDCC unless the --std-c89 or --std-c99 command line options are used. These may include (depending on the selected processor): 'at', 'banked', 'bit', 'code', 'critical', 'data', 'eeprom', 'far', 'flash', 'idata', 'interrupt', 'near', 'nonbanked', 'pdata', 'reentrant', 'sbit', 'sfr', 'shadowregs', 'sram', 'using', 'wparam', 'xdata', '_overlay', '_asm', '_endasm', and '_naked'. Compliant equivalents of these keywords are always available in a form that begin with two underscores, f.e. '__data' instead of 'data'.
And finally it is also mentioned in the footnote for inline assembly _asm/_endasm on this page http://sdcc.sourceforge.net/doc/sdccm...ode82.html. Unfortunately the footnote is less readable in HTML form than in the PDF version of the manual http://sdcc.sourceforge.net/doc/sdccman.pdf. Maarten |
Topic | Author | Date |
SDCC declaring SFR bits | 01/01/70 00:00 | |
Manual | 01/01/70 00:00 | |
SDCC declaring SFR bits | 01/01/70 00:00 | |
Header files? | 01/01/70 00:00 | |
Header files? | 01/01/70 00:00 | |
The manual is not enough! | 01/01/70 00:00 | |
This is one way | 01/01/70 00:00 | |
That's not what the manual says | 01/01/70 00:00 | |
Those SFR definitions are working | 01/01/70 00:00 | |
Need someone who knows SDCC: Maarten Brock? | 01/01/70 00:00 | |
variant syntax of SDCC keywords and ANSI-C compatibility | 01/01/70 00:00 | |
C standard compliance | 01/01/70 00:00 | |
Common for all compilers | 01/01/70 00:00 | |
coders should think twice | 01/01/70 00:00 | |
The preprocessor is often a good friend | 01/01/70 00:00 | |
Suggestion | 01/01/70 00:00 | |
thanks, but...![]() | 01/01/70 00:00 |