Hallo, ich bin aktuell auf der Suche nach Informationen den GCC an eine selbst entworfene Architektur anzupassen (Backend), finde bislang aber nur sehr wenig darüber. Hat eventuell jemand ein paar Informationen darüber für mich? Also die Basics (GCC Source besorgen, Config Files anpassen, Prozessorspezifische Definitionen und Implementationen anlegen, etc.) sind klar, ich suche dabei eher etwas konkretere Vorgehensweisen, am besten anhand einer Beispielarchitektur.
schau dir lieber clang/llvm in kombination mit risc-v an..
LLVM hab ich schon durch, diesmal gehts mir nur um GCC. Und RISC-V ist für so ein Vorhaben eine denkbar schlechte Wahl, viel zu viel Funktionalität, ich würde mich lieber von einer Minimal Architektur aus hocharbeiten als ewig versuchen RISC-V runter zu bauen.
Tim T. schrieb: > LLVM hab ich schon durch, diesmal gehts mir nur um GCC. Hab ich auch mal versucht, habs aber aufgegeben weil ich nichts vernüftiges gefunden habe und der Code vom GCC nicht gerade der schönste und aussagekräftigste ist. LLVM ist da wesentlich besser. Tim T. schrieb: > Und RISC-V ist für so ein Vorhaben eine denkbar schlechte Wahl, viel zu > viel Funktionalität, ich würde mich lieber von einer Minimal Architektur RV32I Base Integer Instruction Set hat gerade mal 39 Instruktionen und implementiert nur einfachste Integerarithmetik und den Rest den man so braucht. Mehr braucht es nicht. Mein eigener minimalistischer 8Bit Softcore hat sogar ein paar mehr. Also einfacher gehts eigentlich kaum...
Obacht beim Zählen von Befehlen. So kann man beispielsweise bedingte Sprünge gleicher Sprungweise aber unterschiedlicher Bedingungen als 16 Befehle zählen, oder als einen einzigen mit Bedingung als Parameter. Der Aufwand ist identisch, nur die Darstellung über die Anzahl der Befehle unterscheidet sind. Bei 8-Bit Prozessoren mit Akku kommen in Verbindung mit den dabei erforderlichen Load-Execute Operation oft mehrere Adressierungsarten ins Spiel, die bei 32-Bit Prozessoren nicht nötig sind. Das erhöht die Anzahl unterscheidbarer Befehle. Viel minimierter als RV32I erscheint mir bei 32 Bits nur sinnvoll, wenn man von der Anwendung her genau weiss, dass man bestimmte Grundadressierungen, Grundoperationen oder Datenbreiten nicht benötigt.
:
Bearbeitet durch User
Christopher C. schrieb: > Hab ich auch mal versucht, habs aber aufgegeben weil ich nichts > vernüftiges gefunden habe und der Code vom GCC nicht gerade der schönste > und aussagekräftigste ist. LLVM ist da wesentlich besser. Schon klar, aber mit LLVM hab ich schon mehrere Architekturen portiert, diesmal will ichs unbedingt auf GCC versuchen, dem bin ich bislang immer wegen den genannten Gründen aus dem Weg gegangen. Christopher C. schrieb: > RV32I Base Integer Instruction Set hat gerade mal 39 Instruktionen und > implementiert nur einfachste Integerarithmetik und den Rest den man so > braucht. Mehr braucht es nicht. Mein eigener minimalistischer 8Bit > Softcore hat sogar ein paar mehr. Also einfacher gehts eigentlich > kaum... Naja, aber wenn du dir mal das RISC-V Backend im GCC anschauen würdest, ist das auf einmal garnicht mehr so minimalistisch. Da gibts minimalistischere Ansätze.
:
Bearbeitet durch User
Tim T. schrieb: > Christopher C. schrieb: >> RV32I Base Integer Instruction Set hat gerade mal 39 Instruktionen und >> implementiert nur einfachste Integerarithmetik und den Rest den man so >> braucht. Mehr braucht es nicht. Mein eigener minimalistischer 8Bit >> Softcore hat sogar ein paar mehr. Also einfacher gehts eigentlich >> kaum... > > Naja, aber wenn du dir mal das RISC-V Backend im GCC anschauen würdest, > ist das auf einmal garnicht mehr so minimalistisch. Da gibts > minimalistischere Ansätze. Liegt aber eher daran, dass der GCC das hier alles abdeckt:
1 | RV32I: A load-store ISA with 32, 32-bit general-purpose integer registers. |
2 | RV32E: An embedded flavor of RV32I with only 16 integer registers. |
3 | RV64I: A 64-bit flavor of RV32I where the general-purpose integer registers are 64-bit wide. |
4 | |
5 | In addition to these base ISAs, a handful of extensions have been specified. The extensions that have both been specified and are supported by the toolchain are: |
6 | |
7 | M - Integer Multiplication and Division |
8 | A - Atomics |
9 | F - Single-Precision Floating-Point |
10 | D - Double-Precision Floating-Point |
11 | |
12 | C - 16-bit Compressed Instructions |
13 | G - General, a shortcut to IMAFD |
Quelle: https://gnu-mcu-eclipse.github.io/toolchain/riscv/
Tim T. schrieb: > Naja, aber wenn du dir mal das RISC-V Backend im GCC anschauen würdest, > ist das auf einmal garnicht mehr so minimalistisch. Da gibts > minimalistischere Ansätze. Geht es dir um die Minimierung der Architektur, oder um die Minimierung des Backends im Compiler? Das sind zwei recht verschiedene Paar Stiefel. Das Backend eines Compilers pflegt mit der Zeit zu wachsen, weil man immer wieder Sequenzen finden, die man besser implementieren könnte. Und weil optionale Befehlssätze hinzu kommen. Macht man es für sich selber und interessiert sich nicht für Prozessor-spezifische Optimierungen, kann man die auch weglassen und sich auf die generischen Optimierungen des Compilers verlassen. Beim RISC-V kommt hinzu, dass dessen Backend wahrscheinlich für alle Varianten gleichermassen verwendet wird, also sowohl für RV32I als auch den Maximalausbau. Die Komplexität des Codes vom Backend wird dadurch natürlich grösser. Bei einem Exoten, für den sich ausser dem Entwickler selbst kein Aas interessiert, sieht es dann viel einfacher aus.
:
Bearbeitet durch User
A. K. schrieb: > Geht es dir um die Minimierung der Architektur, oder um die Minimierung > des Backends im Compiler? Das sind zwei recht verschiedene Paar Stiefel. > Das Backend eines Compilers pflegt mit der Zeit zu wachsen, weil man > immer wieder Sequenzen finden, die man besser implementieren könnte. Und > weil optionale Befehlssätze hinzu kommen. > > Macht man es für sich selber und interessiert sich nicht für > Prozessor-spezifische Optimierungen, kann man die auch weglassen und > sich auf die generischen Optimierungen des Compilers verlassen. > > Beim RISC-V kommt hinzu, dass dessen Backend wahrscheinlich für alle > Varianten gleichermassen verwendet wird, also sowohl für RV32I als auch > den Maximalausbau. Die Komplexität des Codes vom Backend wird dadurch > natürlich grösser. Bei einem Exoten, für den sich ausser dem Entwickler > selbst kein Aas interessiert, sieht es dann viel einfacher aus. In erster Linie geht es mir darum das ich, im Idealfall, anhand eines Beispiels die Portierung aufs Backend im GCC nachvollziehen kann. Alternativ dazu würde ich sonst mir mal ein einfaches Backend als Vorlage anschauen und eventuell auf meine Bedürfnisse umbauen. RISC-V ist da als Vorlage aufgrund der mehrfachen ISA Profilen, den 32/64-Bit Modi und dem ganzen anderen Raffel, der im laufe der Zeit dazu gekommen ist, nicht mehr wirklich einfach nachvollziehbar. Also ganz konkret: Erstmal geht es mir um ein minimalistisches Backend im Compiler um es nachvollziehen und als Vorlage nutzen zu können.
:
Bearbeitet durch User
Tim T. schrieb: > Also ganz konkret: Erstmal geht es mir um ein minimalistisches Backend > im Compiler um es nachvollziehen und als Vorlage nutzen zu können. Dann schau dir mal das Backend für die ZPU an. ZPU ist recht bekannt und sehr minimalistisch. https://github.com/zylin/zpu https://github.com/zylin/zpugcc
Christopher C. schrieb: > Tim T. schrieb: >> Also ganz konkret: Erstmal geht es mir um ein minimalistisches Backend >> im Compiler um es nachvollziehen und als Vorlage nutzen zu können. > > Dann schau dir mal das Backend für die ZPU an. ZPU ist recht bekannt und > sehr minimalistisch. > > https://github.com/zylin/zpu > https://github.com/zylin/zpugcc Danke, genau an sowas hatte ich gedacht.
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.