Re: Limited RAM stdio replacement for newlib

On Fri, Sep 21, 2018, 10:19 AM Keith Packard <[email protected]> wrote:

> Can Finner <[email protected]> writes:
>
> > Did you try newlib-nano options?  In case it doesn't fit into your use
> > case either, is it possible to improve nano instead?
>
> Yes I did. Even with all of the knobs dialed to minimize memory usage it
> still uses many kB of memory, requires malloc and has a fairly deep call
> stack. At this point, I'm pretty convinced that there's no reasonable
> way to create a stdio that targets good performance in high-capability
> environments while offering options that reduce memory usage to near
> zero bytes of ram.
>
> The other benefit of this replacement stdio is that it doesn't depend on
> any POSIX interfaces like open/close read/write, so the underlying OS
> needn't have support for those, only character-at-a-time get and put
> functions.
>

This made me remember that RTEMS has a simple set of printk stdio. Would it
be possible to have a set of "kernel" stdio methods in parallel with
regular stdio. Use names like printk, sprintk, etc and have a user level
feature flag to enable macros that map stdio to those methods.

I am just pondering. The idea of having both in newlib sounds useful. We
use multilibs for many variants within an architecture so we have a single
toolchain for all arm variants. Being able to let an application select
when it is built if they are mapped to these would be desirable.

Now the best you get is integer only methods or a rebuild for nano which
doesn't meet these smallest systems.

--joel

>
> --
> -keith
>