Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #29193

Re: newlib, FreeRTOS, reentrancy, heap and related questions

Show all headers | View raw

Il 06/02/2020 14:58, David Brown ha scritto:
> On 06/02/2020 13:57, pozz wrote:
>> Il 06/02/2020 13:37, Richard Damon ha scritto:
>>> On 2/6/20 7:26 AM, pozz wrote:
> 
>>>> So the final question. If I remove printf/malloc/time/... from
>>>> newlib, is newlib(-nano) needed yet? Is it possible to avoid using
>>>> newlib at all?
>>>> I know I could need memset, strchr, strtok, but those functions can
>>>> be implemented if needed (I think there are many implementations
>>>> available, even in newlib project).
>>>>
>>>> Of course, I don't need stdio features (open, close, read, write,
>>>> exit, ...).
>>>>
>>>> I know newlib is for resource constrained embedded devices, so it is
>>>> already small, but I have the feeling that it's bigger than I need,
>>>> mostly with FreeRTOS.
>>>>
>>>>
>>>> [1] http://www.nadler.com/embedded/newlibAndFreeRTOS.html
>>>
>>> Yes, it is quite possible to totally implement you own 'standard
>>> library' yourself and totally replace newlib-nano. The question comes
>>> does doing so buy you enough to be worth the time.
>>
>> I'm wondering how many standard functions I need to implement without
>> newlib. 1, 10 or 100? How complex would be to implement them?
>> Of course, only me can answer.
> 
> It depends a lot on what you need to do.  A good many of the standard C
> functions are rarely useful in small embedded systems (hands up those
> who need the locale functions or wide character handling).  Most systems
> can also do without the maths functions - perhaps also implementing
> their own for a more appropriate balance between speed and accuracy.

Yes, indeed those are my assumptions.


> There are a few oddities to watch out for.  Technically, you can't
> actually implement malloc() in standard C, 

If I really need heap, I would use FreeRTOS implementation that is 
thread-safe and already available.


> 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.

> Another possibility here is to move to C++.  It has better support for
> memory allocation functions, memory pools, etc.  And you can avoid one
> of the silliest aspects of malloc/free - the fact that the memory
> allocator implementation has to store the size of the allocated block
> somewhere.  Usually when you are freeing memory, you know the size
> already - storing it in the block just makes things less efficient.  C++
> also has functions for "washing" pointers so that you can keep the
> compiler informed about aliasing and re-use of memory, for better
> efficiency and safety.  (I haven't tried much of this myself as yet, but
> I expect to do so before long.)
> 

[1] https://github.com/bminor/newlib/blob/master/newlib/libc/string/memcpy.c

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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