Mit dem Wechsel von Debian 11 auf Debian 12 wurde auch der gcc für ARM aktualisiert (jetzt arm-none-eabi-gcc (15:12.2.rel1-1) 12.2.1 20221205).
Leider liefen damit einige meiner Projekte nicht mehr. Also hab ich die Ursache eingegrenzt und bin auf eine Optimierung gestoßen, die dafür sorgt, dass meine eigene strlen Implementierung mit der Optimierung von Os durch eine Endlosschleife ersetzt wird:
Aus
1
size_tstrlen(constchar*text){
2
size_tlen=0;
3
while(*text){
4
text++;
5
len++;
6
}
7
returnlen;
8
}
wird mit -Os:
1
strlen:
2
b strlen
Benenne ich meine Funktion um, so wird daraus ebenfalls b strlen.
Der Compiler erkennt also dass meine Implementierung das selbe liefert wie strlen und will meine Funktion durch einen Aufruf der Standardlib ersetzen. Wie schalte ich das ab? Die Makefile fürs Beispiel habe ich angehängt. Mit O1 sieht der generierte Code gut aus. Mit O2 wird ein rekursiver Aufruf mit fehlerhaften Rückgabewert draus.
Bevor jetzt jemand fragt warum ich die Standard strlen Funktion ersetze: Meine Implementierung ist zwar nicht unbedingt schneller, aber deutlich Programmspeicher sparender als die strlen der newlib (28byte vs 220byte).
Mein Vertrauen in den GCC und die Maintainer ist schon lange gestoert.
Ein AVR-GCC verweigerte, ohne weitere Fehlermeldung die Compileroption -Os.
Nach vielem Suchen stellte sich heraus, dass dieser Teil eine bessere
CPU im Host erwartete...
Eine Qualitaetskontrolle hat da sicher nicht stattgefunden.
GCC scheint halt "Bastlersoftware" zu sein.
Oder das fuer eine Compilerversion X valider Code, in der Compilerversion
X+1, sich nur noch als "grosser Haufen von Fehlern" praesentiert.
Und man bevor man weitere Zeit verschendet, die Distribution mit
Version X in einen Virtualisierer installiert, und das was man braucht
dann dort kompilieren muss?
Fuer ARM gibt es, Gott sei es gedankt, ja genug kommerzielle Alternativen.
Schiebe die Funktion in ein eigenes C-File und kompilier es mit -ffreestanding. Dann weis GCC, das er für die Datei keine libc vorrausetzen darf und lässt diese Optimierung weg.
Ggf. funktioniert auch -fno-builtin-strlen in deinem Fall.
Aus
size_t strlen(const char * text) {
size_t len = 0;
while(*text) {
text++;
len++;
}
return len;
}
wird mit -Os:strlen:
b strlen
Benenne ich meine Funktion um, so wird daraus ebenfalls b strlen.
Der Compiler erkennt also dass meine Implementierung das selbe liefert
wie strlen und will meine Funktion durch einen Aufruf der Standardlib
ersetzen.
Rein nach C-Standard ist das korrekt. Das definieren eigener Funktionen, deren Name mit str gefolgt von einem Kleinbuchstaben beginnt, führt bei einer "hosted"-Impelementation zu undefiniertem Verhalten.
Wie schalte ich das ab?
Mit -ffreestanding. Das gilt dann aber für alle Standard-Funktionen.
Bevor jetzt jemand fragt warum ich die Standard strlen Funktion ersetze:
Meine Implementierung ist zwar nicht unbedingt schneller, aber deutlich
Programmspeicher sparender als die strlen der newlib (28byte vs
220byte).
Wenn du strlen aufrufst, nutzt er dann überhaupt die Implementation der newlib? Solche Funktionen sind bei gcc normalerweise bereits im Compiler selbst umgesetzt. Das hätte ich gerade bei so einer einfachen Funktion wie strlen erwartet.
Oder das fuer eine Compilerversion X valider Code, in der
Compilerversion X+1, sich nur noch als "grosser Haufen von Fehlern"
praesentiert.
Oft ist der Code nicht valide, sondern der Fehler ist nur nicht aufgefallen. Viele Fehler im Code fallen einem erst bei Optimierungen auf die Füße. Neue Optimierungen führen daher dazu, dass diese Fehler erst in einer neueren Compiler-Version auffallen. Der Fehler liegt dann aber trotzdem im Code und nicht im Compiler.
Schiebe die Funktion in ein eigenes C-File und kompilier es mit
-ffreestanding.
Danke, damit sieht der Code so aus wie er soll :) Und mit 14 byte dürfte es kürzer nicht gehen.
Ggf. funktioniert auch -fno-builtin-strlen in deinem Fall.
Nein, der erzeugt den selben Code. Ist ja auch zu erwarten. Bei nicht-buildin soll er ja die Lib aufrufen, statt gegebenenfalls inline Code einzufügen.
Ein AVR-GCC verweigerte, ohne weitere Fehlermeldung die Compileroption
-Os.
Hmm, ja es dürfte einen Grund haben warum Debian für den AVR weiterhin gcc version 5 ausliefert.
Mein Vertrauen in den GCC und die Maintainer ist schon lange gestoert.
In einer älteren gcc version (mit ARM) war mir mal aufgefallen, dass bei einer Funktion, die ein float zurück gibt und wo das return vergessen wurde der program counter einfach in die nächste Funktion reinläuft, weil auch kein Funktionsreturn generiert wird. Das scheint aber in der aktuellen Version inzwischen behoben zu sein.
Wirklich gruselig finde ich eher die newlib für ARM. Erst dadurch habe ich zu schätzen gelernt wie gut und kompakt die avr-libc geschrieben ist.
Wenn du strlen aufrufst, nutzt er dann überhaupt die Implementation der
newlib? Solche Funktionen sind bei gcc normalerweise bereits im Compiler
selbst umgesetzt. Das hätte ich gerade bei so einer einfachen Funktion
wie strlen erwartet.
Jup, tut er. Egal welche Optimierung ich wähle, es gibt immer ein bl strlen wenn ich strlen aufrufe (deswegen hab ich die ja auch in der Map Datei gefunden und durch meine kurze Implementierung ersetzt).
Das macht ja auch Sinn. Bei -Os dürfte Platz gespart werden werden wenn strlen mehr als 1x im Programm verwendet wird. Bei -O3 könnte die Implementierung für lange strings schneller sein, wenn dann auf einem 32Bitter immer 4 Byte auf einmal gelesen und verglichen werden (erfordert natürlich mehr Code).
Selber mit den passen Optionen compilieren, und alles wird gut. Wenn du
Linux nutzt, gehört das zum Spiel.
Das habe ich vor einiger Zeit tatsaechlich mal wieder probiert.
Von frueher™ kenne ich noch selbst das "Bootstrapping" fuer eine
neue Version. Das ist mir auch immer als recht problemlos in
eigener Erinnerung.
Diesmal sollte es aber der RISCV-GCC fuer den Test eines Softcore werden.
Da braucht der Source dann noch droellfzig Patche.
Als Linux haette ein Oracle Linux bereitgestanden.
Einige Stunden spaeter:
Schlussendlich habe ich das "Selberbauen" dann gelassen, und mein
recht kurzes Testprogramm mit dem IAR-Compiler kompiliert. :)
Das dann erwartungsgemaess auch funktionierte.
Schlussendlich habe ich das "Selberbauen" dann gelassen, und mein
recht kurzes Testprogramm mit dem IAR-Compiler kompiliert. :)
Das dann erwartungsgemaess auch funktionierte.
Beim 'Versuch' ein IAR-Projekt auf Segger ES (GCC) umzustellen, mache ich leider gerade eine ähnliche Erfahrung. Beim RP2040 soll auf das Ende einer DMA-Übertragung gewartet werden, was bei IAR problemlos läuft und im Fehlerfall einfach zu debuggen wäre.
Eigentlich ganz simpel:
aber es wird nicht beachtet. Erst eine zusätzliche Warteschleife wirkt als notwendige Bremse.
Insofern fand ich die hiesigen Beiträge sehr interessant, daß ich da nicht ganz alleine bin.
Irgendwann werde ich weiter 'forschen', trete das Zeug aber zunächst in die Tonne. Macht absolut keinen Spaß!
Selber mit den passen Optionen compilieren, und alles wird gut. Wenn du
Linux nutzt, gehört das zum Spiel
Das ist doch wohl eine Selbstverstaendlichkeit. Ich hab alle meins Crosscompiler selber uebersetzt. Ich will doch schliesslich auch alle meine Cores auf demselben Revisionslevel haben.
Also manchmal denke ich der durchnittliche Linuxuser wird immer bloeder.
Bei solchen einfachen Fällen lohnt sich meist ein Blick in den generierten Assembler um zu erkennen ob es ein Compiler (falscher Assembler) oder Hardware Problem (korrekter Assembler) ist.
Das ist aber nicht der Code aus dem Beispiel, das du angehangen hast.
Der wäre
Ja sorry. Ich hatte in dem kurzen Beispiel zunächst strlen stehen. Und dachte mir das kann einfach nicht sein, dass der gcc an so einer simplen Funktion scheitert. Also war mir kurz vor dem Abschicken noch die Idee gekommen diese umzubenennen. Das hat mich dann auf die Spur mit dem ersetzen des Musters durch strlen gebracht.
Selber mit den passen Optionen compilieren, und alles wird gut. Wenn du
Linux nutzt, gehört das zum Spiel.
Das ist bei machen Softwarepaketen aber alles andere als einfach. https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads -> arm-gnu-toolchain-src-snapshot-13.2.rel1.tar.xz -> Entpackt 289065 Dateien. Vor Jahren hatte ich mal eine Anleitung gefunden wie es dann weiter geht. Aber aktuell finde ich nichts. Ist echt gruselig.
Von daher bin ich glücklich dass die Distri Maintainer mir diese Arbeit abnehmen. Dass es dabei einen Zielkonflikt gibt "läufts auf einem Cortex-M0, M4 oder M7 und möchte der Nutzer kleinen oder schnellen Code" ist mir bewusst. Die Newlib in Debian ist definitiv für "so schnell wie möglich auf einem M7" übersetzt, wenn man sich das Disassembly anschaut.
Das ist bei machen Softwarepaketen aber alles andere als einfach
Korrekt. Daher habe ich mich oben auch zu einem Smiley hinreissen lassen. In den 90ern war auch fuer Anfaenger vollkommen normal und schaffbar Software von Source zu installieren. Mittlerweile hat es aber eine Level erreicht wo schon jeden Tag 8h beruflich so was treiben muss. Ich mach das jetzt seit 30jahren und komme gelegentlich an Grenzen wo ich aufgebe.
Wieso? Weil jeder Programierer sein Waesche nur noch gewaschen bekommt in dem er hunderte vom Libaries nutzt die natuerlich in der richtigen version vorliegen muessen und Abhaengigkeiten zum Systen habe. Das ganze natuerlich Distributionsabhaengig und gerne mit den unterschiedlichsten build-tools.
Beim Gcc darf man noch vermuten das Programmier die Spass dran haben den neusten Spielkram einer Sprache einzubauen natuerlich den Kram vom letzen Jahr nutzen. Da sollte man selber nicht mit einem Compiler vom vorletzten Jahr ankommen.
Es wundert mich wie lange das noch beherschbar bleibt. Irgendwann bekommen die alten Knacker das nicht mehr gebacken und der Nachwuchs schafft es nicht mehr einzusteigen.
Und schuld ist das Unfaehigkeitstheorem der Informatik. Ein Programierer ist grundsaetzich nicht in der Lage ein Projekt abzuschliessen und als fertig zu erklaeren.
Stellt euch mal vor Ikea kommt an und will am vor einem Jahr gekauften Stuhl ein Bein verlaenger und in einer neuen Farbe streiche und eine geaenderte sitzhoehe ist auch kein Problem weil ihr euch ja einen neuen Tisch kaufen koennt.
Programmierer bemerken ihre Fehle(=Feature) nicht sonder machem aus ihre Unfaehigkeit ein Geschaeftsmodel. (software nur noch im Abo)
Programmierer bemerken ihre Fehle(=Feature) nicht sonder machem aus ihre
Unfaehigkeit ein Geschaeftsmodel. (software nur noch im Abo)
Das sind nicht Programmierer, das ist das Management und das Marketing. Da der "dernier cri" der Softwareeentwicklung nun mal CI/CD ist, /muss/ ständig neue Software produziert werden, immer wieder, ständig neu. Egal, ob es tatsächlich nötig ist, man kann sich immer damit rausreden, daß irgendeine Abhängigkeit (die x-te Library, die wegen irgendeines längst vergessenen Features "gezogen" wird) das so nötig macht.
Und offenbar ist schon wieder vergessen worden, was das blinde Verlassen auf irgendwelche Libraries und deren Abhängigkeiten zur Folge haben kann - lib4j, erinnert sich noch jemand daran? Ich hab' vor ein paar Jahren mal ein so strukturiertes Projekt genauer untersucht (das war irgendwas, was SVG renderte), darin steckten gleich drei konkurrierende XML-Parser. Mit ihrem jeweiligen Rattenschwanz an Abhängigkeiten, natürlich.
Gäbe man Softwareenwicklern oder Programmierern etwas mehr Zeit, könnten sie sich, statt für jeden Furz /irgendwas/ von irgendwem irgendwo geschriebenes zu "ziehen", sich intensiver damit beschäftigen, was sie eigentlich erreichen wollen, und erkennen, daß a) sie oft den fremden Code gar nicht benötigen, weil das Problem auch anders lösbar ist oder b) sie den fremden Code auch mit einer halben Stunde Eigenleistung ersetzen könnten, nur daß die dann nicht noch drölfzig Abhängigkeiten hat.
Aber dazu müssten die Jungs halt nicht nur hippe Architekturkonzepte mit bunten Namen kennen, sondern sich mit Grundlagen beschäftigen. Ich habe mal einen Java-Programmierer dabei erlebt, wie er in einem 32-Bit-Wert nach gesetzten Bits suchte. Nein, er nutzte keinen Schiebeoberator, sondern die Funktion pow(). Macht ja nichts, PCs haben ja fett Rechenleistung.
void DMA11_transfer_abwarten(void)
{
while(DMA->CH11_CTRL_TRIG & DMA_CH11_CTRL_TRIG_BUSY_Msk);
}
aber es wird nicht beachtet. Erst eine zusätzliche Warteschleife wirkt
als notwendige Bremse.
Das optimiert der gcc weg weil sich die Bedingung im while Block nicht ändert. Die DMA struct oder den Member volatile deklarieren und es wird funktionieren. Sowas ist doch kein Fehler.
Über den IAR und die Tools haben hier auch schon einige fürchterlich geschimpft, die kochen auch nur mit Wasser. Und auch Keil, kennt der mittlerweile aligned_alloc()? Ist ja erst neu im Standard seit C11.
Bei gcc gibt es ein altes issue das die Optimierung für M0 schlecht ist, ich weiß nicht ob das schon besser geworden ist. Für M0 hatte der Keil mal deutlich kürzeren Code erzeugt, das lag aber auch an der schlechteren LTO, die bei gcc mittlerweile auch deutlich besser funktioniert.
Und wo braucht die newlib mehr Code für das strlen? Newlib ist reentrant, das ist mir mehr Wert als ein paar gesparte Byte. Für MCU mit weniger Speicher gibt es ja noch die Newlib nano die für strlen evtl. auch weniger braucht.
Was allerdings weder aus dem Namen der Option hervorgeht noch aus ihrer Dokumentation.
-ffreestanding will man eigentlich nicht verwenden, auch nicht auf bare-metal. Zum Beispiel wird dann strlen("Hallo") nicht mehr zu 5 optimiert, sondern die Länge des bekannten Strings wird zur Laufzeit berechnet.
-fno-builtin-strlen wiederum bewirkt, dass explizte Aufrufe von strlen immer zu einem Aufruf von strlen führen. Ist also auch nicht, was man braucht; erklärt aber, warum diese Option nicht wirkt — warum -fno-builtin wirkt ist dann wieder schleierhaft...
Bevor jetzt jemand fragt warum ich die Standard strlen Funktion ersetze:
Meine Implementierung ist zwar nicht unbedingt schneller, aber deutlich
Programmspeicher sparender als die strlen der newlib (28byte vs
220byte).
Newlib implementiert eine Speed-optimierte Version von strlen. Zuerst wird bis zu einem bestimmten Alignment byteweise untersucht, danach geht's dann in Word-Happen weiter, zumindest für ARM v7:
Dein Problem ist also, dass -Os keine Multilib-Option ist, und man für kleinen Code die Newlib mit speziellen Optionen generieren muss wie -Os bzw. -D PREFER_SIZE_OVER_SPEED.
Wenn du die Newlib selbst generiert hast, dann liegt da der Hase im Pfeffer. Bzw. beim Distributor, der wenn es wirklich auf die paar Bytes ankommt (tut es das überhaupt?) die Newlib mit entsprechenden Optionen generiert haben sollte.
Dann gibt es diese Implementierung, die je nach Gegebenheit die o.g. includiert bzw. was eigenes macht:
Das optimiert der gcc weg weil sich die Bedingung im while Block nicht
ändert. Die DMA struct oder den Member volatile deklarieren und es wird
funktionieren. Sowas ist doch kein Fehler.
Nicht wegoptimiert, sondern sogar doppelt vorhanden, wobei jeder Aufruf noch einmal inline und etwas anders nachgebildet wird. Einmal wird auf Bit24 getestet und einandermal 7 x nach links geschoben und auf negativ getestet.
Egal, ich bekomme das in den Griff.
Das optimiert der gcc weg weil sich die Bedingung im while Block nicht
ändert. Die DMA struct oder den Member volatile deklarieren und es wird
funktionieren. Sowas ist doch kein Fehler.
Das DMA-Struct stammt aus den vom Hersteller für den Prozessor bereitgestellten Headern. Wenn das nicht volatile definiert sein sollte, wäre das ein signifikanter Fehler da drin. Das sollte aber nicht der Fall sein.
