Couple of years ago, when I was working on AVRs, I have managed to get
basic STL working by enabling proper flags during GCC compilation (for
version 5.4).

Basically, all the <traits> and compile time stuff worked just fine without
any issues. With proper insight, I have used all the classes and templates
features of C++ without sacrificing performance nor memory.

The script for GCC compilation (and already-built .deb packages) for
avr-gcc 5.4 with libstdcpp enabled can be found here:

Best regards,

         Grzegorz Gajoch

wt., 2 lut 2021 o 15:52 Klaus <zf...@web.de> napisaƂ(a):

> Hi,
> >
> > Naturally, much of the C++ standard library isn't remotely suitable for
> > AVRs, and should not be supported. However, there are a fair amount of
> > features that I believe would work very nicely, and would be worthwhile
> > to support. For example, std::array, std::optional, <concepts>, and the
> > C++ counterparts to the C standard headers (e.g. <cstdint>).
> For me, most of the <traits> is important to make programming easier.
> And all compile time constant containers as well. A long time ago, for
> gcc 4.x.x I was able to fake the gcc libc++ for avr and was able to use
> a lot of things from scratch. But I saw that it is a moving target to
> keep my adaptions working and stopped my work. I simply faked some of
> the ./bits/* files and was able to compile a lot of stl code. What I saw
> was a lot of dependencies to thread support and such. A lot of headers
> are including each other and it was more or less a big bunch of code not
> very well structured. But all this is decades away :-)
> >
> > It seems that the usual solution for those seeking this functionality is
> > to make their own implementation. While it works, I think it would be
> > nice to have it provided by avr-gcc, if possible. I'd prefer to keep the
> > boilerplate in the compiler rather than my projects.
> >
> > Is there a reason beyond a lack of interest that these features are not
> > supported? I would be happy to work on this if so. Would selectively
> > picking out parts of libstdc++ be a reasonable approach?
> As said, it was possible with some hours of afford to fake parts of STL
> delivered with gcc to work on avr. But if there is no interest from
> others and stl will not be maintained for avr, it makes no sense to run
> behind the main platforms.
> And there is still the problem, that gcc has some very old design
> "bugs". One is vtable in ram and other code which directly goes to ram
> and makes it often impossible to use c++ for some "bigger" projects. I
> see me often writing hand crafted vtable replacements and "deoptimizing"
> switch/case and such stuff, because gcc wastes a lot of ram. Quite clear
> that it is fast, but ram is the most critical resource on avr. I moved
> to arm for a lot of projects, even if avr hardware would be nicer, but
> gcc was not able to generate the needed code for avr for given reasons.
> Missing parts of STL and the ram problem let me move to other controllers!
> Klaus

Reply via email to