Die diesjährige GCC Release v15 ist raus:
https://gcc.gnu.org/gcc-15/changes.html
Per Default wird C als C23 übersetzt. Ein paar Neuerungen:
* constexpr für Objekte. Kann z.B. für Array-Größe verwendet werden.
* Direktive #embed, mit der man Binärdateien ins Programm einfügen kann.
Das ging bislang schon, war aber z.T. umständliches Binutils Gebastel.
Beispiel mit #embed:
1
#include<stdio.h>
2
#include<avr/pgmspace.h>
3
4
staticconstcharfoo_c[]PROGMEM=
5
{
6
#embed "foo.c"
7
// Append \0 so that foo_c becomes a proper C string
8
// (assuming foo.c is a text file).
9
,'\0'
10
};
11
12
intmain()
13
{
14
printf("== foo.c has %d bytes ==\n%S\n",
15
(int)sizeof(foo_c)-1,foo_c);
16
}
* bool, true und false sind Schlüsselworte. stdbool.h wird nicht mehr
gebraucht, funktioniert aber weiterhin.
* Globale asm Statements können Argumente haben.
* In Prototypen wie "int func()" ist "()" gleichbedeutend mit "(void)".
* Case Ranges (-std=c2y)
* if Deklarationen so wie in for (-std=c2y)
* Implizite Oktal-Literals sind abgeschafft. Wer wirklich 12 oktal will
schreibt also nicht mehr 012 sondern 0o12.
Auch für AVR gibt es ein paar Neuerungen:
https://gcc.gnu.org/gcc-15/changes.html#avr
* Attribute signal(num) wo num die IRQ-Nummer ist. Damit kann man
static Funktionen als ISR verwenden und auch Funktionen aus einem C++
Namespace. AVR-LibC v2.3 uterstützt das als ISR_N(num). Beispiel:
1
#include<avr/io.h>
2
3
__attribute__((signal(ADC_vect_num)))
4
staticvoidadc_isr(void)
5
{
6
// Code
7
}
8
9
#include<avr/interrupt.h>
10
11
ISR_N(INT0_vect_num)// ab AVR-LibC v2.3
12
staticvoidint0_isr(void)
13
{
14
// Code
15
}
* Unterstützung von Compact Vector Table (CVT). Auch dies erfordert
AVR-LibC v2.3.
AVR-LibC v2.3 ist noch nicht released.
News: https://github.com/avrdudes/avr-libc/blob/main/NEWS.md
(Links auf neue Header sind 404 weil die aktuelle Doku noch für v2.2
ist.)
Johann L. schrieb:> #embed "foo.c"> // Append \0 so that foo_c becomes a proper C string> // (assuming foo.c is a text file).> , '\0'> };
Und was mache ich, wenn ich keine extra \0 haben will, was bei
Binärdateien der Normalfall ist? Denn dadurch ändert sich ja die
Objektgröße.
Falk B. schrieb:> Und was mache ich, wenn ich keine extra \0 haben will, was bei> Binärdateien der Normalfall ist?
Meinst Du die Frage ernst?
Johann L. schrieb:> , '\0'
Falk B. schrieb:> Und was mache ich, wenn ich keine extra \0 haben will, was bei> Binärdateien der Normalfall ist?
Ich haette dann einfach die Zeile 9 weggelassen. Aber ich hab's nicht
ausprobiert.
Gruss
WK
Johann L. schrieb:> * Implizite Oktal-Literals sind abgeschafft. Wer wirklich 12 oktal will> schreibt also nicht mehr 012 sondern 0o12.
Vielen Dank für die Warnung. Wer war das? 0.2% meiner Quelltextzeilen
müssen geändert werden, muss das sein? Brauchen die alle kein chmod(),
open(), creat()... oder ANSI-Escapes? Funktioniert denn jetzt zum
Ausgleich wenigstens '\e' statt '033'?
Kennt der gcc 13 oder 14 diese Konstruktion schon?
Bauform B. schrieb:> Vielen Dank für die Warnung. Wer war das? 0.2% meiner Quelltextzeilen> müssen geändert werden, muss das
Du musst ja alte Quelltexte nicht mit C23 übersetzen. Wenn doch, muss es
halt C23 sein. Für den Sprachstandard kann der Compiler nichts.
Oliver
Bauform B. schrieb:> Johann L. schrieb:>> * Implizite Oktal-Literals sind abgeschafft. Wer wirklich 12 oktal will>> schreibt also nicht mehr 012 sondern 0o12.>> Vielen Dank für die Warnung. Wer war das?
WG14 Vorschlag N3193 "Obsolete implicitly octal literals" ist zum
Beispiel hier zu finden:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3193.htm>> The use of base-8 instead of base-10 by integer literals that begin>> with a zero digit is the source of frequent confusion. We propose>> marking the use of such literals as obsolete in order to encourage>> a warning that will prompt rewrites, and the introduction of a new>> prefix to explicitly mark literals that are genuinely intended to>> be in base-8.
und:
>> We propose that a new syntax is added for explicit octal constants,>> with a new prefix 0o or an alternative spelling to mark the beginning>> of a base-8 literal. The old syntax should be retained and marked as>> obsolescent to avoid breaking the meaning of existing code.
Wie es aussieht wird es eine neue Diagnostic geben, die auch deaktiviert
werden kann wenn man die alte Syntax wirklich haben will (ähnlich zu
Trigraphen).
> Kennt der gcc 13 oder 14 diese Konstruktion schon?
Das hängt weniger am Compiler als an der C-Version, welche noch nicht
released ist. C2y wird wohl C26 oder C27 werden. In C23 ist es als
Erweiterung drin, aber erst ab GCC v15:
Johann L. schrieb:> * Implizite Oktal-Literals sind abgeschafft. Wer wirklich 12 oktal will> schreibt also nicht mehr 012 sondern 0o12.
Die Änderung bezüglich der oktalen integer literals ist in C2y, nicht
C23. Und auch in C2y ist die Variante mit führender 0 nicht
"abgeschafft", sondern nur "obsolete".
Hmmm schrieb:>> Und was mache ich, wenn ich keine extra \0 haben will, was bei>> Binärdateien der Normalfall ist?>> Meinst Du die Frage ernst?>> Johann L. schrieb:>> , '\0'
Ach ich Depp, ich hab's falsch verstanden! War zu warm heute!
Johann L. schrieb:> Die diesjährige GCC Release v15 ist raus:> https://gcc.gnu.org/gcc-15/changes.html
Vielen Dank!
Habe gerade paar meiner Projekte damit und aktueller avr-libc (git)
durchgebaut. Generierter code scheint, bei mir, mit dem gcc-15.1
deutlich kleiner zu sein als gcc-14.2. An gcc-13.1 kommt er allerdings
nicht heran.
Trotzdem, vielen Dank noch mal fuer den unglaublichen Einsatz!
Wie wird uebrigens das hier funktionieren:
> * Unterstützung von Compact Vector Table (CVT). Auch dies erfordert> AVR-LibC v2.3.
In den neuen gcc/ld manpages habe ich nichts dazu gefunden. Wird es
automatisch passieren, oder wird man sich dazu linker-command-files
selber stricken muessen?
-Foka
Foka M. schrieb:> Generierter code scheint, bei mir, mit dem gcc-15.1 deutlich kleiner> zu sein als gcc-14.2. An gcc-13.1 kommt er allerdings nicht heran.
Da wäre interessant zu sehen, wo es da hakt (also Testfall, Optionen
etc.)
> Wie wird uebrigens das hier funktionieren:>> * Unterstützung von Compact Vector Table (CVT). Auch dies erfordert>> AVR-LibC v2.3.> In den neuen gcc/ld manpages habe ich nichts dazu gefunden.https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/AVR-Options.html#index-mcvt
Linker und Linkerscript sind unverändert.
1) libc configure stellt fest, welche Devices CVT können.
2) Für entsprechende Devices gibt es eine neue Build-Variante
crt<mcu>-cvt.o des Startup-Codes, der ja die Vectab mitbringt.
3) Welcher Startup-Code gelinkt wird entscheidet der Compiler anhand von
-mcvt: crt<mcu>.o oder crt<mcu>-cvt.o.
4) crt<mcu>-cvt.o referenziert Code, der CVT aktiviert (in .init3). Man
braucht CVT also nicht händisch zu aktivieren.
https://github.com/avrdudes/avr-libc/blob/main/libc/misc/init_cvt.S
Falls man CVT selbst aktivieren möchte, dann definiert man Symbol
__init_cvt so dass der Code nicht mehr aus der Devicelib gezogen wird.
crt<mcu>-cvt.o kann man natürlich auch mit älteren GCC Versionen
verwenden, hat dann aber nicht den Comfort von -mcvt.
Johann L. schrieb:> Foka M. schrieb:>> Generierter code scheint, bei mir, mit dem gcc-15.1 deutlich kleiner>> zu sein als gcc-14.2. An gcc-13.1 kommt er allerdings nicht heran.>> Da wäre interessant zu sehen, wo es da hakt (also Testfall, Optionen> etc.)
Ich versuche mal am kommenden langen WoE etwas mehr Inhalte zusammen zu
bekommen.
Compiler wird aufgerufen mit (nur ein Beispiel):
Ich mache vorwiegend C++ und bin gerade auf C++20 festgenagelt. Die
Unterschiede koennten also auch hieraus entstehen. Auch wenn der gcc-13
schon so ziemlich "feature complete" gewesen ist.
>> Wie wird uebrigens das hier funktionieren:>>> * Unterstützung von Compact Vector Table (CVT). Auch dies erfordert>>> AVR-LibC v2.3.>> In den neuen gcc/ld manpages habe ich nichts dazu gefunden.>> https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/AVR-Options.html#index-mcvt>
Oh, richtig. Habe ich in der manpage echt uebersehen.
Danke fuer die Erklaerung. Das WoE wird echt zu kurz ;-)
-Foka
Mit LTO genügt zum Nachvollziehen nicht mehr das Präcompilat eines
Moduls (z.B. mit -save-temps), weil *.o nur LTO-Bytecode enthält.
(-ffat-lto-objects hilft auch nix, weil nicht-LTO Code zur lto Time
verworfen wird).
Mit LTO braucht man also (die Präcompilate) alle(r) Module, um was
nachzuvollziehen. Evtl lässt sich mit -fno-lto eingrenzen, wo der
Codezuwachs herhommt. Wenn er nur mit -flto passiert ist es ein Indiz
dafür, dass sich was beim IPA geändert hat (Inlining, Cloning,
LTO-Partitioning, etc.).
>> Mit LTO genügt zum Nachvollziehen nicht mehr das Präcompilat eines> Moduls (z.B. mit -save-temps), weil *.o nur LTO-Bytecode enthält.> (-ffat-lto-objects hilft auch nix, weil nicht-LTO Code zur lto Time> verworfen wird).
Ich habe jetzt das gleiche ohne lto gemacht.
Geiches Projekt, gleiche compile optionen, in beiden Faellen ohne lto.
gcc-13.1:
1
Sections:
2
Idx Name Size VMA LMA File off Algn
3
0 .data 00000050 00800100 00001b0c 00001bc0 2**0
4
CONTENTS, ALLOC, LOAD, READONLY, DATA
5
1 .text 00001b0c 00000000 00000000 000000b4 2**1
6
CONTENTS, ALLOC, LOAD, READONLY, CODE
7
2 .bss 00000091 00800150 00800150 00001c10 2**0
gcc-15.1:
1
Sections:
2
Idx Name Size VMA LMA File off Algn
3
0 .data 00000050 00800100 00001b7e 00001c32 2**0
4
CONTENTS, ALLOC, LOAD, READONLY, DATA
5
1 .text 00001b7e 00000000 00000000 000000b4 2**1
6
CONTENTS, ALLOC, LOAD, READONLY, CODE
7
2 .bss 00000091 00800150 00800150 00001c82 2**0
Das sind, bei ca. 7kB in .text, 114Byte Unterschied zu Gunsten des
gcc-13.1.
Wie gesagt, ich werde mir am WoE die einzelnen Objekte ansehen, und
melde mich wieder falls ich etwas greifbareres habe.
-Foka
Johann L. schrieb:> * Implizite Oktal-Literals sind abgeschafft. Wer wirklich 12 oktal will> schreibt also nicht mehr 012 sondern 0o12.
Hmm, dann kann man jetzt endlich die 0 in dezimal schreiben. 😀
Rolf M. schrieb:> Johann L. schrieb:>> Wer wirklich 12 oktal will schreibt also nicht mehr 012 sondern 0o12.>> Hmm, dann kann man jetzt endlich die 0 in dezimal schreiben. 😀
Nicht mal das. N3193:
>> Zero remains a traditional octal constant
Da oktal in MISRA absolut verboten ist, darf man also immer noch nicht
"x = 0;" schreiben sondern muss weiterhin "x = 1-1;" o.ä.
Johann L. schrieb:> Da oktal in MISRA absolut verboten ist, darf man also immer noch nicht> "x = 0;" schreiben
Prust! Aber man kann jetzt immerhin "x = 0815;" schreiben. :-)
>>>> Mit LTO genügt zum Nachvollziehen nicht mehr das Präcompilat eines>> Moduls (z.B. mit -save-temps), weil *.o nur LTO-Bytecode enthält.>> (-ffat-lto-objects hilft auch nix, weil nicht-LTO Code zur lto Time>> verworfen wird).>> Wie gesagt, ich werde mir am WoE die einzelnen Objekte ansehen, und> melde mich wieder falls ich etwas greifbareres habe.>
Ich habe jetzt mal paar Codestellen die gcc-15.1 dicker macht genauer
angesehen. Zum einen muss ich zu geben, dass ich die gcc-13.1 und 15.1
tool-chains mit verschiedenen avr-libc Versionen gebaut habe.
Dummerweise beide direkt auf dem, damaligen, git-master basierend. Dh.
um wirklich fundierte Vergleiche zu bekommen muesste ich beide compiler
mit der gleichen avr-libc verwenden.
Mir fiel jedoch auf, dass der gcc-15.1 sich mehr um den stack pointer
'kuemmert' und dazu neigt prologue/epilogue fetter zu machen. Hier mal
eine kleine Funktion die zwei bytes auf SPI schreibt. Eigentlich sollte
es nur CS-ziehen, zwei mal `txRaw` (schreibt einen byte und wartet auf
fertig) aufrufen und dann wieder CS los lassen.
Beim gcc-13.1 sieht es so aus ('//' sind meine kommentare):
In `.Loc.16` ist eine sub-routine die den SREG rettet, interrupts
stoppt, stack pointer runter schiebt, und dann den SREG wieder zurueck
holt (gcc-15.1):
1
00001ad0 <.Loc.16>:
2
1ad0: aa 81 ldd r26, Y+2 ; 0x02
3
1ad2: b9 81 ldd r27, Y+1 ; 0x01
4
1ad4: ce 0f add r28, r30
5
1ad6: d1 1d adc r29, r1
6
1ad8: 0f b6 in r0, 0x3f ; 63
7
1ada: f8 94 cli
8
1adc: de bf out 0x3e, r29 ; 62
9
1ade: 0f be out 0x3f, r0 ; 63
10
1ae0: cd bf out 0x3d, r28 ; 61
11
1ae2: ed 01 movw r28, r26
12
1ae4: 08 95 ret
Klingt plausiebel. Aber ich frage mich, warum der gcc-13.1 das nicht
macht. Sind im neuen GCC vielleicht irgendwelche stack pointer
Schutzmechanismen eingebaut worden die jetzt mehr speicher verbrauchen?
Der gcc-13.1 schiebt den stack pointer natuerlich auch immer wieder
herum. Aber vor allem dann, wenn eine groessere sub-routine (oder
mehrere davon) aufgerufen wird. Ich habe kaum Stellen gesehen an den es
so aufwaendig gemacht wird, obwohl die sub-routine wirklich so banal ist
wie mein `txRaw` oben.
Falls es etwas bringt, kann ich den generierten code fuer die kleine
`txRaw` auch posten.
Ich habe noch paar andere Stellen gefunden, an den der gcc-15.1 sich dem
stack pointer mehr zuwendet. Es ist etwas weniger aufwaendig wie oben
und ist vollstaendig, ohne 'jump', in den prologue der Funktion
eingebettet. Allerdings macht an der gleichen Stellen der gcc-13.1
nichts weiter als nur den Stackpointer zu speichern, was viel weniger
aufwaendig und damit kuerzer ist.
Hier ein Auszug aus einer etwas groesseren Funktion. Nur der prologue.
gcc-13.1:
c70: a3 85 ldd r26, Z+11 ; 0x0b // ab hier alles wieder gleich
22
c72: b4 85 ldd r27, Z+12 ; 0x0c
Ist es moeglich dem gcc-15.1 etwas schlankere Funktionsaufrufe
beizubringen? Ich habe das Gefuel, dass ich, zumindest in meinem Code,
einiges sparen koennte.
-Foka
Jörg W. schrieb:> Johann L. schrieb:>> Da oktal in MISRA absolut verboten ist, darf man also immer noch nicht>> "x = 0;" schreiben>> Prust! Aber man kann jetzt immerhin "x = 0815;" schreiben. :-)
0815 ist weiterhin eine oktale Ganzzahl. Ab C2y in einer dann
veralteten, aber weiterhin unterstützten Schreibweise.
Foka M. schrieb:> Ist es moeglich dem gcc-15.1 etwas schlankere Funktionsaufrufe> beizubringen?
Bestimmt. Wie überall bei open source gilt: einfach machen...
Ob sich überhaupt jemand sich gross um den avr-g++ kümmert, keine
Ahnung. Der hat ja mit dem hier (implizit) besprochenen C-Compiler
nichts zu tun.
Oliver
Foka M. schrieb:> Zum einen muss ich zu geben, dass ich die gcc-13.1 und 15.1> tool-chains mit verschiedenen avr-libc Versionen gebaut habe.
Spielt auf der Ebene keine Rolle.
> In `.Loc.16` ist eine sub-routine die den SREG rettet, interrupts> stoppt, stack pointer runter schiebt, und dann den SREG wieder> zurueck holt (gcc-15.1):
Das ist __epilogue_restores
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/avr/lib1funcs.S;h=dfe99b1ea06f5b45e0a19942c42fe92f46e497ac;hb=HEAD#l2241
das Gegenstück zu __prologue_saves
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/avr/lib1funcs.S;h=dfe99b1ea06f5b45e0a19942c42fe92f46e497ac;hb=HEAD#l2188
Beide können verwendet werden wenn -mcall-prologues an ist.
> Aber ich frage mich, warum der gcc-13.1 das nicht macht.
Weil, wie du bereitst feststelltest, v15 mehr Stack beansprucht.
> Falls es etwas bringt, kann ich den generierten code fuer die kleine> `txRaw` auch posten.
Den generierten Code seh ich ja. Bestenfalls könnte man mit dem
Präcompilat (*.ii von -save-temps) was anfangen.
> Ist es moeglich dem gcc-15.1 etwas schlankere Funktionsaufrufe> beizubringen?
Da es sich um den Register-Allokator handelt wäre eine Änderung
hochgradig nichttrivial und würde alle Targets betreffen, also nicht nur
AVR.
Mit C vs. C++ hat das überigens nichts zu tun. Die > 300 Passes nach dem
Frontend sind für C und C++ die selben.
Thread beobachten
Seitenaufteilung abschalten