From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bart Veer To: Fabrice_Gautier@sdesigns.com Cc: ecos-discuss@sourceware.cygnus.com Subject: Re: [ECOS] Redboot and builtin functions Date: Thu, 19 Oct 2000 05:01:00 -0000 Message-id: <200010191200.e9JC0j917530@sheesh.cygnus> References: <5AF611D83988D4118ACF00E0B10400540557D1@mr-intranet.sdesigns.net> X-SW-Source: 2000-10/msg00209.html >>>>> "Fabrice" == Fabrice Gautier writes: Fabrice> About builtins functions, memcpy, memset ... Fabrice> I've seen that memset and memcpy are defined and Fabrice> implemented in multiple places. Fabrice> One of this place is generic-stub.c where a comment says Fabrice> that the stub can't use the same memcpy and memset than Fabrice> the rest (I can't see really why but why not..) Already answered by others. Note that generic-stub.c came from the gdb source tree and was not written from scratch by the eCos team. Fabrice> Another place is the libc (the string part to be more Fabrice> precise) where they are implemented with a weak Fabrice> attribute. There is also the possibility that e.g. an architectural HAL package might implement an optimized version for a specific cpu. AFAIK we don't do that yet for any platform, but we have at least some of the required infrastructure in place. Fabrice> Last place I saw is in redboot, but only for memset, Fabrice> memcpy is not implemted here... (why almost all the Fabrice> strings functions but memcpy?) Same reason as for generic-stub.c, I don't know why memcpy() is missing here. Possibly an oversight, unnoticed because so far memcpy() has not been needed here. Fabrice> And there is the builtins too. Fabrice> So there are 4 implementations, but the one in redboot Fabrice> does not have the same declarations than the one in the Fabrice> eCos libc. I do not know for sure what the builtins Fabrice> declaration is (is there an include file for the Fabrice> builtins?) but I think they conform to the ISO standard, Fabrice> and so I guess are the same as the eCos libc. Fabrice> So, a few questions: Fabrice> 1/ Do the builtins are intented to be used at all in Fabrice> eCos? (if not, it lacks a -fno-builtin in the 386 target) Yes. However my understanding is that the compiler may not support all the builtins on all targets. Even when a builtin is implemented for a given target it will not apply in all cases. For example in the case of memcpy() the compiler might only generate inline code if it knows about source and destination alignments, otherwise it would invoke the function. An inlined memcpy() which can cope with all possible cases involves a non-trivial amount of code, so using such a builtin everywhere would lead to code bloat. Also the function must be available at all times so that code can take its address and pass a function pointer somewhere else. That would be unusual for e.g. memcpy(), but legal. Fabrice> 2/ Why RedBoot doesn't/can't use the string functions Fabrice> defined in the libc ? Or the the builtins ? Answered by others. Fabrice> 3/ Which memcpy/memset the common ethernet support and Fabrice> ethernet drivers are supposed to use ? The builtins if the compiler believes that is the right choice given the target processor and its knowledge about e.g. data alignment. Otherwise the RedBoot ones if the ethernet drivers are being used inside RedBoot (I think). Otherwise the ones in libc - unless there is an alternative implementation in e.g. the architectural HAL Fabrice> 4/ When builtins are used by gcc, when does it use the Fabrice> user-defined version of memcpy/memset ? See above. Bart Veer // eCos net maintainer