suggestion for GCC (1)

[David Brown]

On 08/02/2011 01:44, Ian Lance Taylor wrote:
> Thomas Martitz<thomas.martitz@student.htw-berlin.de>  writes:
>
>> Am 08.02.2011 00:04, schrieb Ian Lance Taylor:
>>> ali hagigat<hagigatali@gmail.com>   writes:
>>>
>>>> A necessary feature for GCC is to compile C/Assembly programs without
>>>> standard libraries for Intel architectures.
>>> This feature can not and will not be implemented.  Some supporting
>>> routines are always required, particularly for gcc extensions like
>>> nested functions and __attribute__ ((cleanup)).
>>
>> IIRC the functions Ali mentioned (mem*) are the only required ones to
>> build working binaries without C library (i.e. for bare metal
>> targets). We do it this way at Rockbox.
>>

Do you not use any sort of libc?  I do embedded programming on a number 
of targets, and while I avoid most of libc (there's seldom any evil 
"malloc" or "printf" calls in my code), some of it is useful.

>> But I wonder why, the mem* functions are trivial to implement in plain
>> C so why does one need to provide them?
>
> I took ali to be asking to build without any libraries at all, including
> libgcc, which is what you get when you use -nostdlib.  That can't work.
>

On most of the targets I use, libgcc is essential for supporting the 
language itself (if your target doesn't have division instructions, for 
example, then the supporting library functions are in libgcc).  My 
understanding is that libgcc contains what is needed for the C language, 
but is not supposed to contain anything from the C standard library.

> I think you are talking about the case where we do use libgcc, but don't
> use libc.  In other words: why don't we provide memcpy, etc., in libgcc,
> or, rather, just call libgcc-specific routines?  The answer is that we
> expect the library provider to have a highly optimized version of those
> functions.  That is certainly the case when using glibc on GNU/Linux.
> Since the library provider should already have a highly optimized
> version, gcc doesn't bother providing one itself.
>

The optimal implementation of something like memcpy is highly dependent 
on the target, so I agree it doesn't make sense to try to put it libgcc. 
  Even for the same architecture, "optimised" will mean different things 
on different platforms.  For a small ARM microcontroller, "optimised" 
will mean "small" - for an ARM netbook, "optimised" will mean "fast". 
The memcpy implementations in the target libc will presumably have an 
appropriate algorithm.

> Of course we could still arrange to provide simple versions in some
> additional library which is only linked after libc.  I would not be
> opposed to that.  Real C programs, though, almost always call memcpy and
> friends themselves, and real C programs always require some level of
> supporting code.  The current situation doesn't really bother me.
>

Doesn't gcc treat functions like memcpy as builtins?  Or is that only if 
you explicitly write __builtin__memcpy?  I would have thought that in 
many cases, a builtin version can be a lot smaller and faster than 
library code, since the compiler often knows about things like alignment 
and sizes and can thus generate better code.