Re: Partial libstdc++ Support
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 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 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, , and the > > C++ counterparts to the C standard headers (e.g. ). > > For me, most of the 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 > >
Re: Partial libstdc++ Support
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, , and the C++ counterparts to the C standard headers (e.g. ). For me, most of the 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
Re: Partial libstdc++ Support
Hey John, > 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. I've been playing with the same thought for a while and briefly looked into this. It's worthwile to note that other embedded targets (notably ARM) seem to just include the c++ standard libraries that come with gcc which supports a lot of the useful stuff. Then, I think avr *could* use the same approach, except that the convention so far is to just disable the standard library on all avr-gcc builds. Maybe because there are bugs or things not yet properly implemented for AVR, but not using the standard library will in itself lead to more bugs in AVR if you ever try to enable it. Having said that, I think there have been some people in the past who tried enabling the gcc c++ standard library for avr, which has indeed seen some success. I've been meaning to try this as well with the Arduino-built avr-gcc version or maybe the Debian version, which are the versions I use most, but haven't found the time so far (probably will not have time for this in the near future either). From my previous look into this, I collected some links that might prove useful. I'll share them here without further comment (I'd have to look at them again to comment): - http://gcc.1065356.n8.nabble.com/avr-freestanding-libstdc-td1710708.html#a1710857 - https://www.reddit.com/r/cpp/comments/esk2wy/standard_c_library_on_gccs_avr_target/ - https://patchwork.ozlabs.org/project/gcc/patch/CADfx-VSmfye0Xe7xMWVFZKDZhQbwFcw7RbNYe=6irdjuzpt...@mail.gmail.com/ - https://patches-gcc.linaro.org/patch/9338/ - https://patches-gcc.linaro.org/patch/9338/ - http://avr-libstdcxx.gitlab.io/ Gr. Matthijs signature.asc Description: PGP signature
Re: Partial libstdc++ Support
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, , and the C++ counterparts to the C standard headers (e.g. ). For me, most of the 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
Re: Partial libstdc++ Support
Hi John, We already have and , for example, when the freestanding implementation of libstdc++ is used. You can check in the C++ standard[1] all we have until now and you also can take a look at the Freestanding Proposal (p0829)[2] of Ben Craig to know more about what we can have in the future. If you want to contribute with something in this field, I think that maybe it's a good idea to take a look at https://gitlab.com/avr-libstdcxx, which is an effort to implement the p0829 in gcc. [1] https://timsong-cpp.github.io/cppwp/n4861/compliance [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0829r4.html On Mon, 01 Feb 2021 16:20:01 -0300 John A. Leuenhagen wrote Hi all, I enjoy working in C++ with avr-gcc. Since C++11, there have been a number of low overhead features that can really make programming nicer. Unfortunately, a fair number of these are part of the standard library, and thus aren't available with avr-gcc. 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, , and the C++ counterparts to the C standard headers (e.g. ). 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?
