GNU Arm Embedded Toolchain

thumb/libc.a memcpy is huge !

Asked by fenugrec

I just noticed that the memcpy from libc.a is huge (possibly compiled without any -O flags?).
I used
" arm-none-eabi-objdump -d /usr/arm-none-eabi/lib/thumb/libc.a -j .text.memcpy > memcpy_disasm.txt " to view the disassembly... 128 bytes !
Luckily libc_nano.a is a very reasonable 22 bytes.

I realize nano is meant for embedded targets (hence I should be using it), but is there any reason for libc.a 's implementation to be so bloated ? Just different compile-time flags ?
This is from gcc-arm-none-eabi-bin 4.9_2014_q4 .

Thanks,
Chris

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
Joey Ye
Solved:
Last query:
Last reply:
Revision history for this message
Best Joey Ye (jinyun-ye) said : 		#1

libc.a and libc_nano.a pick different implementation of memcpy. One for
performance and one for code size. That's the main reason of code size
difference.

On Fri, Mar 27, 2015 at 2:31 PM, C. Stewart <
<email address hidden>> wrote:

> New question #264249 on GCC ARM Embedded:
> https://answers.launchpad.net/gcc-arm-embedded/+question/264249
>
> I just noticed that the memcpy from libc.a is huge (possibly compiled
> without any -O flags?).
> I used
> " arm-none-eabi-objdump -d /usr/arm-none-eabi/lib/thumb/libc.a -j
> .text.memcpy > memcpy_disasm.txt " to view the disassembly... 128 bytes !
> Luckily libc_nano.a is a very reasonable 22 bytes.
>
> I realize nano is meant for embedded targets (hence I should be using it),
> but is there any reason for libc.a 's implementation to be so bloated ?
> Just different compile-time flags ?
> This is from gcc-arm-none-eabi-bin 4.9_2014_q4 .
>
> Thanks,
> Chris
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>

Revision history for this message
fenugrec (fenugrec) said : 		#2

Yes, a valid point, but I find it surprising that the 128 byte version, with 4-5 local variables on the stack, can have that much of a performance advantage. Ah, but it probably uses word-aligned read/writes so on large blocks it would win. OK. Solved, thanks.

Revision history for this message
fenugrec (fenugrec) said : 		#3

Thanks Joey Ye, that solved my question.