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 02/09/2018 02:32 PM, Corinna Vinschen wrote:
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.On Feb 9 19:09, Jaap de Wolff wrote:Van: Jaap de Wolff [mailto:info@jasoon.nl]Van: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org] On 02/09/2018 10:06 AM, Jaap de Wolff wrote:modify ctype not to use __locale_ctype_ptr (== __CTYPE_PTR) or __locale_ctype_ptr_l To do this al inline functions are removed, and the source implementations test hard coded values of the given characters ================================== PATCH ================= diff --gita/newlib/libc/ctype/isalnum.c b/newlib/libc/ctype/isalnum.c index d926f97b7..6d3864114 100644 --- a/newlib/libc/ctype/isalnum.c +++ b/newlib/libc/ctype/isalnum.c @@ -46,5 +46,9 @@ No OS subroutines are required. int isalnum (int c) { +#ifdef _REENT_SMALL + return (isdigit(c) | islower(c) | isupper(c)); #else return(__CTYPE_PTR[c+1] & (_U|_L|_N)); +#endif }I would think that we should be able to do better than this, as this method is taking a half step backwards for some of the functions, such as isalnum(). That is, it potentially loses the efficiency of doing one table lookup plus one OR, as it needs to do N table lookups and N+N-1 ORs (where N appears to be from 1-3). I say "potentially" because maybe the compiler would end up reducing it to the 1+1 case, but maybe not, too (depending on compiler, compiler 1+settings). Before locale was added, isalnum(), for example, was return(__ctype_ptr__[c+1] & (_U|_L)); I'm not sure what the right thing is now (still __ctype_ptr__?), but the same basic thing ought to work, knowing the right thing to put in. But for that matter, why not in the REENT_SMALL case simply redefine __CTYPE_PTR to point to the right thing? Then all these other source file changes become unnecessary. It seems reasonable to expect this to work, and it would be a cleaner solution (since the is*.c files remain untouched, without #ifs). The stated purpose of the patch is to stop ctype from using __locale_ctype_ptr, but ctype.h is where it is defined to be __CTYPE_PTR--so just define it differently. CraigCraig, 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. Corinna
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? A new option? (In case this were somehow considered too radical. For example, you might want your speed and be able to put the table into ROM and so save RAM space (as long as there are not too many macor calls).)
Another possible approach would be to say that the table and the macros should be kept, at the same time that the functions use PREFER_SIZE_OVER_SPEED to not use the table. The user then has complete control over what they get on an individual call basis rather than a library basis. If you want some speed and can afford the size of the table, just default to getting the macros. If you don't want that, use whatever method you want to defeat the macros (#undef, escaping, etc.).
Craig Craig
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |