QBE – Compiler-Backend: Version 1.3
(c9x.me)- Es wurden umfangreiche Performance-Optimierungen hinzugefügt, sodass QBE 1.3 bei unverändertem coremark mehr als 63 % der Leistung eines kommerziellen Compilers erreicht und in der Hare-Testsuite gegenüber qbe-1.2 um 33 % verbessert ist
- QBE 1.3 ist das größte Release seit 1.0 und umfasst etwa 7k zusätzliche Zeilen sowie 1,5k gelöschte Zeilen
- Zu den neuen Optimierungen gehören GVN/GCM, Loop-Optimierungen, If-Eliminierung, CFG-Vereinfachung und mehr, wobei nur einige verifizierte Passes beibehalten wurden
- Inlining wurde aus diesem Optimierungs-Set ausgeschlossen, da es nicht gut zum Streaming-Compile-Modell auf Funktionsebene von QBE passt
- In einer Coremark-Variante, in der
ee_isdigitinline gesetzt undcrcu8auf eine einfachere branchless Implementierung umgestellt wurde, erreichte QBE die anvisierten 70 % der Leistung vongcc -O2 - Das neue OCaml-Tool
mgenkompiliert lispy-IL-Muster in C-Matching-Code und kann damit die bisher handgeschriebene Instruction-Selection-Logik ersetzen oder vereinfachen mgenfindet IL-Muster in speziellen Kommentarblöcken und fügt direkt darunter C-Code ein; ein aktuelles Einsatzbeispiel gibt es inisel.c- Das Matching von Instruction-DAGs folgt einem nummerierungsbasierten Ansatz ähnlich dem des Plan9-C-Compilers von Ken Thompson; außerdem wird ein einfacher Bytecode-Matcher erzeugt, den
runmatch()interpretiert - Unterstützung für die Windows-ABI wurde hinzugefügt, sodass mit
-t amd64_winfür Windows kompiliert werden kann - Der von QBE erzeugte Assembler verwendet weiterhin die AT&T-Syntax; empfohlen wird daher die Kompilierung mit dem mingw-Assembler
- Die Unterstützung für positionsunabhängigen Code wurde verbessert, sodass auf den meisten Targets Shared Objects reibungsloser gelinkt und erzeugt werden können
- Mit dem neuen dynamischen
extern-Konstanten-Flag (DYNCONST) kann auf IL-Ebene indirekter Zugriff auf globale Symbole wie Variablen in dynamischen Bibliotheken dargestellt werden
1 Kommentare
Lobste.rs-Kommentare
Ich arbeite seit Langem als Hobbyprojekt an einem kleinen OS im Stil von TRIPOS/Amiga Exec
Es hat keinen Speicherschutz, ein flaches Memory-Map, und selbst Message Passing bedeutet im Grunde nur, Pointer weiterzugeben
Um so ein System self-hosting-fähig zu machen, ist ein kleiner Compiler, der PIE/PIC erzeugen kann, deutlich praktischer. Bibliotheken im Amiga-Stil müssen natürlich PIC sein, und es ist außerdem gut, beim Laden nicht viele Patches vornehmen zu müssen, wenn man ein Executable irgendwo in eine gemeinsam genutzte Memory-Map legt
GCC und Clang können das zwar, sind aber viel zu groß. Als ich das letzte Mal nachgesehen habe, konnte TCC kein PIC, also sollte ich mir QBE wohl genauer ansehen
Ich hoffe, das klingt nicht nach Eigenwerbung. Ich mag kleine Compiler einfach wirklich sehr, und es braucht auch mehr Tests
Es ist schon ziemlich weit fortgeschritten und unterstützt mehrere Plattformen
Self-Hosting wird aber wohl so bald schwierig. Ich brauche Thumb-2-Codegenerierung, und praktisch der einzige Weg dafür ist, selbst einen Compiler zu schreiben. Dazu kommt die Beschränkung auf nur 8 MB nutzbaren RAM außerhalb des Kernel-Codes
Ich verwende ein eigenes Executable-Format namens
.ashex, das aus ELF-Dateien konvertiert wird. Dabei wird effektiv eine spezielle Section verbraucht, die nur aus einem absoluten Jump besteht, und der App-Loader schreibt sie dann auf die tatsächliche Adresse des Systemaufrufs umDie Schwierigkeit bei einem flachen Speichersystem besteht darin, Shared Objects sauber zu unterstützen. Um Code zwischen verschiedenen Anwendungen zu teilen, braucht man Compiler-Unterstützung, damit jeder Zugriff auf dynamische Symbole über Variablen erfolgt, die in Registern gehalten werden
Ich freue mich wirklich über das neue
extern-KeywordEs steht zwar nicht in den Release Notes, funktioniert aber auch zusammen mit
thread, sodass initial-exec TLS möglich wird. Das wird benötigt, um auf thread-lokale globale Variablen zuzugreifen, die in anderen Shared Libraries definiert sind, und FreeBSDsctype.hbraucht dasexternwird auch auf Plattformen wie macOS oder Haiku benötigt, um auf normale globale Variablen in Shared Libraries zuzugreifen, zum Beispielstderr. Dadurch können QBE-basierte Compiler jetzt deutlich mehr Betriebssysteme und Anwendungsfälle unterstützenAuch für Rolands Performance-Verbesserungen bin ich sehr dankbar. Wirklich hervorragende Arbeit
Wenn ich das richtig gelesen habe, heißt das, es gibt jetzt offizielle Windows-Unterstützung?
War das nicht einer der historisch größten und bis heute wichtigsten Einschränkungen von QBE? Das ist wirklich schön zu sehen
Überschneidet sich das Ziel dieses Projekts mit Cranelift? Ich habe kein gutes Gefühl dafür, wann man QBE verwendet
Die eigentlichen Konkurrenten sind Cranelift und LLVM
Leider wurde es in der Vergangenheit meist nur für Hobbysprachen oder als Compiler-Implementierung verwendet. myrddin, das einmal wie eine neue C-artige Sprache aussah, scheint zum Beispiel tot zu sein, und cproc ist noch eine lebendige C-Compiler-Implementierung als Hobbyprojekt
Trotzdem gibt es seit der Übernahme von QBE durch Hare wieder Anlass zur Hoffnung. Die Antwort auf die Frage steht hier: https://harelang.org/documentation/faq.html#why-qbe-instead-of-llvm
Ich kenne die Details nicht besonders gut, aber es gibt viele Vergleiche. Soweit ich weiß, zielt QBE im Vergleich zu den beiden anderen auf ein viel einfacheres Backend ab
Ich finde den Ansatz mit einer kleinen DSL zum Erzeugen eines Instruction-Selection-Matchers wirklich großartig