[
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.
Regards,
--
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
E-Mail: joerg.walter@xxxxxxxx
URL: http://www.offis.de
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:
https://www.offis.de/datentransparenz.html
