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 mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
