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]

Re: FW: [PATCH][STEP 2] ctype changes for removing locale structures


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]