Re: [avr-libc-dev] io.h re-org

[Joerg Wunsch]

As Theodore A. Roth wrote:

> The patch looks good, but it's too much at once. My plan (when I got
> around to it) was to do something similar but in small, incremental
> steps.

> It's a pain, but it makes review much easier. It's not much fun
> trying to review a 2500 line diff and grok everything it does. ;-)

OK, another idea.  Instead of reviewing the 2500 line diff, just
review the effect it has on compiled programs. :)

At least the technical correctness can be verified by comparing the
preprocessor symbols resulting from the inclusion of <avr/io.h> before
and after the change.  This can easily be automated by using avr-gcc
-E -dM, run on a simple .S file that is almost empty except of the
#include <avr/io.h> line.

This only ensures technical correctness, i. e. stylistic changes
cannot be verifies that way (like, i might have forgotten a
placeholder comment telling that e. g. 0x3F is SREG), nor can it catch
harmless situations where i missed to remove one of the #define
statements within the device-specific header file so now a macro is
defined twice with the same arguments.

The script and the result are attached.  Since i pulled out the list
of supported devices from doc/api/main_page.dox, as a side-effect it
became obvious that there are two typos. ;-) (at90s8534 must be
at90c8534, and there's no such device as an attiny10.)  I'll fix that.

Also attached a revisited diff, now with Changelog entries. ;-)  The
io1200.h file got a few more changes to comply with the specific
details of this device (no EEMWE bit, no ZH register).

One common difference between the old and new io.h is that only two of
the device-specific header files used to contain bit definitions for
SREG (i. e., for the processor's flag bits).  I decided they are
useful enough to have even though they aren't really needed mostly,
since there's often a shorter way to express the same idea using one
of the specialized SREG-examining opcodes, so they are now in the
generic file.  In order to not obfuscate the diff from the regression
test, i omitted this difference in the verification.


Here's a discussion of the remaining differences:

The io1200.h file was missing a definition for EEAR (the generic
EEPROM address register), this has been added automatically now (which
is an alias for the 8-bit EEARL).

The automated decision about the EEPROM registers based on E2END
causes differences for the at90s4414 and at90s4434 devices: they have
only 256 bytes of EEPROM, thus they now don't get an EEARH declared,
and EEAR becomes an alias for EEARL.  Since they are the `smaller'
counterparts of the '8515 and '8535 devices, the EEARH register might
officially exist even in the smaller devices but their use makes no
sense.  Would we like to live with the automated decision, or should i
rather special-case these two devices to be (bug-)compatible with the
datasheet?

The automated decision about the stack pointer symbols made obvious
that there have previously been bugs in the at90s2333 and at90s4433
files: these devices do not officially have SPH registers.

The ATmega162 file was missing a definition for SP (the generic stack
pointer register).

As already mentioned, the files for atmega169, atmega32, and
atmega8535 now also have definitions for XRAMEND.

The ATtiny15 file was completely missing the inclusion of
<avr/sfr_defs.h>.

The ATtiny28 file erroneously declared bits in the non-existent EECR
register (this device doesn't have EEPROM at all).

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/

regress
Description: Text document

regresslog
Description: Text document

diff
Description: Text document