From: Borut R. <bor...@si...> - 2009-01-24 18:10:16
|
Hi sdcc users, 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. Borut |
From: Frieder F. <fri...@we...> - 2009-01-25 20:22:11
|
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 |
From: Maarten B. <sou...@ds...> - 2009-01-25 20:41:50
|
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 > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Borut R. <bor...@si...> - 2009-02-01 12:19:16
|
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 >> Sdc...@li... >> 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 > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > |