Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [4diac-dev] 回复: CSinglyLinkedList improvements

On 4/29/22 11:31, Jörg Walter wrote:
On 2022-04-29 11:03, alois.zoitl@xxxxxx wrote:
On Fri, 2022-04-29 at 10:32 +0200, Davor Cihlar wrote:
So there are no more platforms that doesn't support STL?

AFAIK no. But up to now I'm personally considering STL mostly for new code. Haven't yet found time and need to rework the existing code.

Given that we are about to move beyond C++11, STL is a required dependency anyway. Even when targeting a freestanding C++11 implementation on microcontrollers, there are libraries out there that provide lightweight implementations of the more common STL parts. Not that I would expect this to work out-of-the-box, AFAIK such small targets haven't been tested for a while.

My colleague recently tested something on STM32 and it appeared to have some potential, but it had unreliable ethernet interface so he aborted further work on that hardware and we're currently waiting for our own custom hardware.

Has anyone considered boost? I know it's often times avoided, but it has some more embedded friendly implementations. I.e. lists with static allocation. But I
never had an opportunity to work with it so I don't have any experience with it.
we use boost for the test framework. But never looked beyond that.

In C++11, there is std::pmr::*, that would be a boost-less alternative to more controlled memory management for constrained targets. Even just some strategically placed vector::resize calls could eliminate any problems that might exist -- and like Alois I doubt that there is a problem in the first place. Don't optimize prematurely, i.e. until you have shown (measured) there is actually a problem.

I didn't know for std::pmr::*. I only saw some "DIY" allocators that others have made. So thank you for that. :)

My only concern are embedded devices without an MMU. I don't know (yet? :)) how internals of Forte work and how those lists are used. If the memory fragmentation is an actual concern then it would limit the possibilities of an embedded device and a lot of memory would just be unused (to allow headroom on heap).

But if most lists need only a few elements, then everything would be allocated at startup and no reallocations would occur and that would be completely fine with an ordinary std::vector.

So my suggestion for static allocation is only for parts of Forte that are expected to run on embedded devices and only if it poses a thread of memory fragmentation.

But on the other hand, statically allocated lists also guarantee memory consumption. With them you can exactly know how much memory is needed. It can also increase application robustness.

I do understand that it can complicate things quite a bit, and it also seems like Forte is not exactly designed for embedded device. It's just a nice possibility to be able to run it on them. So I guess I just need to wait for that hardware to arrive and collect some experiences with how demanding Forte on embedded actually is.

I also have some other suggestions:
  * use std::thread and synchronization mechanisms from STL, that can be ported to embedded devices with not too much effort
Here I'm not sure. It definitly is worth a look. But I have no experience about it.

I think this will not be practical, due to the very different RTOSes that FORTE supports.

An example from personal experience: For FreeRTOS, there is a C++11 compatibility library out there that would allow this, but std::thread depends on thread-local storage. That needs explicit support from all of: device, toolchain, C library, and RTOS. In FreeRTOS, each and every board has a different approach to TLS, often none at all. The C library (newlib, picolibc, ...) must have matching support code, and the compiler must use the same mechanism.

I did that once from scratch for STM32+FreeRTOS, and I don't remember it being it too hard to do. But I didn't support the whole standard. Only thread, mutex, chrono, and a few other minor things. I've made std::thread to act like the real one and it didn't require TLS. To support stack size I needed to add specialized functions, outside of C++ standard. I can imagine implementing condition variables would be a pain, and especially on many different platforms, but the question is if it's really needed. Currently Forte uses semaphores instead.

So I'm suggesting using std::mutex and other constructs just as simple wrappers for OS. It would be just like it's currently implemented, but with a different namespace and class names (the C++11 standard ones).

A developer only needs to be aware that if a code needs to run on embedded devices then only a subset of C++11 threading features can be used. Or do you thing it would be too confusing?

Back to the top