2008/10/10 Bernhard Reutner-Fischer <[EMAIL PROTECTED]>:
> On Fri, Oct 10, 2008 at 07:07:52PM +0200, walter harms wrote:
>>
>>
>>Bernhard Reutner-Fischer schrieb:
>>> On Fri, Oct 10, 2008 at 04:21:51PM +0200, Loïc Grenié wrote:
>>>> I've noticed that busybox uses few functions from libm.
>>>
>>> Actually, you can turn off ASH_MATH_SUPPORT_64 FEATURE_AWK_MATH and
>>> you don't need libm at all.
>>>
>>>> I've written some replacements for those functions. Right
>>>> now this is just the test program and I've not made the
>>>> effort of including them in Busybox. However I'd like to
>>>> have your opinion: would it be a good idea to include
>>>> them ?
>>>
>>> I don't think so (but perhaps vda likes it anyway). Just:
>>> 1) turn off the abovementioned two features
>>> or, if either of that is really needed desperately, you can
>>> 2a) link busybox statically (very likely in the scenarios you mention
>>> below)
>>> 2b) Use a trimmed libm which only contains those few functions that will
>>> be needed by your initramfs (usually 0, see #1 above).
>>>
>>>> They are neither very fast nor very precise (the
>>>> trigonometric functions are awful, up to 16 bits are
>>>> false) but libm is rather large and usually a user of
>>>> Busybox on an initrd or embedded platform does not
>>>> need neither speed nor excellent precision. Otherwise
>>>
>>> I think that neither of them need ASH_MATH_SUPPORT_64 FEATURE_AWK_MATH,
>>> so busybox wouldn't link against libm anyway.
>>
>>
>>Hi Bernhard,
>>you are right but the idea is nice and we do not have a lot of libm functions.
>
> text data bss dec hex filename
> 754 0 0 754 2f2 e_log.os (ex libm-mini.a)
> 12 0 0 12 c w_log.os (ex libm-mini.a)
> 688 0 0 688 2b0 e_exp.os (ex libm-mini.a)
> 12 0 0 12 c w_exp.os (ex libm-mini.a)
> 2340 0 0 2340 924 e_pow.os (ex libm-mini.a)
> 12 0 0 12 c w_pow.os (ex libm-mini.a)
> 316 0 0 316 13c k_cos.os (ex libm-mini.a)
> 236 0 0 236 ec s_cos.os (ex libm-mini.a)
> 246 0 0 246 f6 k_sin.os (ex libm-mini.a)
> 238 0 0 238 ee s_sin.os (ex libm-mini.a)
> 670 0 0 670 29e k_tan.os (ex libm-mini.a)
> 138 0 0 138 8a s_tan.os (ex libm-mini.a)
> 408 0 0 408 198 e_sqrt.os (ex libm-mini.a)
> 12 0 0 12 c w_sqrt.os (ex libm-mini.a)
> 660 0 0 660 294 e_atan2.os (ex libm-mini.a)
> 12 0 0 12 c w_atan2.os (ex libm-mini.a)
> 52 0 0 52 34 s_fabs.os (ex libm-mini.a)
> 1308 0 0 1308 51c e_rem_pio2.os (ex libm-mini.a)
> 1530 0 0 1530 5fa k_rem_pio2.os (ex libm-mini.a)
> 9644 0 0 9644 25ac (TOTALS)
> 10324 172 0 10496 2900 libm-mini.so
>
> $ file libm-mini.so
> libm-mini.so: ELF 32-bit MSB shared object, Motorola 68020, version 1
> (SYSV), dynamically linked, not stripped
>
> So approximately 10k for a random m68k smallish-libm with accurate
> precision.
>
> Loïc didnt' paste the size, but if they are not precise then it's easy
> to cut down on the size :)
Indeed. bloat-o-meter says:
function old new delta
myatan2 - 344 +344
mysqrt - 327 +327
myexp - 316 +316
mycos_or_sin - 289 +289
mylog - 285 +285
.rodata 8 136 +128
mytan - 58 +58
mypow - 35 +35
mysin - 27 +27
mycos - 27 +27
------------------------------------------------------------------------------
(add/remove: 9/0 grow/shrink: 1/1 up/down: 1836/0) Total: 1836 bytes
If there is a better solution, I don't mind !
Loïc
_______________________________________________
busybox mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/busybox
