Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
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

List of 17 messages in thread
TopicAuthorDate
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      

Back to Subject List