Christian-Ioan SzaszSibiu, Rumänienoffen für Remote-Arbeit

Project 01

Stack86

Eine Browser-IDE, die neun Sprachen zu 8086-Assembler übersetzt und das Ergebnis anschließend auf einem Emulator ausführt, den man Schritt für Schritt durchgehen kann.

2 minute readC#, TypeScript, 8086 assembly

  • .NET 10
  • Angular 22
  • CQRS
  • NgRx
  • Monaco
  • EF Core
  • Polly
  • Vite

Demo-Repository ansehenLive-Demo öffnen

stack86 · Compiler und Emulator
Die Stack86-IDE: C-Quelltext links, der erzeugte 8086-Assembler rechts und ein Build-Log, das die Pipeline mitschreibt.

Überblick

Eine Browser-IDE, die neun Sprachen zu 8086-Assembler übersetzt und das Ergebnis anschließend auf einem Emulator ausführt, den man Schritt für Schritt durchgehen kann.

Du hast zehntausendmal eine for-Schleife geschrieben. Stack86 zeigt dir, was die Maschine tatsächlich damit macht.

  • In C, C++, C#, Go, Java, JavaScript, Python, Rust oder TypeScript schreiben
  • Den erzeugten 8086-Assembler lesen
  • Schritt für Schritt durchgehen und sehen, wie sich Register, Flags, Stack und Speicher ändern
Eine Trial-Lizenz kompiliert C, eine Volllizenz alle neun Sprachen.
RolleAlleinentwickler: Backend, Frontend und Toolchain
AufbauModularer ASP.NET-Core-Monolith plus eine Angular-22-SPA
EingabesprachenC, C++, C#, Go, Java, JavaScript, Python, Rust, TypeScript
Zielplattform8086-Assembler, ausgeführt von einem Emulator im Browser
Tests956 Backend-Testmethoden, 864 Frontend-Specs, 100 End-to-End
Öffentliches RepositoryEine reduzierte Variante: Anmeldung und Persistenz entfernt

Architektur

Ein modularer Monolith mit einer Abhängigkeitsrichtung und einer bewusst gezogenen Prozessgrenze.

Die gestrichelte Linie ist die Prozessgrenze: auf dem Server kompilieren, im Browser ausführen.
  • Kompilieren bleibt auf dem Server, wo jede Sprache von ihrer eigenen Toolchain geprüft wird: TCC, javac, rustc, gofmt, Node, Python.
  • Ausführen bleibt im Browser, weil ein gedrückt gehaltener Step-Knopf nicht auf das Netzwerk warten kann.
  • Jede Stufe ist ein Filter, und jede Sprache holt ihre Kette aus einer Registry, deshalb ist die ganze zweite Hälfte gemeinsam.
  • Die CQRS-Schicht habe ich selbst geschrieben statt MediatR zu nehmen: Zwei Interfaces und ein Dispatcher reichten.

Domänendesign

Eine kleine Zwischendarstellung, in die jede Sprache passen muss.

Neun Sprachen hinein, eine IR in der Mitte, ein 8086-Backend hinaus.
  • Frontends wissen nichts über den 8086. Sie erzeugen IR und Diagnosen, sonst nichts.
  • Register, Segmente und INT 21h leben nur hinter dem Codegenerator.
  • Eine Sprache einzubinden ist ein Eintrag in der Registry, kein Sonderfall.

Daten- und Kontrollfluss

Ein Build, vom Tastendruck bis zum Emulator im Einzelschritt.

Das Log aktualisiert sich, während die Stufen laufen; danach ist jeder Schritt ein lokaler Funktionsaufruf.

Teststrategie

956 Backend-Tests, 864 Frontend-Specs, 100 End-to-End-Tests und ein Build, der bei jeder Warnung fehlschlägt.

  • Eine Pipeline-Stufe oder ein Frontend ist ein Unit-Test. Routing, Auth oder die Datenbank machen daraus einen Integrationstest.
  • Grüne Tests haben nicht erkannt, dass der Editor auf fünf Pixel geschrumpft war. Deshalb liegen Playwright-Screenshots daneben.
  • StyleCop und ESLint mit Warnungen als Fehler und ohne Hintertür über any, in beiden Sprachen.

Was ich ändern würde

  • Noch kein Register-Allokator: Jeder Wert bekommt einen Stack-Slot, deshalb ist der Assembler-Code zwei- bis dreimal länger als nötig.
  • Der Optimierer ist ein einziger Copy-Propagation-Durchlauf. Constant Folding und Dead-Store-Elimination fehlen noch.
  • Fehlt auf dem Server eine Toolchain, sieht das wie ein Compilerfehler aus, nicht wie eine fehlende Abhängigkeit.
  • Die Sprachen sind unterschiedlich weit ausgebaut, und die Sprachauswahl sollte das anzeigen.