[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] Feature wishlisht
From: |
Joerg Wunsch |
Subject: |
Re: [avr-libc-dev] Feature wishlisht |
Date: |
Fri, 25 Feb 2011 23:00:29 +0100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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.
> 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. ;-)
Oh, yeah, that way people could easily encrypt their source code in
FORTRAN. :-)
However, another prerequisite for FORTRAN would be a full stdio, i.e.
one that can handle true files within a filesystem. The FORTRAN
library has standardized functions for that, so the FORTRAN to C
mapping would want to map those onto the standard C library.
> 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?
No, not really. If someone really feels like it, I might look into
that again.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
- [avr-libc-dev] Feature wishlisht, Boyapati, Anitha, 2011/02/25
- Re: [avr-libc-dev] Feature wishlisht, Joerg Wunsch, 2011/02/25
- RE: [avr-libc-dev] Feature wishlisht, Boyapati, Anitha, 2011/02/25
- RE: [avr-libc-dev] Feature wishlisht, Weddington, Eric, 2011/02/25
- RE: [avr-libc-dev] Feature wishlisht, Boyapati, Anitha, 2011/02/26
- RE: [avr-libc-dev] Feature wishlisht, Boyapati, Anitha, 2011/02/27
- RE: [avr-libc-dev] Feature wishlisht, Weddington, Eric, 2011/02/27
- Re: [avr-libc-dev] Feature wishlisht, Joerg Wunsch, 2011/02/28