smaller ramsize for newlib-nano builds

[Orlando Arias]

On 02/01/2018 07:57 AM, Corinna Vinschen wrote:
> On Jan 31 17:50, Jaap de Wolff wrote:
>> I am working with embedded systems with have very limited ram resources.
>>
>> As known current version of the newlib-nano build uses 364 bytes of ram for
>> __global_locale
>>
> This build option should be available via a configure option, ideally.
> Also, the change itself basically changes __global_locale to read only,
> so I wonder if the name of the option shouldn't reflect that, kind of
> like
> 
>   ./configure --enable-readonly-locale
> 
> or
> 
>   ./configure --enable-const-locale
> 
>> I realize that MB_CAPABLE must be off for this modification, but are there
>> other implications?
> 
> I don't think so, but a potential patch submission should make sure that
> under normal circumstances no write access occurs with this option.

Greetings,

For a while I have been contemplating making a patch set that provides
an option to utilize only the C locale, removing all locale stuff from
newlib at build time. Moving the __global_locale to ROM may be a good
temporary solution, however, it will not work well for resource limited
devices. For example, the MSP430F2013 provides only 2 kB of ROM and the
MSP430F2003 has only 1 kB. This is about 1/6 and 1/3 of the total
program capacity of the device, respectively ( further exacerbating the
problem is that these particular devices only provide 128 B of RAM).

Unfortunately, I do not have much time to actually work on this
proposal, but I am willing to give it a shot if I can find some
documentation on how current locale stuff is implemented in newlib
(other than ``the code is the documentation''). Any pointers on this
would be greatly appreciated.

Thank you.

Cheers,
Orlando.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/newlib/attachments/20180201/1c005f95/attachment.sig>