论坛

使更多的C标准库对于独立实现是强制性的

开始于 菲利普·克劳斯·克劳斯 2020年5月6日
Am 06.05.2020 um 20:10 schrieb 格兰特·爱德华兹:
> On 2020-05-06, 菲利普·克劳斯·克劳斯 <pkk@spth.de> wrote: >> Am 06.05.20 um 18:47 schrieb 格兰特·爱德华兹: >>>> 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. //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. > > //gcc.godbolt.org/z/wGNKDZ
Yea, that's an acknowleged 和 documented "feature" of GCC: //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 和 not visible to the user.
On 07/05/2020 19:17, 格兰特·爱德华兹 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. >> >> //gcc.godbolt.org/z/wGNKDZ > > Yea, that's an acknowleged 和 documented "feature" of GCC: > > //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 和 not > visible to the user. >
Yes. That can include things like multiplication 和 division functions for processors that don't support it in hardware, 和 especially software floating point. These things are often referred to as "language support libraries" 和 are part of the compiler, rather than part of the C library.
Am 07.05.2020 um 10:16 schrieb 菲利普·克劳斯·克劳斯:
> Am 06.05.20 um 23:25 schrieb 汉斯·伯恩哈德·布朗&ouml;ker: >> Am 06.05.2020 um 22:36 schrieb 菲利普·克劳斯·克劳斯: >> >>> 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.&nbsp; At the bottom.&nbsp; 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", 和 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 汉斯·伯恩哈德·布朗&ouml;ker:
> Am 07.05.2020 um 10:16 schrieb 菲利普·克劳斯·克劳斯: >> Am 06.05.20 um 23:25 schrieb 汉斯·伯恩哈德·布朗&ouml;ker: >>> Am 06.05.2020 um 22:36 schrieb 菲利普·克劳斯·克劳斯: >>> >>>> 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.&nbsp; At the bottom.&nbsp; 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", 和 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. > &nbsp;Otherwise it's something else, but not the baseline.
I meant yes to having only one baseline. 怎么样ever I argue that the line should not be drawn at an arbitrary point (why draw it between a large part of the language 和 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 和 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.
菲利普·克劳斯·克劳斯 <pkk@spth.de> writes:
> For many embedded users, memcpy() might be more useful 和 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) 和 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, 格兰特·爱德华兹 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 格兰特·爱德华兹:
> 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. >> >> //gcc.godbolt.org/z/wGNKDZ > > Yea, that's an acknowleged 和 documented "feature" of GCC: > > //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, 和 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 和 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
* 格兰特·爱德华兹:

> On 2020-05-06, 菲利普·克劳斯·克劳斯 <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() 和 abs() often used in >> programs for embedded systems, 和 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.