Re: [avr-libc-dev] [CVS commit: HEAD] document <avr/delay.h>

[Marek Michalkiewicz]

On Mon, Dec 20, 2004 at 10:08:31PM +0100, Joerg Wunsch wrote:

> The only problem I'm seeing as that you never know which new
> differences you might encounter on the next Atmel.  There was already
> a remark about one device (was it the secure AVR?) that's got a couple
> of other instructions unknown to current AVRs.  Ah yep, SBRA and CBRA,
> see here:
> 
> http://www.avrfreaks.net/phpBB2/viewtopic.php?t=24957

Thanks for the pointer.  But, these instructions don't look very
interesting for the compiler - will probably only be found in
hand-optimized assembler code.  As long as they add new opcodes,
and don't redefine existing ones (I hope!) - I don't see much of
a problem here.  SBRA and CBRA can be handled just like SPM - the
compiler itself never needs to generate them, no multilibs needed.

This situation is different than MOVW, which is clearly useful to
the compiler, because it reduces code size (and the ABI was even
changed to gain more from MOVW - that's why function args are
aligned on even-numbered registers today) - it is quite a big loss
if GCC can't (right now) use MOVW on ATtiny2313 etc.

> Hmm, but I'd definately want this to be maintained along with newlib,
> otherwise we end up in maintaining even more software packages than we
> maintain right now.

One more software package, but still the same total amount of code :)
I think newlib, once ported completely, will be quite stable and rarely
will need to be updated again.  The per-device part is much more
dynamic (Atmel releases new devices often, renames bits in datasheets
even more often, etc.) and, looking at the avr-libc development until
now, will probably need most of the work in the future.

> I've already got too many spare-time jobs at hand.  With a couple of
> small kids (soon to be three, so I'm catching up with Eric ;-)
> spare-time isn't an unlimited resource.

No kids here, but I understand the problem (spare time) very well...
I just don't think keeping the per-device part separate from newlib
will cost more work in the long run.  It can be quite the opposite:
no need to rebuild all of newlib (just the small per-device library)
when new AVR devices (with no interesting new opcodes) are added.

Just to clarify: newlib would only contain generic C library code
(most of it written in C; some possibly hand-optimized assembler,
such as memcpy), and multilibs are only needed to handle different
_instruction sets_ (not per-device details like I/O registers).
These don't change as often - Atmel makes lots of new devices by
adding peripherals around the same few basic AVR cores.

> I'm not too much concerned about that.  After all, keep in mind that
> the vast majority of people is likely to use pre-defined or
> pre-compiled toolchain kits.  If we can manage it to settle WinAVR
> (Eric), cdk4avr (Stephan), the FreeBSD ports (myself), and maybe
> whatever is used on MacOS X (any maintainer over here?) to ship a new
> version of all required tools by the same time, we've got pretty much
> a coverage of probably 99 % of our user base by this.  So unlike your
> old days, Marek, we're IMHO in a much better situation these days.

You're right.  While I'm still used to building AVR tools from CVS,
most people today will install the nicely (thanks!) packaged versions.
Time for me to finally forget about these old days, I guess :)

> Can you elaborate?  What would be the maximum possible size, 8 MB?

8 MB flash, 64 KB RAM.  Size checking by ld scripts is not reliable
anyway (only text size is checked, but text+data must actually fit
in the flash) - it's a historic thing (long long ago we had almost
per-device ld scripts, one for each combination of flash/RAM sizes).

Marek