Re: [PATCH] save around 100 bytes on core.img by inlining small misc.c functions

[Vladimir 'phcoder' Serbinenko]

On Wed, Aug 19, 2009 at 5:11 PM, Robert Millan<address@hidden> wrote:
> On Mon, Aug 17, 2009 at 03:54:06PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> On Mon, Aug 17, 2009 at 3:43 PM, Robert Millan<address@hidden> wrote:
>> > On Sat, Aug 15, 2009 at 04:47:32PM +0200, Vladimir 'phcoder' Serbinenko 
>> > wrote:
>> >> +static inline char *
>> >> +grub_strncat (char *dest, const char *src, int c)
>> >> +{
>> >> +  char *p = dest;
>> >> +
>> >> +  while (*p)
>> >> +    p++;
>> >> +
>> >> +  while ((*p = *src) != '\0' && c--)
>> >> +    {
>> >> +      p++;
>> >> +      src++;
>> >> +    }
>> >> +
>> >> +  *p = '\0';
>> >> +
>> >> +  return dest;
>> >> +}
>> >
>> > Some of them (like this one) are surprisingly big.  Did you test them
>> > separately?
>> Yes I did. My test environment was a core.img with pc+fat+biosdisk. I
>> have a log which functions save how much. In this case inlining
>> strncat saved 21 bytes. The reason for some bigger functions to be
>> inlined is that they are used only in non-size critical parts. In this
>> case it's used in LUA and iso9660.mod (one call). So inlining strncat
>> always saves space (even if iso9660.mod is in core.img but there is no
>> size limit when booting from cd).
>
> Ok, fine with me then.
Comitted
>
> --
> Robert Millan
>
>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>  how) you may access your data; but nobody's threatening your freedom: we
>  still allow you to remove your data and not access it at all."
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git