Re: [avr-libc-dev] Feature wishlisht

[Joerg Wunsch]

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. ;-)