This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
On Feb 9 15:54, Craig Howland wrote: > On 02/09/2018 02:32 PM, Corinna Vinschen wrote: > > On Feb 9 19:09, Jaap de Wolff wrote: > > > In basic the intention of my patches is to make to memory footprint for embedded environment small. > > > I talked about locale, and a part of the locale definition is a lookup table with the characteristics of each character. > > > Of course it is possible to move the lookup table outside the locale, but then the lookup table still takes 257 bytes of memory. > > > > > > In the beginning my intention was just to move the __global_locale table from ram to rom, and a reaction was that that was not enough when using embedded processors with 2K or even 1K of ROM and 128 bytes of RAM. > > > > > > I do think that for the intended users of the REENT_SMALL computation speed (efficiency) is less important as memory. > > > So I replaces all usage of a lookup table by a (kind of) computation. > > I'm more with what Craig said. A pointer to a character table has been > > used since newlib started in the 90s. We never had complaints for using > > a single character table before. > > > Jaap has a good point, since the patch does actually totally get rid of the > table and uses comparisons. So while we could get more instructions in a > few functions, it seems unlikely they would add up to the table, and that > size could be saved even for the most minimal application. In addition, the > macro table lookup plus operation is likely larger than a function call, so > the more an app calls them it is likely that, relatively speaking, more size > is saved. > > But to continue the discussion, a big-picture question/issue. Is coupling > it to REENT_SMALL the best approach? Would ditching the table based on > PREFER_SIZE_OVER_SPEED, as is done for a number of the string functions, > make more sense? Or maybe REENT_SMALL && PREFER_SIZE_OVER_SPEED? PREFER_SIZE_OVER_SPEED sounds like the way to go. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat
Attachment:
signature.asc
Description: PGP signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |