Hi.
>
> Hmm... Yes, this is better in compile time and library
> image size in comparison to pure lib_per_device.
> However, this excludes the possible optimization, for
> example '-mtiny-stack' for ATtiny2313.
It is small advantage, to compile avr-libc with '-mtiny-stack' optimisation
for devices with 8-bit stack pointer. The advantage of this optimisation
appears only for the "big" functions, at which the size of the frame buffer is
more 3-5 byte. Not much such functions in avr-libc, and as they is "big",
usually are not used on devices with 1 or 2 KB of code memory.
I do not see the reasons to add new architecture in avr toolchain for devices
with 8-bit stack pointer. It is enough to have '-mtiny-stack' switch in the
avr-gcc.
> At the other
> hand, the current lib_per_arch approach permits to
> have a small set functions per device with CPP redefining.
>
My offer to add "library for device" to solve problem, when two devices is a
members to one architecture, but have peripheral modules located on different
addresses, for example eeprom or wdt, and different functions for work with
these modules is required.
Anatoliy.
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
