> -----Original Message----- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > org] On Behalf Of Dmitry K. > Sent: Saturday, May 03, 2008 3:33 PM > To: [email protected] > Subject: [avr-libc-dev] What about to unify _SFR's macroses? > > Hi. > > We have 3 variants of SFR usage: > 1. This is default for C/C++. Port names are like common variables. > 2. Port names are defined as ordinary numbers, suitable to use with > IN/OUT instructions. > 3. Port names are defined as ordinary numbers (addresses), suitable > to use with LDS/STS instruction. > > The next is too complex to understand (IMHO, worse): > . With variant #2 the _SFR_MEM_ADDR() returns correct > address only for > ports higher than SREG. For smaller ports it returns the > port number, > ie value suitable for IN/OUT. > . With variant #2 the _SFR_ADDR() works correct for C/C++ > source only. > For ASM it is not defined. > . There is no method to determine the address of ports > (those <= 0x5F) > in ASM source. > > What about to change the _SFR macroses: > . _SFR_MEM_ADDR() must return address for all ports in all variants. > . _SFR_ADDR() must be defined in both ASM variants. > . In addition to cryptic __SFR_OFFSET (used for choice the variant) > add clean macroses to set compatibility level, like: > #define _SFR_ASM_COMPAT _SFR_ASM_IOPORT > > Note, the _SFR_IO_ADDR() and _SFR_IO_REG_P() work correct in > all cases. > With proposed changes the _SFR_MEM_ADDR() and _SFR_ADDR() > would be equal. > > Also, I prefer to have default for ASM the variant #3: this > is compatible > with old programs and corresponds to Atmel's datasheet > examples. However, > it too late to change. > > Please, opinions.
I agree that it is a mess and it would be nice to be cleaned up. Do you have a patch available that shows the changes you describe? Eric _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
