Making more of the C standard library mandatory for freestanding implementations

Am 06.05.2020 um 20:10 schrieb Grant Edwards:
> On 2020-05-06, Philipp Klaus Krause <pkk@spth.de> wrote:
>> Am 06.05.20 um 18:47 schrieb Grant Edwards:
>>>> Do you see any reason those could not be provided on some C
>>>> implementation?
>>>
>>> Memory size.
>>
>> Could you elaborate?
>>
>> I do not see a problem there: If the programmer doesn't use e.g.
>> memcpy(), no memcpy() will be linked in, so memory size would not be
>> affected.
> 
> Would that be required by the spec?

I'm actually pretty surprised that memcpy is NOT required part of a
freestanding implementation (hadn't looked for a while...) because
compilers actually call memcpy even if the programmer does not call it,
for structure assignment.

https://gcc.godbolt.org/z/wGNKDZ

In addition to that, compilers call a bunch of other little helper
functions (e.g. long long division), so they will have a way to pull
functions out of a library if needed.


  Stefan

On 2020-05-07, Stefan Reuther <stefan.news@arcor.de> wrote:

> I'm actually pretty surprised that memcpy is NOT required part of a
> freestanding implementation (hadn't looked for a while...) because
> compilers actually call memcpy even if the programmer does not call
> it, for structure assignment.
>
> https://gcc.godbolt.org/z/wGNKDZ

Yea, that's an acknowleged and documented "feature" of GCC:

  https://gcc.gnu.org/onlinedocs/gcc/Standards.html

See the penultimate paragraph in section 2.1.

> In addition to that, compilers call a bunch of other little helper
> functions (e.g. long long division), so they will have a way to pull
> functions out of a library if needed.

I don't think anybody claimed that there are no low-level compiler
support library functions required when linking in "freestanding"
mode.  Those are typically reserved for use by the compiler and not
visible to the user.

On 07/05/2020 19:17, Grant Edwards wrote:
> On 2020-05-07, Stefan Reuther <stefan.news@arcor.de> wrote:
> 
>> I'm actually pretty surprised that memcpy is NOT required part of a
>> freestanding implementation (hadn't looked for a while...) because
>> compilers actually call memcpy even if the programmer does not call
>> it, for structure assignment.
>>
>> https://gcc.godbolt.org/z/wGNKDZ
> 
> Yea, that's an acknowleged and documented "feature" of GCC:
> 
>    https://gcc.gnu.org/onlinedocs/gcc/Standards.html
> 
> See the penultimate paragraph in section 2.1.
> 
>> In addition to that, compilers call a bunch of other little helper
>> functions (e.g. long long division), so they will have a way to pull
>> functions out of a library if needed.
> 
> I don't think anybody claimed that there are no low-level compiler
> support library functions required when linking in "freestanding"
> mode.  Those are typically reserved for use by the compiler and not
> visible to the user.
> 

Yes.  That can include things like multiplication and division functions 
for processors that don't support it in hardware, and especially 
software floating point.  These things are often referred to as 
"language support libraries" and are part of the compiler, rather than 
part of the C library.

Am 07.05.2020 um 10:16 schrieb Philipp Klaus Krause:
> Am 06.05.20 um 23:25 schrieb Hans-Bernhard Bröker:
>> Am 06.05.2020 um 22:36 schrieb Philipp Klaus Krause:
>>
>>> Yes, but one benefit of standardization is providing a baseline of
>>> functionality that C programmers can target.
>>
>> And a baseline belongs exactly there: at the base of the building, i.e.
>> all the way down.  At the bottom.  And there can be only _one_ baseline.
>>
> 
> Yes. And I am arguing that this baseline should include most of
> string.h. 

Why do you say "yes", and then immediately go on by stating the exact 
opposite of what you just agreed to?

Anything that's not absolutely necessary doesn't belong in the baseline. 
  Otherwise it's something else, but not the baseline.

Am 07.05.20 um 21:39 schrieb Hans-Bernhard Bröker:
> Am 07.05.2020 um 10:16 schrieb Philipp Klaus Krause:
>> Am 06.05.20 um 23:25 schrieb Hans-Bernhard Bröker:
>>> Am 06.05.2020 um 22:36 schrieb Philipp Klaus Krause:
>>>
>>>> Yes, but one benefit of standardization is providing a baseline of
>>>> functionality that C programmers can target.
>>>
>>> And a baseline belongs exactly there: at the base of the building, i.e.
>>> all the way down.  At the bottom.  And there can be only _one_ baseline.
>>>
>>
>> Yes. And I am arguing that this baseline should include most of
>> string.h. 
> 
> Why do you say "yes", and then immediately go on by stating the exact
> opposite of what you just agreed to?
> 
> Anything that's not absolutely necessary doesn't belong in the baseline.
>  Otherwise it's something else, but not the baseline.

I meant yes to having only one baseline. However I argue that the line
should not be drawn at an arbitrary point (why draw it between a large
part of the language and the library, rather than somewhere within the
language or the library?). IMO, the line should be drawn based on what
can be easily implemented on virtually all hardware.

For many embedded users, memcpy() might be more useful and necessary
than long long or float. Also, memcpy() is easier to implement than
support for long long or float. Still the latter are currently mandatory
for freestanding implementations, while the former is not.

Philipp Klaus Krause <pkk@spth.de> writes:
> For many embedded users, memcpy() might be more useful and necessary
> than long long or float. Also, memcpy() is easier to implement than
> support for long long or float. Still the latter are currently mandatory
> for freestanding implementations, while the former is not.

Forth has a core wordset (basically a library) and a bunch of separate
optional wordsets, each of which is standardized.  Floating point
arithmetic is an optional wordset so it's fine if your implementation
doesn't have it.  But if you do choose to supply floating point
features, the standard says what those features should do, so you don't
have to make it up as you go along.

Maybe C could use a similar approach.

On 7.5.20 18:51, Grant Edwards wrote:
> On 2020-05-07, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
> 
>> The shared/dynamic libraries contain all the functions with
>> their entry points listed separately.
> 
> I've never seen a freestanding target that had shared/dynamic
> libraries.  All of the freestanding targets I've ever worked with ran
> as a single statically linked binary executable.
> 
> --
> Grant


Neither have I. Just mentioned it to keep the shared libraries
out of the discussion.

I even use the options in GNU toolset to drop unused functions
at linking stage.

For bare metal, I have needed to recompile the newlib-arm
with size optimization (-Os) to keep the resulting binary
at a minimum size.

-- 

-TV

Am 07.05.2020 um 19:17 schrieb Grant Edwards:
> On 2020-05-07, Stefan Reuther <stefan.news@arcor.de> wrote:
>> I'm actually pretty surprised that memcpy is NOT required part of a
>> freestanding implementation (hadn't looked for a while...) because
>> compilers actually call memcpy even if the programmer does not call
>> it, for structure assignment.
>>
>> https://gcc.godbolt.org/z/wGNKDZ
> 
> Yea, that's an acknowleged and documented "feature" of GCC:
> 
>   https://gcc.gnu.org/onlinedocs/gcc/Standards.html
> 
> See the penultimate paragraph in section 2.1.

I get similar code from ARM msvc, x86-64 clang, and armv8-a clang, so
gcc is not an outlier here.

>> In addition to that, compilers call a bunch of other little helper
>> functions (e.g. long long division), so they will have a way to pull
>> functions out of a library if needed.
> 
> I don't think anybody claimed that there are no low-level compiler
> support library functions required when linking in "freestanding"
> mode.  Those are typically reserved for use by the compiler and not
> visible to the user.

The point I tried to make is that there's little reason to worry that
there is a compiler that links in all of libc if memcpy is used, because
compilers have a means of linking these functions as needed.

TL;DR: I don't see any technical roadblocks that would prevent requiring
more utility functions for a freestanding implementation.


  Stefan

On 2020-05-08, Stefan Reuther <stefan.news@arcor.de> wrote:

> The point I tried to make is that there's little reason to worry
> that there is a compiler that links in all of libc if memcpy is
> used, because compilers have a means of linking these functions as
> needed.
>
> TL;DR: I don't see any technical roadblocks that would prevent
> requiring more utility functions for a freestanding implementation.

What's the benefit of requiring extra stuff for a freestanding
iplementation?

--
Grant

* Grant Edwards:

> On 2020-05-06, Philipp Klaus Krause <pkk@spth.de> wrote:
>
>> In C, most of the standard library is mandatory for hosted
>> implementations only, not for freestadning implementations.  Still,
>> I see many functions, such as memcpy() and abs() often used in
>> programs for embedded systems, and see no obstacles to implementing
>> them even on small systems.
>>
>> Should more of the standard library become mandatory for
>> freestanding implementations?
>
> No.  Just No.  For use on small embedded systems, there must be a
> "bare metal" option that requires no standard library functions.

Why?  Why would the link editor copy unreferenced functions in the
standard library?

My concern would that an implementation that takes this proposal
seriously would make it impossible to test different implementations
of these functions without patching the language implementation itself
(rather just overriding the functions).  So language implementations
would likely continue to provide something like -ffreestanding.