[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [avr-libc-dev] Feature wishlisht

From: Boyapati, Anitha
Subject: RE: [avr-libc-dev] Feature wishlisht
Date: Sat, 26 Feb 2011 22:36:04 +0800

>As an admittedly weird side-benefit: IIRC, I think that all we need is to
>implement 64-bit doubles in order to build the Fortran compiler of GCC for
>the AVR target. That is if anyone really cares about writing Fortran for
>the AVR. ;-)

Aahh..Fortran support :-)

>And in my opinion, there are other things that we can do to improve and
>extend avr-libc even more.
>IIRC, there are some routines that we could add to improve XMEGA support,
>including some of those "timed sequences" inline assembly routines.
>We also talked about making avr-libc build "per device", instead of build
>per architecture like we do now. Did that get ever fully settled?

Particularly this thread is interesting: 

Also as linker uses emulation per architecture the linker scripts are per arch 
basis. Specifying the exact text and data size of a device is not done. However 
what I don't understand is -mavrN option. (I am assuming N stands for arch 
suffix like 2, 3, 4, 51...). This is what I get when verbose is turned on:

cc1.exe -quiet -v -imultilib avr51 -iprefix c:\program files\atmel\avr 

I don't see any explicit -mavrN option here.

>Anitha, there is also a TODO file in the source tree (I think under /doc)
>which contains a lot of old ideas that we've had over the years.

Thanks Eric, I have gone (rather have been going) through it. I did not get the 
[7] part of it - Smallest common denominator for IO port declarations. There 
was an intense discussion on avr-gcc-list under the title -'port access with 
avr-gdb'. I am still trying to get head and tail of all the conversations on 
this issue :-(

The other point I would like to know is test strategy - how is avr-libc being 
tested currently? Do we use simulator for executing tests or some set of 
devices per family...


>I still want to do the "corelib" project, but that would technically be in
>addition to avr-libc, not a part of it.
>AVR-libc-dev mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]