Unterstützen C++ Compiler für verschiedene µC-Architekturen mittlerweile durchgängig C++11 bzw. C++14? Ich hab eine Idee für eine Library, die im Wesentlichen für Microcontroller gedacht ist. Es wäre schön, wenn ich das mit C++14 umsetzen kann ohne mich zusehr auf einige wenige Architekturen zu beschränken, die das bereits unterstützen. Unabhängig von der obigen Frage würde es mich auch interessieren, welche Version der Sprache (C oder C++) von eurer Toolchain unterstützt wird. Der XC8 von Microchip (C-Compiler) ist ja z.B. immer noch auf C89 Niveau. Daher rührt auch die Befürchtung, dass viele meine Bibliothek nicht nutzen könnten, wenn ich diese mit C++14 schreibe.
AVR Arduino ist auf C++11 Konfiguriert. Mit Austausch der Toolchain steht C++17 vollumfänglich(?) zur Verfügung AVR Gcc 9.2
Beispielsweise kann der GCC für sämtliche ARMs C++ compilieren. Das mchte ich nicht mehr missen, denn wenn immer es geht nutze ich C** statt normalen C.
Joghurtbecher mit Arsenfüllung schrieb: > Beispielsweise kann der GCC für sämtliche ARMs C++ compilieren. Das heißt, auf ARM stehen einem alle Funktionen des (aktuellen) GCC zur Verfügung? Defacto wäre das dann ja die gesamte Sprachfunktionalität.
Danish B. schrieb: > Das heißt, auf ARM stehen einem alle Funktionen des (aktuellen) GCC zur > Verfügung? Defacto wäre das dann ja die gesamte Sprachfunktionalität. https://gcc.gnu.org/projects/cxx-status.html
> ist ja z.B. immer noch auf C89 Niveau.
Wenn du deine grossartige Library nicht in C89 fassen kannst,
ist sie womoeglich gar nicht so grossartig und der Rest der
Welt kann gerne darauf verzichten.
Es gibt sogar schon OS mit C++ API. Und wenn du zuviel Speicher übrig hast kannst du den auch mit iostreams vollpacken.
Danish B. schrieb: > Unterstützen C++ Compiler für verschiedene µC-Architekturen mittlerweile > durchgängig C++11 bzw. C++14? Das hängt allein von der Compilerversion ab. Beim verbreiteten gcc steht C++14 ab 7.3 zur Verfügung. XC8 von Microchip verwendet den gcc5.4, damit hättest du zumindestens C++11. Nur das du auf dem Laufenden bist. In paar Tagen-Wochen kommt gcc10 raus mit C++20 Unterstützung. Um welche µC handelt es sich denn? Danach richtet sich welche Toolchain du benötigst. Der Compiler hat erstmal nichts direkt mit der µC Unterstützung zu tun.
:
Bearbeitet durch User
Danish B. schrieb: > Unterstützen C++ Compiler für verschiedene µC-Architekturen mittlerweile > durchgängig C++11 bzw. C++14? Der Hype ist schon lange durch. Wenn du den krassen letzten Scheiß willst, übersetzt du deine C++20 library mit clang und llvm nach javascript/Webassembly und lässt das völlig cross-platform in nodejs auf deinem Controller laufen.
Danish B. schrieb: > Defacto wäre das dann ja die gesamte Sprachfunktionalität. Der C++ Compiler Compiler und die C++ Standard-Bibliothek sind allerdings zwei getrennte paar Schuhe.
Nur Anfänger proggen Mikrocontroller in C++ schrieb: > Der Hype ist schon lange durch. Wenn du den krassen letzten Scheiß > willst, übersetzt du deine C++20 library mit clang und llvm nach > javascript/Webassembly und lässt das völlig cross-platform in nodejs auf > deinem Controller laufen. Ich bin jetzt unsicher ob das ironisch gemeint war oder dein voller ernst. Tatsache ist, dass Menschen mit einer gewissen Reife von dieser Technologie ungefähr gar nichts halten. Es taugt bestenfalls als kurzzeitiges Forschungsobjekt.
Stefan ⛄ F. schrieb: > Ich bin jetzt unsicher ob das ironisch gemeint war oder dein voller > ernst. Ich bin jetzt sicher, dass mich deine Kommentare hier kein Stück interessieren. Tatsache ist, dass Menschen mit einer gewissen Reife von dir exakt gar nichts halten. Es wäre eine Bereicherung für 99,99% der Nutzer, wenn du dieses Forum verlässt. Du taugst bestenfalls als schlechtes Beispiel.
Ach.. "Ironie"? Nixda. Das ist einfach nur ein Terrorvogel, der im Grunde nix zum Thema sagen kann und dessen einziges Ziel, es ist, Zwietracht zu sähen, bzw. schlechte Stimmung zu verbreiten..
von Nur Anfänger proggen Mikrocontroller in C++ schrieb im Beitrag #6153235: > Tatsache ist, dass Menschen mit einer gewissen Reife von dir exakt gar > nichts halten. Es wäre eine Bereicherung für 99,99% der Nutzer, wenn du > dieses Forum verlässt. Interessante Fakten, die du da zu wissen glaubst. Nur entstammen sie Leider ausschließlich deiner unreifen Phantasie.
Danish B. schrieb: > Unterstützen C++ Compiler für verschiedene µC-Architekturen mittlerweile > durchgängig C++11 bzw. C++14? Weil die Antworten bisher alle irgendwie um den heissen Brei drumrum geredet haben, nochmal Klartext: Alle architekturspezifischen xxx-gcc -Versionen sind vollwertige gccs, und können alle das, was die jeweilige gcc-Version halt kann. Nutzt du einen anderen Compiler, dann musst du in dessen Doku nachlesen, was der unterstützt. Ob es dann für deinen speziellen Mikrocontroller eine C/C++-lib gibt, und was die dann unterstützt, musst du dann auch nachschauen. Oliver
Veit D. schrieb: > Um welche µC handelt es sich denn? Danach richtet sich welche Toolchain > du benötigst. Der Compiler hat erstmal nichts direkt mit der µC > Unterstützung zu tun. Ich hab keine konkreten µCs im Kopf. Es sollen "so viele wie möglich" unterstützt werden. Aber vermutlich wird es sich hauptsächlich um ARM handeln. Stefan ⛄ F. schrieb: > Danish B. schrieb: >> Defacto wäre das dann ja die gesamte Sprachfunktionalität. > > Der C++ Compiler Compiler und die C++ Standard-Bibliothek sind > allerdings zwei getrennte paar Schuhe. Oh. Das habe ich gar nicht bedacht :/. Oliver S. schrieb: > Alle architekturspezifischen xxx-gcc -Versionen sind vollwertige gccs, > und können alle das, was die jeweilige gcc-Version halt kann. Die sind aber nicht zwangsläufig auf aktuellem Stand (,oder?). Ich hab mal testweise diverse C++-Compiler im Compiler Explorer mit C++ 11 Code ausprobiert:
1 | void nothing() { volatile int *ptr = nullptr; }
|
Der MIPS-GCC ist der einzige Testkandidat der das nicht kompilieren kann. Erfolgreich sind: - ARM GCC - AVR GCC - RISC-V rv32gc clang - MSP430 GCC - und sicherlich noch einige mehr Im Wesentlichen wird der Misserfolg von MIPS GCC an der Version liegen (5.4). https://godbolt.org/z/jRZL6e
Danish B. schrieb: > Es sollen "so viele wie möglich" unterstützt werden. Das bedeutet zugleich: Maximal beschränkt und maximal teuer. Keine gute Idee. So "irgendwas" wie möglich ist nur gaaaaaanz selten vernünftig.
Danish B. schrieb: > Im Wesentlichen wird der Misserfolg von MIPS GCC an der Version liegen > (5.4). Oliver S. schrieb: > Alle architekturspezifischen xxx-gcc -Versionen sind vollwertige gccs, > und können alle das, was die jeweilige gcc-Version halt kann. Ein gcc 5.4 ist halt ein gcc 5.4 Klingt komisch, ist aber so. Es hindert dich aber niemand daran, dir selber einen MIPS gcc 9.2 oder auch jede andere Version zu bauen. Arduino Fanboy D. schrieb: > Oliver S. schrieb: >> alle > Das stimmt nicht. Beispiel? Oliver
Oliver S. schrieb: > Arduino Fanboy D. schrieb: >> Oliver S. schrieb: >>> alle >> Das stimmt nicht. > > Beispiel? Hier Beitrag "Re: C++ Compiler für µCs" habe ich verlinkt, welche Version was kann. Klarer gehts kaum! ------- Danish B. schrieb: > Ich hab mal testweise diverse C++-Compiler im Compiler Explorer mit C++ > 11 Code ausprobiert:void nothing() { volatile int *ptr = nullptr; } > > Der MIPS-GCC ist der einzige Testkandidat der das nicht kompilieren > kann. Kann ich nicht bestätigen.
Arduino Fanboy D. schrieb: > Hier Beitrag "Re: C++ Compiler für µCs" habe ich > verlinkt, welche Version was kann. Oh Mann.. Natürlich kann ein gcc 1.0 nicht das, was ein gcc 10.0 kann. Aber ein xxx-gcc in Version y.z kann alles, was jeder gcc der Version y.z kann, es ist halt einfach ein gcc der Version y.z Klingt einfach, ist auch so. Oliver
von Nur Anfänger proggen Mikrocontroller in C++ schrieb im Beitrag #6153235: > Tatsache ist, dass Menschen mit einer gewissen Reife von dir exakt gar > nichts halten. Es wäre eine Bereicherung für 99,99% der Nutzer, wenn du > dieses Forum verlässt. Achja, dann bin ich wohl bei den 0.1%, schön. > > Du taugst bestenfalls als schlechtes Beispiel. Dafür, dass dieser Typ eine Website mit kostenlosen PDFs unterhält ist das doch etwas übertrieben, er ist doch defacto einer der wenigen guten Beispiele in diesem Forum. Dieses Forum wird von 5-10 Leuten getragen (je nach Unterforum) Stefan gehört da zu 100% dazu.
Das war jetzt ein bisschen dick aufgetragen, aber ich fühle mich trotzdem geehrt. Vielen Dank.
>Dieses Forum wird von 5-10 Leuten getragen (je nach Unterforum) Stefan >gehört da zu 100% dazu. Das sehe ich auch so. Nur einen kleinen Hinweis an Dich, Stefan: Manchmal lässt Du Dich von anderen Bemerkungen hinreisen, die man freundlicher formulieren könnte. Ich denke, Du könntest Deine Anerkennung noch etwas erhöhen, wenn Du Dich nicht auf solche Sachen einlässt.
Markus schrieb: > Ich denke, Du könntest Deine Anerkennung noch etwas erhöhen, > wenn Du Dich nicht auf solche Sachen einlässt. Da hast du bestimmt Recht.
TR.OLL schrieb: > Sein wann gibt es C**? Wir könnten ja den Begriff C-- für die abgespeckte Variante verwenden, die wir auf kleinen µC verwenden.
Nein, weil das impliziert das C++ nicht für „kleine“ uC geeignet ist. Immer wieder das gleiche Vorurteil.
Johannes S. schrieb: > Nein, weil das impliziert das C++ nicht für „kleine“ uC geeignet > ist. Stimmt. Ich kann schließlich auch mit einem Bagger zum Brötchen kaufen fahren - wenn ich wirklich will.
Stefan ⛄ F. schrieb: > Johannes S. schrieb: >> Nein, weil das impliziert das C++ nicht für „kleine“ uC geeignet >> ist. > > Stimmt. Ich kann schließlich auch mit einem Bagger zum Brötchen kaufen > fahren - wenn ich wirklich will. Wenn der Bagger vergleichbar wäre, dann würde man nur die "Fahrfunktion" benutzen und die Schaufel einfach liegen lassen.
Carl D. schrieb: > Wenn der Bagger vergleichbar wäre, dann würde man nur die "Fahrfunktion" > benutzen und die Schaufel einfach liegen lassen. Genau so war es gemeint.
Zum Glück gibt es hier im Forum Leute von denen man wirklich viel zu C++ lernen kann. Für immer das gleiche Gewäsch lohnt es sich echt nicht mehr hier mitzulesen.
Stefan ⛄ F. schrieb: > TR.OLL schrieb: >> Sein wann gibt es C**? > > Wir könnten ja den Begriff C-- für die abgespeckte Variante verwenden, > die wir auf kleinen µC verwenden. Oder für eine schlechtere Variante von C++ z.B.: einen Kompromiss zwischen C und C++.
pumuggl schrieb: >> ist ja z.B. immer noch auf C89 Niveau. > > Wenn du deine grossartige Library nicht in C89 fassen kannst, > ist sie womoeglich gar nicht so grossartig und der Rest der > Welt kann gerne darauf verzichten. Man kann natürlich alles auch noch in antiken Sprachversionen verfassen. Allerdings dreht sich auch in der IT die Welt weiter, und man muss in der Regel nicht mehr auf einen vollkommen veralteten Standard setzen, der eigentlich vor über 20 Jahren bereits durch seinen Nachfolger ersetzt wurde. Es sei den eben, man ist gezwungen, einen Compiler zu verwenden, der sich seit den Neunzigern nicht weiterentwickelt hat. Oliver S. schrieb: > Alle architekturspezifischen xxx-gcc -Versionen sind vollwertige gccs, > und können alle das, was die jeweilige gcc-Version halt kann. Naja, die mitgelieferte libstdc++ und libsupc++ steht nicht auf allen Plattformen in gleichem Maße zur Verfügung. Beim AVR beispielsweise fehlt die komplette Standardbibliothek, und exception handling funktioniert auch nicht. Oliver S. schrieb: > Es hindert dich aber niemand daran, dir selber einen MIPS gcc 9.2 oder > auch jede andere Version zu bauen. Oder einfach einen zu installieren. Gibt's ja durchaus: https://packages.debian.org/sid/gcc-9-mips-linux-gnu TR.OLL schrieb: > Joghurtbecher mit Arsenfüllung schrieb: >> C** > > Sein wann gibt es C**? Ich vermute, er hat den Finger versehentlich auf der Shift-Taste gelassen. TR.OLL schrieb: > Oder für eine schlechtere Variante von C++ z.B.: einen Kompromiss > zwischen C und C++. Da wäre doch eher C+=0.5 passend. ;-) C-- wäre ja weniger als C.
Rolf M. schrieb: > Oliver S. schrieb: >> Alle architekturspezifischen xxx-gcc -Versionen sind vollwertige gccs, >> und können alle das, was die jeweilige gcc-Version halt kann. > > Naja, die mitgelieferte libstdc++ und libsupc++ steht nicht auf allen > Plattformen in gleichem Maße zur Verfügung. Beim AVR beispielsweise > fehlt die komplette Standardbibliothek, und exception handling > funktioniert auch nicht. Naja... Dass der Lieferumfang nicht der selbe ist, sollte doch schon klar geworden sein. Der Sprachumfang wird allerdings vom Kompiler abgedeckt, nicht von den Libs. Ein großer Teil der Libs benötigt die dynamische Speicherverwaltung. Das ist auf den kleinen 8Bittern recht unpraktikabel. Womit dann schon mal ein Grund für die Abwesenheit gefunden wäre. Auch Exceptions sind auf den 8Bittern eher eine Qual. Wobei ich mir recht sicher bin, dass man diese im Kompiler aktivieren kann, wenn man nur ernstlich will. ungetestet
Arduino Fanboy D. schrieb: > Rolf M. schrieb: >> Oliver S. schrieb: >>> Alle architekturspezifischen xxx-gcc -Versionen sind vollwertige gccs, >>> und können alle das, was die jeweilige gcc-Version halt kann. >> >> Naja, die mitgelieferte libstdc++ und libsupc++ steht nicht auf allen >> Plattformen in gleichem Maße zur Verfügung. Beim AVR beispielsweise >> fehlt die komplette Standardbibliothek, und exception handling >> funktioniert auch nicht. > > Naja... > > Dass der Lieferumfang nicht der selbe ist, sollte doch schon klar > geworden sein. Im obigen Zitat von Oliver S. steht aber genau das Gegenteil. > Der Sprachumfang wird allerdings vom Kompiler abgedeckt, nicht von den > Libs. Die Standardbibliothek ist Teil von C++. Und es gibt außerdem auch bestimmte Dinge im Sprachkern, die Bibliothekssupport benötigen, wie eben Exceptions. > Ein großer Teil der Libs benötigt die dynamische Speicherverwaltung. > Das ist auf den kleinen 8Bittern recht unpraktikabel. > Womit dann schon mal ein Grund für die Abwesenheit gefunden wäre. > > Auch Exceptions sind auf den 8Bittern eher eine Qual. Ich hab ja nicht behauptet, es gebe keinen Grund dafür. Nur dass es eben so ist und damit der Funktionsumfang einer spezifischen g++-Version doch nicht unbedingt wie oben behauptet auf allen Zielplattformen exakt gleich ist. > Wobei ich mir recht sicher bin, dass man diese im Kompiler aktivieren > kann, wenn man nur ernstlich will. > ungetestet Das Problem ist, dass Exception-Handling ohne Bibliothek (in dem Fall libsupc++) nicht funktioniert. Man kann sie im Compiler per -fexceptions aktivieren, aber wenn man eine Exception zu werfen versucht (egal von welchem Typ), bricht der Linker mit fehlenden Symbolen ab.
Rolf M. schrieb: > > Naja, die mitgelieferte libstdc++ und libsupc++ steht nicht auf allen > Plattformen in gleichem Maße zur Verfügung. Beim AVR beispielsweise > fehlt die komplette Standardbibliothek, und exception handling > funktioniert auch nicht. - Das ist aber kein Grund AVR8 oder andere uC nicht mit c++ zu programmieren. - grosse Teile von std:: existieren schon für AVR8 ... ... weil die "Diskussion" zu c++ hier im Forum regelmässig degeneriert, muss man die Quellen halt selber suchen. Stefan ⛄ F. schrieb: > Stimmt. Ich kann schließlich auch mit einem Bagger zum Brötchen kaufen > fahren - wenn ich wirklich will. ... weil die "Diskussion" zu c++ hier im Forum regelmässig degeneriert, schreibe ich hier auch nicht mehr gerne ...
A. B. schrieb: > - Das ist aber kein Grund AVR8 oder andere uC nicht mit c++ zu > programmieren. Auch das habe ich nicht behauptet! Ich habe lediglich der folgenden Aussage widersprochen, nicht mehr und nicht weniger: Oliver S. schrieb: > Alle architekturspezifischen xxx-gcc -Versionen sind vollwertige gccs, > und können alle das, was die jeweilige gcc-Version halt kann. Ich habe dafür den avr-gcc einfach nur als Beispiel genannt.
:
Bearbeitet durch User
Rolf M. schrieb: > Ich hab ja nicht behauptet, es gebe keinen Grund dafür. Nur dass es eben > so ist und damit der Funktionsumfang einer spezifischen g++-Version doch > nicht unbedingt wie oben behauptet auf allen Zielplattformen exakt > gleich ist. Dann bleibts dabei, auch wenn es dir nicht schmeckt: 1. Der Kompiler unterstützt es vollumfänglich 2. Die mitgelieferten Libraries leider nicht. A. B. schrieb: > weil die "Diskussion" zu c++ hier im Forum regelmässig degeneriert Ach, es gibt hier ein paar Priester der eigenen Geschmacksrichtung. Was ja eigentlich nicht schlecht ist. Allerdings neigen einige dazu andersartige Geschmacksrichtungen abzuwerten, zu verteufeln. Naja... Wenns der Erhöhung der eigenen Person dienlich ist, von mir aus... Aber nerven tuts schon. A. B. schrieb: > - Das ist aber kein Grund AVR8 oder andere uC nicht mit c++ zu > programmieren. Naja.. Wenn man denn templates und OOP nun gar nicht versteht und dagegen eine abgrundtiefe Abneigung entwickelt hat, dann ist das schon ein Grund auf C++ zu verzichten und stattdessen Basic, C, ASM oder was auch immer, zu verwenden. Aber sich deswegen zum Priester aufblasen zu wollen, ist doch irgendwie auch ziemlich Banane. Der Priester der Beschränktheit.
Arduino Fanboy D. schrieb: > Dann bleibts dabei, auch wenn es dir nicht schmeckt: > 1. Der Kompiler unterstützt es vollumfänglich > 2. Die mitgelieferten Libraries leider nicht. Das hat nichts mit "schmecken oder nicht schmecken" zu tun. Ich hab's jetzt bereits zweimal erklärt, wie meine Aussage zu verstehen ist, obwohl sie meiner Meinung nach auch so verständlich genug sein sollte. Wenn du es dann immer noch nicht verstehst, dann sei es eben so.
Rolf M. schrieb: > obwohl sie meiner Meinung nach auch so verständlich genug sein sollte. Du differenzierst nicht zwischen Kompiler und Libraries. Ich schon. Was mir den Startpunkt liefern kann, um den benötigten Kram nachzurüsten. Ohne den Kompiler zu modifizieren. Wer jetzt recht hat, mit seiner Sicht auf die Dinge, das Urteil, überlasse ich lieber anderen...
Arduino Fanboy D. schrieb: > Rolf M. schrieb: >> obwohl sie meiner Meinung nach auch so verständlich genug sein sollte. > Du differenzierst nicht zwischen Kompiler und Libraries. > > Ich schon. Ich beziehe mich auf das GCC-Paket, zu dem beides gehört. Das ist ganz einfach: Du installierst einen GCC für x86 und einen der gleichen Version für AVR, und du stellst fest, dass der Funktionsumfang nicht gleich ist. Schlussfolgerung: Die Aussage, dass er gleich sei, ist falsch. Und das war's dann schon. Mehr wollte ich gar nicht sagen. Ob das nun im Executable des Compilers selbst oder einer mitgelieferten Bibliothek begründet ist, spielt dafür keine Rolle. Und es sagt auch nichts darüber aus, wie einfach oder kompliziert man diese selbst nachbauen kann. Es ist außerdem weder als Wertung zu verstehen, ob man auf dem AVR C++ verwenden sollte, noch als Aussage darüber, wie sinnvoll oder wichtig diese Funktionalität ist. > Wer jetzt recht hat, mit seiner Sicht auf die Dinge, das Urteil, > überlasse ich lieber anderen... Du hast ja mit allem recht. Es geht aber an meiner Aussage vorbei.
Rolf M. schrieb: > Das ist ganz einfach: Du installierst einen GCC für x86 und einen der > gleichen Version für AVR, und du stellst fest, dass der Funktionsumfang > nicht gleich ist. Doch. Wenn du wirklich nur den GCC installierst, ist der Funktionsumfang gleich. Wenn du ein Paket aus GCC und Standard Library für x86 installierst, aber nur den GCC für AVR, ist der Umfang natürlich anders. Wenn du irgendwo eine stdlib für den AVR auftreibst und installierst, ist der Umfang gleich. Es ist halt nur so, dass Pakete für x86 oder ARM praktischerweise die stdlib mitliefern, aber das ist eben nicht mehr nur der GCC. Wenn du ein VW-Auto und einen Mercedes-Motor kaufst, sagst du ja auch nicht der Motor vom VW hat mehr Funktionsumfang; du hast nur mehr Drumherum zum Motor dazu erworben. Der GCC-ARM-Embedded unterstützt übrigens Exceptions; nur braucht die zugehörige Library so viel Flash und RAM dass das eher unpraktikabel ist. Es wäre eine interessante Aufgabe, da eine "Lite" Version für Embedded zu basteln. Vielleicht ohne Backtrace-Erzeugung.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.