Bombyx: OpenCilk-Kompilierung für FPGA-Hardwarebeschleunigung

Grundinformationen

• Paper-ID: 2511.21346
• Titel: Bombyx: OpenCilk Compilation for FPGA Hardware Acceleration
• Autoren: Mohamed Shahawy, Julien de Castelnau, Paolo Ienne (École Polytechnique Fédérale de Lausanne)
• Klassifizierung: cs.AR (Computerarchitektur)
• Veröffentlichungsdatum: 26. November 2025 (arXiv-Preprint)
• Paper-Link: https://arxiv.org/abs/2511.21346

Zusammenfassung

Dieser Artikel präsentiert Bombyx, eine Toolchain zur Kompilierung von OpenCilk-Programmen in FPGA-Hardwarebeschleuniger. Bombyx konvertiert das implizite Task-Parallelitätsmodell von OpenCilk in eine explizite Continuation-Passing-Zwischendarstellung im Cilk-1-Stil, die besser für die Stream-Charakteristiken von FPGAs geeignet ist. Die Toolchain unterstützt mehrere Kompilierungsziele: eine OpenCilk-kompatible Laufzeit zur Verifikation sowie synthetisierbare Processing-Unit-Generatoren für High-Level-Synthesis-Tools wie Vitis HLS. Darüber hinaus führt Bombyx die Decoupled-Access-Execute (DAE)-Optimierung ein, die automatisch hochperformante Processing Units generiert und die Speicher-Compute-Überlappung sowie den Gesamtdurchsatz verbessert.

Forschungshintergrund und Motivation

1. Kernproblem

Task-Level-Parallelität (TLP) ist eine weit verbreitete Parallelisierungstechnik in Software, die die dynamische Erstellung und Planung unabhängiger Tasks zur Laufzeit ermöglicht. Obwohl bereits Hardwarerahmen (wie ParallelXL und HardCilk) TLP auf FPGAs unterstützen, fehlt es an automatisierten Werkzeugen zur automatischen Extraktion und Kompilierung von Processing-Unit (PE)-Code aus Software-TLP-Frameworks. Bestehende Rahmen erfordern typischerweise, dass Benutzer PE-Code manuell bereitstellen, was sowohl mühsam als auch fehleranfällig ist.

2. Bedeutung des Problems

• Automatisierungsbedarf: Die Portierung von CPU-orientierten TLP-Anwendungen auf FPGAs erfordert umfangreiche manuelle Arbeit, einschließlich Code-Umstrukturierung, Hardware-Interface-Anpassung und Konfigurationsdateigenerierung
• Leistungsoptimierung: Manuell geschriebener Code kann nur schwer fortgeschrittene Hardwareoptimierungen (wie Decoupled-Access-Execute) anwenden
• Entwicklungseffizienz: Das Fehlen automatisierter Toolchains behindert die breite Anwendung von TLP bei der FPGA-Beschleunigung

3. Einschränkungen bestehender Ansätze

• Implizites OpenCilk-Modell: Das Fork-Join-Modell mit cilk_spawn und cilk_sync erfordert Kontextwechsel an Synchronisationspunkten. Die Implementierung von Kontextwechseln in Hardware erfordert das Speichern des gesamten Schaltungszustands, was von aktuellen HLS-Tools weder direkt unterstützt wird noch umfangreiche RTL-Entwicklung erfordert
• TAPIR-Zwischendarstellung: Das von OpenCilk verwendete TAPIR nutzt Low-Level-Compiler-Konstrukte, die es schwierig machen, lesbaren C++-Code ähnlich dem Original für HLS zu generieren
• Manuelle PE-Programmierung: Erfordert manuelle Behandlung von Closure-Ausrichtung, Write-Buffer-Interfaces, Konfigurationsdateigenerierung und anderen mühsamen Details

4. Forschungsmotivation

Das explizite Continuation-Passing-Modell von Cilk-1 ist besser für die Hardwareimplementierung geeignet, da es Funktionen an Synchronisationspunkten in Terminierungsfunktionen aufteilt (die atomar ausgeführt werden, ohne Kontextwechsel). Obwohl dieses Modell für die Software-Programmierung nicht intuitiv genug ist (und daher in der Cilk-Entwicklung aufgegeben wurde), ist es für die Hardwareimplementierung natürlich. Das Ziel von Bombyx ist es, die Konvertierung von OpenCilk zu explizitem TLP zu automatisieren und optimierte Hardware-PEs zu generieren.

Kernbeiträge

1. Automatisierter Kompilierungsprozess: Präsentation einer vollständigen automatisierten Toolchain Bombyx von OpenCilk zu FPGA-Hardwarebeschleunigern
2. Explizite Zwischendarstellung: Entwurf einer auf Kontrollflussgraphen basierenden impliziten und expliziten IR, die die automatische Konvertierung vom Fork-Join-Modell zum Continuation-Passing-Modell ermöglicht
3. Multi-Target-Codegenerierung:
   • HardCilk-Backend: Automatische Generierung von synthetisierbarem C++ HLS-Code und Konfigurationsdateien
   • Cilk-1-Simulationsschicht: Verwendung der OpenCilk-Laufzeit zur Verifikation der Konvertierungskorrektheit
4. Decoupled-Access-Execute-Optimierung: Unterstützung der DAE-Optimierung durch Compiler-Direktiven (Pragmas), die Speicherzugriff und Berechnung in verschiedene Tasks aufteilen und die Hardwareleistung verbessern
5. Experimentelle Verifikation: DAE-Optimierung erreicht eine Laufzeitreduktion von 26,5% in Graph-Traversal-Benchmarks

Methodische Details

Aufgabendefinition

Eingabe: Task-parallele C/C++-Programme, die mit OpenCilk geschrieben sind (CPU-orientiert)
Ausgabe:

• Synthetisierbarer C++ HLS-Code (zur FPGA-PE-Generierung)
• HardCilk-Systemkonfigurationsdateien (JSON-Format)
• Oder ausführbarer Code im Cilk-1-Stil (zur Verifikation)

Einschränkungen:

• Programme müssen dem Fork-Join-Modell von OpenCilk entsprechen
• Abhängigkeiten zwischen Funktionen müssen explizit durch cilk_spawn und cilk_sync ausgedrückt werden

Gesamtarchitektur-Design

Der Kompilierungsprozess von Bombyx besteht aus drei Hauptphasen (siehe Abbildung 3):

OpenCilk-Quellcode → AST → Implizite IR → Explizite IR → Codegenerierung
                      ↓              ↓          ↓
                   Clang-Frontend  DAE-Opt.  HardCilk/Cilk-1

1. AST-zu-implizite-IR-Konvertierung

• Verwendung des OpenCilk Clang-Frontends zur Generierung des abstrakten Syntaxbaums
• Konvertierung des AST in eine Kontrollflussgraph (CFG)-Darstellung der impliziten IR
• Jede Funktion entspricht einem CFG, der Folgendes enthält:
  • Eindeutiger Eingangsblock (keine eingehenden Kanten)
  • Ein oder mehrere Ausgangsblöcke (keine ausgehenden Kanten)
  • Grundblöcke bestehen aus sequenziellen C-Anweisungen, die mit Kontrollflusanweisungen enden

Warum nicht TAPIR verwenden: TAPIR verwendet Low-Level-Konstrukte (wie φ-Knoten, alloca usw.), die es schwierig machen, lesbaren C++-Code ähnlich dem Original zu generieren. Die IR von Bombyx behält die ursprüngliche Codestruktur bei.

2. Konvertierung von impliziter IR zu expliziter IR

Dies ist der zentrale Konvertierungsschritt von Bombyx, der das implizite Synchronisationsmodell von OpenCilk in das explizite Continuation-Passing-Modell von Cilk-1 konvertiert.

Schlüsselkonzepte:

• Closure: Eine Datenstruktur, die eine Task darstellt und Folgendes enthält:
  • Verfügbare Parameter
  • Platzhalter für wartende Abhängigkeiten
  • Rückgabezeiger
• spawn_next: Erstellt eine Continuation-Task, die auf Abhängigkeiten wartet
• send_argument: Schreibt explizit Argumente in einen wartenden Closure und benachrichtigt den Scheduler

Konvertierungsalgorithmus:

1. Pfadaufteilung: Durchlaufe den CFG und starte einen neuen Pfad, wenn Funktionsterminierungsblöcke (return) oder Sync-Operationen auftreten
   • Jeder Pfad wird zu einer in sich geschlossenen Terminierungsfunktion
   • Grau schattierte Bereiche in Abbildung 4(c) stellen zwei Pfade dar
2. Abhängigkeitserkennung: Analysiere Abhängigkeitsbeziehungen an Sync-Grenzen
   • Identifiziere Variablen, die nach Sync verwendet werden müssen (wie x und y in Abbildung 1)
   • Diese Variablen müssen explizit in Closure-Feldern gespeichert werden
3. Schlüsselwort-Ersetzung:
   • Einfügen von Closure-Deklarationen bei Spawn-Aufrufen
   • Ersetzen von Sync durch spawn_next-Aufrufe der Nachfolgerfunktion
   • Ändern von Spawn-Rückgabewerten in explizites Schreiben in Closure-Felder
   • Beibehaltung von Return-Anweisungen, die später in send_argument konvertiert werden können

Konvertierungsbeispiel (Abbildung 1 zu Abbildung 2):

// Implizit (OpenCilk)
int x = cilk_spawn fib(n-1);
int y = cilk_spawn fib(n-2);
cilk_sync;
return x + y;

// Explizit (Cilk-1)
cont int x, y;
spawn_next sum(k, ?x, ?y);  // Erstelle Continuation-Task
spawn fib(x, n-1);           // Schreibe in x-Platzhalter
spawn fib(y, n-2);           // Schreibe in y-Platzhalter
// Funktion endet, kein Sync erforderlich

HardCilk-Backend-Generierung

HardCilk ist ein Open-Source-FPGA-TLP-Architektur-Generator, der einen Hardware-Work-Stealing-Scheduler bereitstellt. Bombyx automatisiert die Generierung aller erforderlichen HardCilk-Komponenten:

1. Closure-Ausrichtung

• Automatisches Hinzufügen von Padding, um Closure-Größen auf 128/256 Bit auszurichten
• Erleichtert die Hardwareimplementierung

2. Write-Buffer-Interface

• HardCilk verwendet ein Write-Buffer-Modul zur Verarbeitung von spawn_next und send_argument
• Bombyx fügt automatisch erforderliche Metadaten ein (Task-Typ, Zieladresse usw.)

3. JSON-Konfigurationsgenerierung

Automatische Generierung von Systembeschreibungsdateien durch statische Analyse, die Folgendes enthält:

• Closure-Größen
• Spawn/Spawn_next/Send_argument-Beziehungen zwischen Tasks
• Weitere Systemkonfigurationsparameter

Decoupled-Access-Execute (DAE)-Optimierung

Motivation

In naiver PE-Implementierung ist eine einzelne Einheit für die Initiierung von Speicheranforderungen und die Ausführung von Berechnungen verantwortlich, was zu Folgendem führt:

• Speicherstalls lassen die PE untätig werden
• Verringerte Gesamtdurchsatzleistung

Traditionelle Pipelining in HLS-Tools (wie Vitis) ist begrenzt:

• Kann Schleifen mit Datenabhängigkeiten an Schleifengrenzen nicht verarbeiten
• Statischer Scheduler kann nicht bestimmen, wann Speicherzugriffe geplant werden sollen

DAE-Lösung

Unter TLP werden Speicherzugriff und Ausführung als verschiedene Tasks ausgedrückt:

• Speicherzugriffs-Task: Speziell verantwortlich für Speicheranforderungen
• Ausführungs-Task: Verarbeitet Berechnungslogik
• Task-Scheduler: Koordiniert die Ausführung und implementiert elastisches Pipelining

Implementierungsweise

Durch Pragma-Direktiven zur Anleitung des Compilers:

#PRAGMA BOMBYX DAE
struct node_t nd = *n;  // Speicherzugriff
// Nachfolgender Code wird zur Ausführungs-Task

Der Compiler führt automatisch Folgendes durch:

1. Extrahieren der annotierten Zeile in eine unabhängige Funktion (Speicherzugriffs-Task)
2. Ersetzen durch Spawn-Aufruf
3. Einfügen von Sync
4. Nach Konvertierung in explizite Form spawnt die Speicherzugriffs-Task die Continuation der Ausführungs-Task

Experimentelle Einrichtung

Benchmarks

Graph-Traversal-Programm (Abbildung 5):

• Parallele Breitensuchen-Graph-Traversal
• Zugriff auf Knotenadjazenzlisten (speicherintensiv)
• Rekursiver paralleler Zugriff auf benachbarte Knoten

Datensätze

Synthetisch generierte Baumgraphen:

• Graph 1: Tiefe D=7, Verzweigungsfaktor B=4, insgesamt 5.461 Knoten
• Graph 2: Tiefe D=9, Verzweigungsfaktor B=4, insgesamt 87.381 Knoten
• Knotenanzahl-Berechnung: $\frac{B^D - 1}{B - 1}$

Experimentelle Konfiguration

• FPGA-Plattform: Xilinx Alveo U55C (xcu55c-fsvh2892-2L-e)
• Synthese-Tool: Vivado 2024.1
• Zielfrequenz: 300 MHz
• PE-Anzahl:
  • Non-DAE: 1 PE
  • DAE: 3 PEs (je eine für Spawner, Executor, Access)

Bewertungsmetriken

1. Laufzeit: Zeit, die für die Traversal des gesamten Graphen erforderlich ist
2. Ressourcenauslastung:
   • LUT (Look-Up Tables)
   • FF (Flip-Flops)
   • BRAM (Block RAM)

Experimentelle Ergebnisse

Hauptleistungsergebnisse

• Laufzeitreduktion: DAE-Optimierung erreicht 26,5% Leistungsverbesserung
• Durch Entkopplung von Speicherzugriff und Ausführung wurde die Speicher-Compute-Überlappung verbessert

Ressourcenauslastungsanalyse

Ressourcen-Overhead:

• LUT-Anstieg um 47% (2.657 → 3.896)
• FF-Anstieg um 50% (2.305 → 3.464)
• BRAM verdoppelt sich (2 → 4)

Experimentelle Erkenntnisse

1. Leistungs-Ressourcen-Kompromiss: Die 26,5%ige Leistungsverbesserung erfolgt auf Kosten eines Ressourcen-Overheads von etwa 50%, was für speicherintensive Anwendungen ein angemessener Kompromiss ist
2. PE-Größen-Analyse:
   • Spawner + Executor ≈ Größe der Non-DAE-Single-PE
   • Access-Task benötigt zusätzliche Ressourcen
   • Empfehlung: Verwendung von RTL-implementierten datenparallelen PEs kann Speicherzugriffs-Task-Kosten amortisieren
3. Optimierungspotenzial: Das Paper weist darauf hin, dass zukünftig Speicherzugriffs-Tasks als Black-Box-Primitive integriert werden könnten, anstatt sie mit HLS zu generieren

Verwandte Arbeiten

TLP-Software-Frameworks

1. Intel Thread Building Blocks (TBB): Weit verbreitete Task-Parallel-Bibliothek in der Industrie
2. Cilk Plus: Cilk-Erweiterung von Intel
3. OpenCilk: Neuestes Cilk-Framework mit besserer Leistung als vorherige Frameworks

TLP-Hardware-Frameworks

1. ParallelXL: Frühes FPGA-TLP-Architektur-Framework
2. HardCilk: Zielplattform von Bombyx, Open-Source-FPGA-TLP-System mit Hardware-Work-Stealing-Scheduler

Cilk-Entwicklung

1. Cilk-1: Früheste Version mit explizitem Continuation-Passing
2. Nachfolgende Versionen: Übergang zum impliziten Fork-Join-Modell (besser für Software-Programmierung)
3. Theoretische Grundlagen: Bewiesene Konvertierbarkeit jedes impliziten Programms in explizite Form

Vorteile dieses Papers

• Erstes automatisiertes Tool: Vollständiger automatisierter Prozess von OpenCilk zu FPGA-PE
• Explizite Konvertierung: Nutzung des Cilk-1-Stils zur Vermeidung von Hardware-Kontextwechseln
• Optimierungsunterstützung: Integration von DAE und anderen hardwarespezifischen Optimierungen

Schlussfolgerungen und Diskussion

Hauptschlussfolgerungen

1. Bombyx realisiert erfolgreich einen automatisierten Kompilierungsprozess von OpenCilk zu FPGA-Hardware
2. Das explizite Continuation-Passing-Modell ist für die Stream-Charakteristiken von FPGAs geeignet und vermeidet teure Kontextwechsel
3. DAE-Optimierung erreicht 26,5% Leistungsverbesserung in Graph-Traversal-Benchmarks
4. Das Tool ist auf andere Hardware-TLP-Frameworks erweiterbar

Einschränkungen

1. DAE-Optimierung erfordert manuelle Anleitung: Derzeit erforderlich, dass Programmierer Pragmas einfügen; vollständige Automatisierung nicht implementiert
2. Begrenzte Bewertung:
   • Nur auf einem Benchmark (Graph-Traversal) bewertet
   • Fehlende Vergleiche mit anderen Methoden (wie handgeschriebenem Code, anderen Compilern)
   • Nicht auf vielfältigere Anwendungsszenarien getestet
3. Ressourcen-Overhead: DAE-Optimierung führt zu etwa 50% Ressourcenerhöhung, was große Systeme einschränken kann
4. Speicherzugriffs-Task-Implementierung: HLS-generierte Speicher-PE ist ineffizient; RTL wird empfohlen, aber nicht implementiert
5. Tool-Reife: Als Forschungsprototyp fehlt umfassende Fehlerbehandlung und Unterstützung für Grenzfälle

Zukünftige Richtungen

1. Automatische DAE-Erkennung: Entwicklung von Compiler-Analysen zur automatischen Erkennung von DAE-Optimierungsmöglichkeiten
2. RTL-Speichereinheiten: Integration effizienter RTL-implementierter datenparalleler Speichereinheiten
3. Weitere Optimierungen: Erkundung anderer hardwarespezifischer Optimierungen (wie Datenwiederverwendung, Lokalitätsoptimierung)
4. Erweiterte Ziele: Unterstützung für mehr Hardware-TLP-Frameworks und HLS-Tools
5. Umfassende Bewertung: Bewertung auf mehr Benchmarks, einschließlich verschiedener TLP-Anwendungstypen

Tiefgehende Bewertung

Stärken

1. Methodische Innovativität

• Einzigartige Konvertierungsstrategie: Geschickte Nutzung des expliziten Continuation-Passing-Modells von Cilk-1 zur Lösung des Hardware-Kontextwechsel-Problems
• Automatisierungswert: Erste vollständige automatisierte Toolchain von OpenCilk zu FPGA-Hardwarebeschleunigung, füllt wichtige Lücke
• Vernünftiges IR-Design: IR-Design, das die ursprüngliche Codestruktur beibehält, erzeugt lesbaren HLS-Code

2. Ingenieurwissenschaftliche Beiträge

• Hohe Praktikabilität: Automatisiert mühsame Details wie Closure-Ausrichtung, Write-Buffer-Interfaces, Konfigurationsdateigenerierung
• Verifizierbarkeit: Bereitstellung einer Cilk-1-Simulationsschicht zur Verifikation der Konvertierungskorrektheit erhöht die Tool-Zuverlässigkeit
• Open-Source-freundlich: Ziel-HardCilk ist ein Open-Source-System, förderlich für Tool-Verbreitung

3. Technische Einsichten

• Hardware-Software-Kodesign: Tiefes Verständnis der Anpassungsprobleme zwischen Software-TLP-Modellen und Hardwareimplementierung
• DAE-Optimierung: Kombination klassischer Hardwareoptimierungen mit TLP zeigt Potenzial von Compiler-gesteuerten Optimierungen

4. Schreibklarheit

• Fibonacci-Beispiel zeigt implizit-zu-explizit-Konvertierung klar
• IR-Vergleich in Abbildung 4 ist intuitiv und leicht verständlich
• Kompilierungsprozess-Diagramm ist klar

Schwächen

1. Unzureichende Experimente

• Einzelner Benchmark: Nur Graph-Traversal bewertet, kann Universalität des Tools nicht vollständig verifizieren
• Fehlende Vergleiche: Keine Vergleiche mit handgeschriebenem Code oder anderen Kompilierungsmethoden
• Begrenzte Skalierung: Getestete Graphen sind relativ klein (maximal 87K Knoten)
• Oberflächliche Leistungsanalyse: Keine Analyse der spezifischen Quellen der Leistungsverbesserung (Bandbreitenauslastung, Task-Planungseffizienz usw.)

2. Methodische Einschränkungen

• DAE-Halbautomatisierung: Erfordert manuelle Pragmas, begrenzt Benutzerfreundlichkeit
• Begrenzte Optimierungsvielfalt: Zeigt nur eine Optimierung (DAE), erforscht nicht andere Hardwareoptimierungen
• Großer Ressourcen-Overhead: 50% Ressourcenerhöhung kann praktische Anwendungen einschränken

3. Fehlende technische Details

• Unvollständige Konvertierungsalgorithmen: Keine detaillierten Erklärungen von Abhängigkeitsanalyse, Closure-Feldauswahl und anderen Schlüsselalgorithmen
• Korrektheitssicherung: Keine formalen Beweise oder systematische Verifikationsmethoden für Konvertierungskorrektheit
• Grenzfälle: Keine Diskussion der Behandlung von Rekursion, Zeigern, komplexen Datenstrukturen usw.

4. Bewertungstiefe

• Skalierbarkeit unbekannt: Nicht auf großen Anwendungen oder komplexen Kontrollflussmuster getestet
• Universalität fragwürdig: Ist Graph-Traversal repräsentativ für typische TLP-Anwendungen?
• Abstand zur Theorie: Ist die 26,5%ige Verbesserung nahe am theoretischen Limit?

Auswirkungen

1. Beitrag zum Forschungsgebiet

• Füllt Toolchain-Lücke: Bietet wichtige Infrastruktur für TLP-Anwendungen auf FPGAs
• Inspiriert zukünftige Forschung: Explizite Konvertierungsidee kann auf andere Parallelitätsmodelle angewendet werden
• Fördert Hardware-TLP: Senkt Eintrittsbarrieren, hilft bei TLP-Verbreitung in FPGA-Beschleunigung

2. Praktischer Wert

• Mittlerer praktischer Wert: Direkter Wert für HardCilk-Benutzer, erfordert aber weitere Reifung
• Lernkosten: Erfordert noch Verständnis von TLP-Konzepten und Hardwarebeschränkungen
• Produktionsreife: Als Forschungsprototyp noch entfernt von produktiver Verwendung

3. Reproduzierbarkeit

• Mittel: Abhängig von OpenCilk, HardCilk, Vitis HLS und anderen Toolchains
• Code nicht Open-Source: Paper erwähnt keine Code-Open-Source-Pläne
• Ausreichende Implementierungsdetails: Bietet genügend Implementierungs- und Experimentaldetails

Anwendungsszenarien

Geeignete Szenarien

1. Dynamische Task-Parallel-Anwendungen: Graph-Algorithmen, Baum-Traversal, dynamische Programmierung usw.
2. Speicherintensive Berechnungen: DAE-Optimierung besonders geeignet für speicherbegrenzte Anwendungen
3. HardCilk-Benutzer: Bereits verwendende oder planende HardCilk-Entwickler
4. Schnelle Prototypisierung: Schnelle Portierung von CPU-TLP-Code zu FPGA erforderlich

Ungeeignete Szenarien

1. Reguläre Parallelität: Datenparallelität, Pipelining und andere Szenarien ohne dynamische Planung
2. Ressourcenbeschränkung: 50% Ressourcen-Overhead möglicherweise nicht akzeptabel
3. Extreme Leistung: Handoptimiertes RTL möglicherweise noch besser
4. Komplexe Speichermuster: Tool-Unterstützung für komplexe Zeiger und dynamischen Speicher unbekannt

Verbesserungsvorschläge

1. Erweiterte Bewertung: Mehr Benchmarks hinzufügen (Sortierung, Suche, wissenschaftliche Berechnung usw.)
2. Leistungsvergleiche: Vergleiche mit handgeschriebenem HLS-Code, CPU-Implementierung, GPU-Implementierung
3. Automatische DAE: Compiler-Analyse zur automatischen Erkennung von DAE-Möglichkeiten entwickeln
4. Optimierungsvielfalt: Weitere Hardwareoptimierungen erforschen (Datenwiederverwendung, lokale Caches usw.)
5. Formale Verifikation: Formale Garantien für Konvertierungskorrektheit bereitstellen
6. Open-Source-Veröffentlichung: Tool Open-Source machen zur Förderung von Community-Beiträgen und Verifikation

Literaturverzeichnis

Schlüsselliteratur, auf die sich dieses Paper bezieht:

1. 2 OpenCilk (PPoPP'23): Neuestes Cilk-Framework, Eingabesprache von Bombyx
2. 4 HardCilk (FCCM'24): Zielplattform von Bombyx, frühere Arbeit der Autoren
3. 5 Cilk-1 (SIGPLAN'95): Klassisches explizites Continuation-Passing-TLP-System, theoretische Grundlage von Bombyx
4. 6 Joerg-Dissertation (1996): Beweis der theoretischen Machbarkeit der implizit-zu-explizit-Konvertierung

Gesamtbewertung: Bombyx ist eine wertvolle Forschungsarbeit, die die Lücke in der automatisierten Toolchain von OpenCilk zu FPGA-Hardwarebeschleunigung füllt. Die Kerninnnovation liegt in der Nutzung des expliziten Continuation-Passing-Modells von Cilk-1 zur Vermeidung von Hardware-Kontextwechseln und der Bereitstellung eines vollständigen Kompilierungsprozesses. Als Anfangsarbeit weist das Paper jedoch offensichtliche Mängel in der Breite und Tiefe der experimentellen Bewertung auf, und die Halbautomatisierung der DAE-Optimierung begrenzt die Benutzerfreundlichkeit. Das Tool hat direkten Wert für HardCilk-Benutzer und TLP-Forscher, erfordert aber weitere Reifung für breite Anwendung. Empfohlene zukünftige Arbeiten sollten sich auf automatisierte Optimierungserkennung, erweiterte Benchmark-Bewertung und Open-Source-Veröffentlichung konzentrieren, um Community-Verifikation und Verbesserung zu fördern.