[RFC] Enabling %lld, %llu (long long) support for newlib's stdio


Paul Sokolovsky
 

Hello,

We have a patch to enable format specifiers %lld, %llu (i.e. dealing
with "long long" C types) for Newlib libc in the next Zephyr SDK
release: https://github.com/zephyrproject-rtos/sdk-ng/pull/101

Unfortunately, enabling it also requires to disable
CT_LIBC_NEWLIB_NANO_FORMATTED_IO which accounts for noticeable code
saving in Newlib formatting implementation. The net result of disabling
nano formatting and enabling long long support is +13K/+100% code size
increase for a simple printf() call:
https://github.com/zephyrproject-rtos/sdk-ng/pull/101#issuecomment-524606258

I personally vote up this change because:

1. The reason we have the Minimal libc in Zephyr, even as the default,
is to exactly because of things like that: minimal libc is what we
carefully size-control and optimize (and so should continue do that in
the future, and it should stay the default).

2. On the other hand, there should be a way to port existing software
(a lot of software!) to Zephyr without being swamped with patching it.
And Zephyr lacks many things in that regard so far, so porting existing
code becomes a firefighting with array of issues. If we can cross some
of those issues in 3rd-party components now, and concentrate on things
which belong to Zephyr, we should do that.


But in general, I find it pretty surprising that I advocate changes
which increase the codesize of a simple app twice. Maybe, there're
people with good arguments on the other side?

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Kumar Gala
 

On Aug 25, 2019, at 2:18 AM, Paul Sokolovsky <paul.sokolovsky@linaro.org> wrote:

Hello,

We have a patch to enable format specifiers %lld, %llu (i.e. dealing
with "long long" C types) for Newlib libc in the next Zephyr SDK
release: https://github.com/zephyrproject-rtos/sdk-ng/pull/101

Unfortunately, enabling it also requires to disable
CT_LIBC_NEWLIB_NANO_FORMATTED_IO which accounts for noticeable code
saving in Newlib formatting implementation. The net result of disabling
nano formatting and enabling long long support is +13K/+100% code size
increase for a simple printf() call:
https://github.com/zephyrproject-rtos/sdk-ng/pull/101#issuecomment-524606258

I personally vote up this change because:

1. The reason we have the Minimal libc in Zephyr, even as the default,
is to exactly because of things like that: minimal libc is what we
carefully size-control and optimize (and so should continue do that in
the future, and it should stay the default).

2. On the other hand, there should be a way to port existing software
(a lot of software!) to Zephyr without being swamped with patching it.
And Zephyr lacks many things in that regard so far, so porting existing
code becomes a firefighting with array of issues. If we can cross some
of those issues in 3rd-party components now, and concentrate on things
which belong to Zephyr, we should do that.


But in general, I find it pretty surprising that I advocate changes
which increase the codesize of a simple app twice. Maybe, there're
people with good arguments on the other side?
There are some other options, but they require more development effort.

1. Add support for newlib nano for long long.
2. Add support to crosstool-ng to build multiple newlib variants. And build 2 variants similar to what the ARM embedded toolchains do today (one nano, one full).

- k


Paul Sokolovsky
 

Hello,

On Mon, 26 Aug 2019 08:29:14 -0500
Kumar Gala <kumar.gala@linaro.org> wrote:

On Aug 25, 2019, at 2:18 AM, Paul Sokolovsky
<paul.sokolovsky@linaro.org> wrote:

Hello,

We have a patch to enable format specifiers %lld, %llu (i.e. dealing
with "long long" C types) for Newlib libc in the next Zephyr SDK
release: https://github.com/zephyrproject-rtos/sdk-ng/pull/101
[]


There are some other options, but they require more development
effort.

1. Add support for newlib nano for long long.
2. Add support to crosstool-ng to build multiple newlib variants.
And build 2 variants similar to what the ARM embedded toolchains do
today (one nano, one full).
Right, those are useful options to keep in mind and explore. But given
that they require more development effort, IMHO they should be treated
as separate tasks/projects with their own stakeholders.

And perhaps the problem space considered thoroughly first. As an
example, not everyone knows that there're two "nano" Newlib's. The
latest contender is https://keithp.com/newlib-nano/ . It would be easy
to discount it as something from someone who's not even aware that
"nano" is already taken, but that's @keithp of X.org, etc, fame. So,
either he indeed doesn't known that Newlib already has "nano" mode,
or he thinks that the old nano is not nano enough.

The result is a library that offers broad API support, including
things like complex numbers, high quality math functions that support
both float and double values, a complete string library with wide
char support but with a stdio API that takes only a 20 bytes of RAM.
And that's only the beginning. I personally have an impression that I
see a new libc popping up in github like every month. Hardly they would
be useful for our usecase, but I guess someone wanting to invest time
in developing and maintaining a particular solution would want to check
them out first nonetheless.

And all that is a nice rabbit hole to follow, but from project
management/"enterprise-grade" software engineering perspective, seems
to be quite distinct from an issue at hand of enabling a missing
feature in already selected component, especially that the feature
starts to look like security-related
(https://github.com/zephyrproject-rtos/sdk-ng/pull/101#issuecomment-525300825)


- k

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Carles Cufi
 

Hi Paul,

And perhaps the problem space considered thoroughly first. As an
example, not everyone knows that there're two "nano" Newlib's. The
latest contender is https://keithp.com/newlib-nano/ . It would be easy
to discount it as something from someone who's not even aware that
"nano" is already taken, but that's @keithp of X.org, etc, fame. So,
either he indeed doesn't known that Newlib already has "nano" mode, or
he thinks that the old nano is not nano enough.
This one seems to have been renamed "picolibc":
https://salsa.debian.org/electronics-team/toolchains/picolibc

Carles


Paul Sokolovsky
 

On Tue, 27 Aug 2019 15:00:54 +0000
"Cufi, Carles" <Carles.Cufi@nordicsemi.no> wrote:

Hi Paul,

And perhaps the problem space considered thoroughly first. As an
example, not everyone knows that there're two "nano" Newlib's. The
latest contender is https://keithp.com/newlib-nano/ . It would be
easy to discount it as something from someone who's not even aware
that "nano" is already taken, but that's @keithp of X.org, etc,
fame. So, either he indeed doesn't known that Newlib already has
"nano" mode, or he thinks that the old nano is not nano enough.
This one seems to have been renamed "picolibc":
https://salsa.debian.org/electronics-team/toolchains/picolibc
Good to know, thanks!


Carles


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog