Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #29201
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: newlib, FreeRTOS, reentrancy, heap and related questions |
| Date | 2020-02-06 21:41 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <r1htmh$q0g$1@dont-email.me> (permalink) |
| References | <r1h0m7$cdt$1@dont-email.me> <QLT_F.426957$ek.10442@fx48.iad> <r1h2gi$lkd$1@dont-email.me> <r1h627$9jo$1@dont-email.me> <r1ha0p$van$1@dont-email.me> |
On 06/02/2020 16:06, pozz wrote:
> Il 06/02/2020 14:58, David Brown ha scritto:
>
>> nor can you implement memcpy
>> or memmove, due to the type aliasing and effective type rules. If you
>> want to be sure of problem-free code that is safe regardless of
>> optimisation, link-time optimisation, new generations of compilers,
>> etc., then you'll be quite careful and make good use of gcc attributes.
>
> What about copying byte by byte?
> Here[1] you can see newlib memcpy implementation. If
> PREFER_SIZE_OVER_SPEED or __OPTIMIZE_SIZE__ is defined, the
> implementation is really copying byte by byte.
>
> I don't really know how newlib used by my compiler (CubeIDE from ST) was
> compiled, maybe I'm using dumb version of memcpy already.
>
> This is an extract from a listing:
>
> 08025850 <memcpy>:
> 8025850: b510 push {r4, lr}
> 8025852: 1e43 subs r3, r0, #1
> 8025854: 440a add r2, r1
> 8025856: 4291 cmp r1, r2
> 8025858: d100 bne.n 802585c <memcpy+0xc>
> 802585a: bd10 pop {r4, pc}
> 802585c: f811 4b01 ldrb.w r4, [r1], #1
> 8025860: f803 4f01 strb.w r4, [r3, #1]!
> 8025864: e7f7 b.n 8025856 <memcpy+0x6>
>
> I'm not an expert of assembly, but it seems to me it is implemented in
> the simple and not optimized way.
>
It is not the actual copying that is the problem - copying by char is
simple and safe (though often inefficient). The issue is that the C
standards say memcpy also copies the effective type in certain
circumstances - there is no way to specify that in C, and it is
therefore a special feature of the library memcpy. A homemade memcpy
does not have that same feature. (In a similar vain, there is no way to
get memory in standard C that has "no declared type" except via the
library malloc and friends - a homemade malloc won't do.) I am not sure
what the best solution is here.
Anyway, for memcpy make sure the compiler can use the builtin versions
where possible (avoid -ffreestanding, or use -fbuiltin) as this will
give far better code.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
newlib, FreeRTOS, reentrancy, heap and related questions pozz <pozzugno@gmail.com> - 2020-02-06 13:26 +0100
Re: newlib, FreeRTOS, reentrancy, heap and related questions Richard Damon <Richard@Damon-Family.org> - 2020-02-06 07:37 -0500
Re: newlib, FreeRTOS, reentrancy, heap and related questions pozz <pozzugno@gmail.com> - 2020-02-06 13:57 +0100
Re: newlib, FreeRTOS, reentrancy, heap and related questions David Brown <david.brown@hesbynett.no> - 2020-02-06 14:58 +0100
Re: newlib, FreeRTOS, reentrancy, heap and related questions pozz <pozzugno@gmail.com> - 2020-02-06 16:06 +0100
Re: newlib, FreeRTOS, reentrancy, heap and related questions David Brown <david.brown@hesbynett.no> - 2020-02-06 21:41 +0100
Re: newlib, FreeRTOS, reentrancy, heap and related questions pozz <pozzugno@gmail.com> - 2020-02-06 23:23 +0100
Re: newlib, FreeRTOS, reentrancy, heap and related questions Richard Damon <Richard@Damon-Family.org> - 2020-02-06 23:44 -0500
Re: newlib, FreeRTOS, reentrancy, heap and related questions David Brown <david.brown@hesbynett.no> - 2020-02-07 09:51 +0100
Re: newlib, FreeRTOS, reentrancy, heap and related questions Paul Rubin <no.email@nospam.invalid> - 2020-02-07 01:04 -0800
Re: newlib, FreeRTOS, reentrancy, heap and related questions David Brown <david.brown@hesbynett.no> - 2020-02-07 10:48 +0100
Re: newlib, FreeRTOS, reentrancy, heap and related questions Paul Rubin <no.email@nospam.invalid> - 2020-02-07 08:00 -0800
Re: newlib, FreeRTOS, reentrancy, heap and related questions David Brown <david.brown@hesbynett.no> - 2020-02-08 16:19 +0100
Re: newlib, FreeRTOS, reentrancy, heap and related questions Paul Rubin <no.email@nospam.invalid> - 2020-02-08 19:42 -0800
Re: newlib, FreeRTOS, reentrancy, heap and related questions David Brown <david.brown@hesbynett.no> - 2020-02-09 12:11 +0100
Re: newlib, FreeRTOS, reentrancy, heap and related questions David Brown <david.brown@hesbynett.no> - 2020-02-07 10:35 +0100
Re: newlib, FreeRTOS, reentrancy, heap and related questions Dave Nadler <drn@nadler.com> - 2020-02-06 07:21 -0800
Re: newlib, FreeRTOS, reentrancy, heap and related questions pozz <pozzugno@gmail.com> - 2020-02-06 17:14 +0100
Re: newlib, FreeRTOS, reentrancy, heap and related questions pozz <pozzugno@gmail.com> - 2020-02-06 23:26 +0100
Re: newlib, FreeRTOS, reentrancy, heap and related questions Richard Damon <Richard@Damon-Family.org> - 2020-02-06 23:29 -0500
Re: newlib, FreeRTOS, reentrancy, heap and related questions Richard Damon <Richard@Damon-Family.org> - 2020-02-06 23:23 -0500
Re: newlib, FreeRTOS, reentrancy, heap and related questions pozz <pozzugno@gmail.com> - 2020-02-07 09:19 +0100
Re: newlib, FreeRTOS, reentrancy, heap and related questions upsidedown@downunder.com - 2020-02-07 11:36 +0200
Re: newlib, FreeRTOS, reentrancy, heap and related questions pozz <pozzugno@gmail.com> - 2020-02-07 14:31 +0100
Re: newlib, FreeRTOS, reentrancy, heap and related questions Dave Nadler <drn@nadler.com> - 2020-02-07 05:55 -0800
Re: newlib, FreeRTOS, reentrancy, heap and related questions Dave Nadler <drn@nadler.com> - 2020-04-05 15:05 -0700
csiph-web