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.
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
Yea, that's an acknowleged and documented "feature" of GCC:
See the penultimate paragraph in section 2.1.
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:
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.
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.
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
I get similar code from ARM msvc, x86-64 clang, and armv8-a clang, so gcc is not an outlier here.
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
What's the benefit of requiring extra stuff for a freestanding iplementation?
-- Grant
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.
Some small embedded systems have no support for a linker of any kind - assembly inevitably proceeds to an exectuable. It was more common on older systems but you still see it on oddball architectures and "research quality" (it this context that means rough and ready) development tools.
-- Andrew Smallshaw andrews@sdf.org
Am 08.05.20 um 19:01 schrieb Andrew Smallshaw:
Can you give an example of a C99, C11 or C17 implementation of this type? Clearly, this would be a limitation of the implementation, not of the targeted hardware.
Am 08.05.20 um 17:56 schrieb Grant Edwards:
Not requiring the users of freestanding implementations to roll their own implementations of that extra stuff.
Making the "freestanding" subset more useful.
It probably depends on what one considers the mission of a freestanding implementation. I had considered the primary objective to be: run without any operating system support. Things like 'memcpy' or 'strlen', even 'sprintf', can be implemented in pure C without any operating system support (needing just a little implementation knowledge like "how to stringify a pointer" in 'sprintf', or "how to detect overlap" in 'memmove'). Therefore, adding those functions does not constrain the environment such an implementation could run on.
If one instead considers a freestanding implementation to be just a portable assembler to turn logic into machine code and otherwise get out of my way, leaving out 'memcpy' & friends is plausible.
Stefan
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.