Für die C++ Interessierten unter uns (C++ bei Flugge): http://bitbashing.io/embedded-cpp.html mfg Torsten
Ich finde den Artikel gut ... wenn auch nicht super neue Erkenntnisse. Allerdings vermisse ich die Entrüstungsstürme über C++ ;-) Stimmt, ist ja noch nicht Freitag!
Wie jetzt - die arbeiten mit GCC 6 für Cortex M4 im Firmenkontext? Der ist gerade erst im Dezember rausgekommen und hat noch nichtmal sein erstes Update bekommen, das ist erst gegen Ende dieses Quartals der Fall. Das ist.. mutig. Ich warte mit dem Update von 5.4 lieber noch bis 6/Q1.
Nop schrieb: > Wie jetzt - die arbeiten mit GCC 6 für Cortex M4 im Firmenkontext? Der > ist gerade erst im Dezember rausgekommen und hat noch nichtmal sein > erstes Update bekommen, das ist erst gegen Ende dieses Quartals der > Fall. Das ist.. mutig. Ich warte mit dem Update von 5.4 lieber noch bis > 6/Q1. Du meinst 6.3 ? M.E: kannst Du ruhig gleich auf 7.0.x gehen. Aber 6.3. reicht ja schon für concepts ... und das ist ja wieder für embedded sehr geeignet!
Wilhelm M. schrieb: > Allerdings vermisse ich die Entrüstungsstürme über C++ ;-) Es gibt vermutlich zwei Sorten von Leuten: die, die sich über allerlei Unzulänglichkeiten von C++ beschweren und argumentieren, warum man das insbesondere im Embedded-Bereich überhaupt nicht verwenden kann – und die, die es einfach benutzen. :-)
Jörg W. schrieb: > Wilhelm M. schrieb: >> Allerdings vermisse ich die Entrüstungsstürme über C++ ;-) > > Es gibt vermutlich zwei Sorten von Leuten: die, die sich über allerlei > Unzulänglichkeiten von C++ beschweren und argumentieren, warum man das > insbesondere im Embedded-Bereich überhaupt nicht verwenden kann – > und die, die es einfach benutzen. :-) Wohl wahr: obwohl es mir zugegebenermaßen oft in den Finger juckt, den Spieß umzudrehen ...
Merkwürdig finde ich ja deren Stack Canary. Der steht NACH dem char-Array, aber M4 hat einen descending stack. Selbst wenn der Compiler (was nicht garantiert ist!) die Stackvariablen in der Reihenfolge legt, in der sie deklariert werden, steht der Stack Canary physikalisch an einer niedrigeren Adresse als das char-Array. Mit anderen Worten: Wenn man char_array[-1] beschreibt, bemerkt der Kanarienvogel das wohl, aber üblicher ist doch, daß man über das Ende hinausschreibt, also char_array[10] überschreibt. Der Kanarienvogel müßte also VOR dem Array deklariert werden. Das hat nichtmal was mit C++ zu tun, aber ob das so die beste Idee ist, einem Team auch noch C++ zu geben, was schon mit hardwarenahem C seine Probleme hat, sei dahingestellt.
Der stack canary kommt vom Compiler, die lange Version von bar() ist eine besispielhafte Erklärung dafür, was der Compiler tut. Man darf davon ausgehen, dass der Compiler weiß, wie der Stack funktioniert, und so schlau ist, den Vogel an die richtige Position zu setzen. Das hat nichtmal was mit C zu tun, aber ob es sinnvoll ist, Artikel zu kommentieren, wenn man mit dem Lesen englischer Texte schon solche Probleme hat, sei dahingestellt.
Ausserdem sollte man rohe statische Arrays in C++ nicht mehr verwenden. In einem std::array<> o.d.gl. könnte man mit Zusicherungen arbeiten ...
Tom schrieb: > Das hat nichtmal was mit C zu tun, aber ob es sinnvoll ist, Artikel zu > kommentieren, wenn man mit dem Lesen englischer Texte schon solche > Probleme hat, sei dahingestellt. Und so ganz ohne Rumpöbeln geht es einfach nicht, oder? Wenn NOP ein Verständnis-Problem hat, dann hilf ihm doch einfach!
Tom schrieb: > eine besispielhafte Erklärung dafür Kay, das hatte ich zu wörtlich genommen. Eine andere Frage: wie ist denn das eigentlich mit diesem Mechanismus, der ist dann ja nicht mehr "in C(++)", sondern in irgendeiner Compiler-internen Zwischendarstellung, oder? Die Frage geht dahin, wie das mit Aliasing wäre, wenn das Array nicht gerade char wäre.
Wilhelm M. schrieb: > Du meinst 6.3 ? Naja ich meinte, daß das GCC-Binary für arm-eabi-none ja erst Ende Dezember zum Download auf die ARM-Webseite gestellt wurde. Klar steht da eine schon deutlich längere Historie des 6er dahinter, aber der breite Feldtest spezifisch für embedded wäre ja der praktische Masseneinsatz, oder nicht?
Nop schrieb: > Wilhelm M. schrieb: > >> Du meinst 6.3 ? > > Naja ich meinte, daß das GCC-Binary für arm-eabi-none ja erst Ende > Dezember zum Download auf die ARM-Webseite gestellt wurde. Klar steht da > eine schon deutlich längere Historie des 6er dahinter, aber der breite > Feldtest spezifisch für embedded wäre ja der praktische Masseneinsatz, > oder nicht? Aber ARM gehört doch zu den primären/sekundären Zielplattformen und wird daher immer unterstützt. Natürlich: je länger abgehangen, desto besser. Man muss halt immer einen gangbaren Kompromiss finden. Aber gerade bei g++-7 haben wir ja z.B. constexpr-lambdas bekommen, was wieder eine ganz tolle Sache ist.
Torsten R. schrieb: > Und so ganz ohne Rumpöbeln geht es einfach nicht, oder? Wenn NOP ein > Verständnis-Problem hat, dann hilf ihm doch einfach! Nee, da muß ich Tom in Schutz nehmen (sofern erlaubt); ich habe damit angefangen, aber das nichtmal kompetent, und insofern war die Retoure völlig angemessen.
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.