Skip to main content

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

On 2022-05-02 14:24, davor@xxxxxxxxxx wrote:

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.

FreeRTOS on Xilinx Zynq devices seems to have pretty stable ethernet, although we didn't really do much beyond "program deploys and runs successfully" yet. Also, this is not a microcontroller; then again, I am not aware of any µC devices with built-in ethernet.

I will probably be trying a Cypress PSoC6 device later this year, which is a proper µC, albeit with comparatively large flash (2MB).

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 definitely like the idea of (optional) static allocation. It would take some work, but I think it can be implemented in a pretty clean way and it would not violate the spirit of FORTE. So for such use cases, I would prefer plain std::vector and some code changes for up-front allocation. This only needs someone to implement that :)

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

I think there is no way around thread-local storage for a fully conformant std::thread (although I can't prove that). I don't know if FORTE uses those parts of the STL that need TLS, but at least one pretty popular dependency (OPC UA/open62541) uses TLS.

I think the proper way to experiment with this approach would be to create a "C++11" architecture and see how much we can abstract away in that. Networking will remain a platform-dependent problem, unfortunately.

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.

The FreeRTOS C++11 compatibility library I mentioned earlier even supports std::condition_variable. GCC seems to support them on one or two other RTOSes as well. But I agree that this is something you won't build as a lightweight emulation for a one-off target.

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

I don't see a performance-friendly way to implement semaphore semantics using C++11 only and not using std::condition_variable.

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?

I still like the idea of a semi-generic C++11 architecture, but networking will be platform-specific for the foreseeable future anyway, so the grand C++11 unification will have to wait.

On the other hand, if you don't need/have networking for some ultra-small platform, you probably could create a new "minimal C++11" platform which might ease porting to exotic targets, possibly even bare metal, with the restrictions you mention. If you document well what C++11 facilities need to be emulated if their toolchain is lacking them, people attempting such a port will know exactly what work lies ahead of them.

Dr.-Ing. Jörg Walter
Gruppenleiter | Group Manager
Distributed Computation and Communication

OFFIS e.V. - Institut für Informatik
FuE Bereich Produktion | R&D Division Manufacturing
Escherweg 2, 26121 Oldenburg - Germany
Phone/Fax.: +49 441 9722-729 / -282
Mobile: +49 176 18811064

Registergericht: Amtsgericht Oldenburg VR 1956
Vorstand: Prof. Dr. Sebastian Lehnhoff (Vorsitzender),
    Prof. Dr. techn. Susanne Boll-Westermann,
    Prof. Dr.-Ing. Andreas Hein, Prof. Dr.-Ing. Wolfgang H. Nebel

Unsere Hinweise zum Datenschutz sind abrufbar unter:

Back to the top