Hi! 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: https://github.com/ggajoch/gcc-avr-libstdcpp 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 > >
