RE: [avr-libc-dev] Feature wishlisht
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... How blind can I be? I am taking this back! I just realized that tests folder exists and that atmega128, at90s8515 (and 4 more- in short arch 2,4,5) are used on simulavr. Ever since delay cycles regression, I was thinking if there is a way to catch such bugs much before. Anitha ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Feature wishlisht
-Original Message- From: Boyapati, Anitha Sent: Sunday, February 27, 2011 7:52 PM To: Boyapati, Anitha; Weddington, Eric; Joerg Wunsch; avr-libc- d...@nongnu.org Subject: RE: [avr-libc-dev] Feature wishlisht 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... How blind can I be? I am taking this back! I just realized that tests folder exists and that atmega128, at90s8515 (and 4 more- in short arch 2,4,5) are used on simulavr. Ever since delay cycles regression, I was thinking if there is a way to catch such bugs much before. Well, certainly there is *some* testing, but as you can see it could certainly use improvement. Ideally, it should be tested for all devices, but that's now well over 100 devices. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Feature wishlisht
As Weddington, Eric wrote: Well, certainly there is *some* testing, but as you can see it could certainly use improvement. In particular, it might need more testcases. Ideally, it should be tested for all devices, but that's now well over 100 devices. That wouldn't have helped in the delay cycles issue though. The problem there is that it's extremely difficult to monitor and verify the delay timing with the limited resources of the simulator (though it's not impossible; at least the gross miscalculation of *4 should have been possible to catch, indeed). Ideally, with any such bug we are fixing and closing, we should accompany it by a testcase that: . demonstrates the bug before the fix is applied, and . verifies the bug is fixed afterwards. Unfortunately, that causes the time to finally apply bugfixes to multiply by at least 10. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Feature wishlisht
On 25/02/2011 23:00, Joerg Wunsch wrote: As Weddington, Eric wrote: On the other hand, I don't like it as an option. -mint8 already breaks avr-libc. Not really. -mint8 doesn't work with the non-mint8 avr-libc binary distributions (so people who'd like to use it have to roll their own or stay away from using library functions), but that's about all. I would rather see 64-bit doubles, 32-bit floats, and library routines to support the user who can then decide which routines to use. The problem here is the same that initially led to the creation of the -mint8 option: promotion rules demand promotions from float to double in many situations, which for sure will cause bloat, lots of bloat. Even the 8-16 bit integer promotions haven't all been shaken out of those places where they aren't necessary within the 10+ years of AVR-GCC lifetime, so I'd expect it'll take another ten years (after establishing 64-bit double support at all) to shake out all the unneeded 32-64 bit FP promotions. Within that period of time, an option like -mdouble32 might save our back. If we do it right, it might even be possible to have avr-libc being compatible with -mdouble32: floating-point arguments aren't used outside libm in many places. libm itself could perhaps map all the 64-bit double functions to their 32-bit float counterparts through #defines if it notices -mdouble32 is in effect, so only a few things remain like printf with floating-point formats, where it could probably be handled by linking a different library through GCC's specs declarations. But well, before that, we need someone to actually implement it ... Btw., IIRC even IAR supports an option like that, despite they are *very* eager to conform to any of the existing standards. gcc already has a -fshort-double switch that makes it use the same size for doubles and floats. I don't know what happens with this if you use library functions (i.e., if you compile double x = 3.14; double y = sin(x) with -fshort-double). But this should probably be the starting point for any options about double sizes. In the development line of gcc, there is also a warning -Wdouble-promotion to warn if a float gets promoted to a double, and -Wunsuffixed-float-constants which warns about writing things like 1.1 instead of 1.1f or 1.1d. Although AVR is one of the smallest mainline gcc targets, the issue of 32-bit floats and doubles is becoming a major issue for bigger targets. I don't know how many people here use gcc for things like the ARM or the PPC, but there are several of these devices that have floating point hardware support for 32-bit floats, but software-only for 64-bit doubles. The relative cost of using 64-bit doubles compared to 32-bit floats is a lot higher on a Cortex M4 than it is on an AVR (or will be, when 64-bit doubles are implemented...). Because of this, support for -fshort-double and new flags like -Wdouble-promotion are already in place in gcc, and groups like CodeSourcery have already been through the issues and written the code. It may be that there are outstanding issues, such as making sure the libraries work correctly in the face of these flags, but it should be possible to make use of this existing work. mvh., David ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Feature wishlisht
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: http://lists.nongnu.org/archive/html/avr-libc-dev/2004-04/msg00125.html 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 toolchain\bin\../lib/gcc/avr/4.5.1/ 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... Thanks Anitha I still want to do the corelib project, but that would technically be in addition to avr-libc, not a part of it. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Feature wishlisht
As Boyapati, Anitha wrote: I recently saw new/delete operator support being requested. This made me think about C++ support. Likewise any such features in the long run maybe... Yes, libstdc++ support is on the wishlist, even though it's beyond the scope of the avr-libc project. Likewise, 64-bit doubles are on the wishlist (as an option to the current implementation), but again, this is much of a compiler issue rather than library only. My preference would be a compiler option much like we've got -mint8, so perhaps -mdouble32 which enables the current behaviour, defaulting to double being 64 bits as this is what the ISO C standard asks for (well, sort of, but they're asking for *more* than 32-bit FP for the double datatype, and while 48 bits would satisfy their requirements, it's IMHO not possible to implement a 48-bit datatype in GCC). I think the standard feature set of avr-libc is pretty much settled, and does not call for many more extensions. (Disclaimer: that's my very personal opinion.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Feature wishlisht
-Original Message- From: avr-libc-dev-bounces+anitha.boyapati=atmel@nongnu.org [mailto:avr-libc-dev-bounces+anitha.boyapati=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Friday, February 25, 2011 11:38 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] Feature wishlisht As Boyapati, Anitha wrote: I recently saw new/delete operator support being requested. This made me think about C++ support. Likewise any such features in the long run maybe... Yes, libstdc++ support is on the wishlist, even though it's beyond the scope of the avr-libc project. Here comes my basic question - we do have libstdc++ in gcc already. However we are not building it for AVR-8 as of now. So what is the requirement for another library? To me it appears that libstdc++ can be built with a bootstrapped compiler (if it is possible). Likewise, 64-bit doubles are on the wishlist (as an option to the current implementation), but again, this is much of a compiler issue rather than library only. My preference would be a compiler option much like we've got -mint8, so perhaps -mdouble32 which enables the current behaviour, defaulting to double being 64 bits as this is what the ISO C standard asks for (well, sort of, but they're asking for *more* than 32-bit FP for the double datatype, and while 48 bits would satisfy their requirements, it's IMHO not possible to implement a 48-bit datatype in GCC). This is still a mystery to me. When BITS_PER_UNIT/WORD is modified, the sizes of INT/LONG get affected. Implementing 48-bit double is definitely not straight forward (or may be not possible? To be confirmed) Anitha ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Feature wishlisht
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Friday, February 25, 2011 11:08 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] Feature wishlisht Likewise, 64-bit doubles are on the wishlist (as an option to the current implementation), but again, this is much of a compiler issue rather than library only. My preference would be a compiler option much like we've got -mint8, so perhaps -mdouble32 which enables the current behaviour, defaulting to double being 64 bits as this is what the ISO C standard asks for (well, sort of, but they're asking for *more* than 32-bit FP for the double datatype, and while 48 bits would satisfy their requirements, it's IMHO not possible to implement a 48-bit datatype in GCC). On the other hand, I don't like it as an option. -mint8 already breaks avr-libc. I would rather see 64-bit doubles, 32-bit floats, and library routines to support the user who can then decide which routines to use. Don't make it optional, as that would mean some toolchains in the field with one set of features, others with another set of features. I think this would just lead to maintenance problems. 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. ;-) I think the standard feature set of avr-libc is pretty much settled, and does not call for many more extensions. (Disclaimer: that's my very personal opinion.) 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? 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. I still want to do the corelib project, but that would technically be in addition to avr-libc, not a part of it. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Feature wishlisht
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Boyapati, Anitha Sent: Friday, February 25, 2011 12:28 PM To: Joerg Wunsch; avr-libc-dev@nongnu.org Subject: RE: [avr-libc-dev] Feature wishlisht Yes, libstdc++ support is on the wishlist, even though it's beyond the scope of the avr-libc project. Here comes my basic question - we do have libstdc++ in gcc already. However we are not building it for AVR-8 as of now. So what is the requirement for another library? To me it appears that libstdc++ can be built with a bootstrapped compiler (if it is possible). No, no, no. We don't mean it as a *new*, separate library. We do mean it as you said: Building libstdc++ that comes with GCC. If it was easy, we would have already done it by now. ;-) Both Joerg and I have looked into doing this many years ago. It doesn't seem straightforward, and both of us ran out of time to look into it. You have to remember that many years ago, there weren't that many C++ users on the AVR. Perhaps, now that some time has passed, there are enough C++ users on the AVR to warrant the time to look deeper into how to get that darn library built for the AVR. If you have some ideas on how to do this, then it would certainly be appreciated. :-) Likewise, 64-bit doubles are on the wishlist (as an option to the current implementation), but again, this is much of a compiler issue rather than library only. My preference would be a compiler option much like we've got -mint8, so perhaps -mdouble32 which enables the current behaviour, defaulting to double being 64 bits as this is what the ISO C standard asks for (well, sort of, but they're asking for *more* than 32-bit FP for the double datatype, and while 48 bits would satisfy their requirements, it's IMHO not possible to implement a 48-bit datatype in GCC). This is still a mystery to me. When BITS_PER_UNIT/WORD is modified, the sizes of INT/LONG get affected. Implementing 48-bit double is definitely not straight forward (or may be not possible? To be confirmed) No, not 48-bit double. We want full-blown 64-bit doubles. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
