1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • 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_isdigit inline gesetzt und crcu8 auf eine einfachere branchless Implementierung umgestellt wurde, erreichte QBE die anvisierten 70 % der Leistung von gcc -O2
  • Das neue OCaml-Tool mgen kompiliert lispy-IL-Muster in C-Matching-Code und kann damit die bisher handgeschriebene Instruction-Selection-Logik ersetzen oder vereinfachen
  • mgen findet IL-Muster in speziellen Kommentarblöcken und fügt direkt darunter C-Code ein; ein aktuelles Einsatzbeispiel gibt es in isel.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_win fü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

 
GN⁺ 3 시간 전
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

    • Mein C-Compiler kann PIC erzeugen, falls das interessant ist: https://codeberg.org/lsof/antcc/
      Ich hoffe, das klingt nicht nach Eigenwerbung. Ich mag kleine Compiler einfach wirklich sehr, und es braucht auch mehr Tests
    • Ich baue ebenfalls ein OS mit flacher Memory-Map, bei dem alles PIE ist und Systemaufrufe Funktionsaufrufe sind: Ashet OS
      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 um
      Die 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-Keyword
    Es 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 FreeBSDs ctype.h braucht das
    extern wird auch auf Plattformen wie macOS oder Haiku benötigt, um auf normale globale Variablen in Shared Libraries zuzugreifen, zum Beispiel stderr. Dadurch können QBE-basierte Compiler jetzt deutlich mehr Betriebssysteme und Anwendungsfälle unterstützen
    Auch 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

    • QBE ist unter den Compiler-Backends am ehesten das „OpenBSD“. Seine Philosophie sind Einfachheit und Minimalismus, und laut der offiziellen Beschreibung ist das Ziel, „70 % der Performance eines industriellen Optimierungscompilers mit 10 % des Codes“ zu liefern
      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 denke, die Ziele überschneiden sich nicht nur mit Cranelift, sondern auch mit 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