Hi, I re-enabled the the floating point support in printf_large() function for small-xstack-auto library, as it was before. The library is generated for regression testing only and is not a part of sdcc binary distribution.
Borut Maarten Brock wrote: > Frieder, > > You may be right about user experience. That is why I suggested to > put it on the user list first. But it could work out the other way > around too. Users that are glad they don't need to recompile part of > the library. > > Compiling printf_large.c twice and renaming one should not be such a > problem. Or include it completely in some otherwise empty file for > the automatic renaming. But how to tell the linker that it must use > the one and not the other object file? > > And what this was really about is to get this pretty large function > some regression testing without rebuilding the library for the > regression tests only. > > I still would like to see more responses. > > Maarten > > >> Borut Razem schrieb: >> >>> I and Maarten Brock had a discussion and agreed to enable the floating >>> point support in printf_large() function included in libsdcc.lib >>> library, which is a part of sdcc distribution, for large, >>> large-stack-auto, small-xstack-auto, medium-xstack-auto and >>> large-xstack-auto models for msc51 target. >>> >>> If you have any objection against this decision, please let me know ASAP. >>> >> Ooops, I'd prefer rather not to. And think I have some objections:) >> >> >> a) I think the increased resource usage will be seen as a major >> regression for users >> >> - migrating from earlier versions of SDCC to 2.9.x versions >> (with one of these memory models). Expect postings like: >> "using latest version of SDCC significantly increased code size" >> >> - migrating from small memory models to one of the larger >> models will result in an disproportionate code memory increase >> being seen. >> >> - migrating from other compilers towards SDCC. >> Note, for the other compiler the source might fit into >> small memory model while SDCC might require large model >> so the size difference can be so Huge as to be discouraging. >> "the evaluation version of the commercial compiler allowed only >> 4 kByte code. To see whether SDCC would be an option I threw the >> code at SDCC, couldn't use the small memory there and ended up with >> x kByte - giving up." >> >> >> b) Additionally I do not like the thought of functionality being >> changed just because the memory model is switched >> (should be as orthogonal to anything as can be). >> "... switched to small memory model and my floating point >> application ..." >> >> >> c) Plus there is a reasonably friendly printf output: "<no float>" >> in case of the non-floating point version of printf being >> used for floats. (we hardly can warn the other way round) >> >> >> Could there be a compiler option like -lPleaseLinkFloatingPointPrintf >> which would we could point users seeing "<no float>" to? >> No perceived regression, just an easy to communicate convenience >> feature added? >> >> >> Greetings, >> Frieder >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Sdcc-user mailing list >> Sdcc-user@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/sdcc-user >> >> > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
