Christian-Ioan SzaszSibiu, Româniadeschis la lucru remote

Project 01

Stack86

Un IDE în browser care compilează nouă limbaje în assembly 8086 și rulează rezultatul pe un emulator pe care îl poți parcurge instrucțiune cu instrucțiune.

3 minute readC#, TypeScript, 8086 assembly

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

Vezi repository-ul demo-uluiDeschide demo-ul live

stack86 · compilator și emulator
IDE-ul Stack86: sursa C în stânga, assembly-ul 8086 generat în dreapta și un log de build care arată etapele pipeline-ului.

Privire de ansamblu

Un IDE în browser care compilează nouă limbaje în assembly 8086 și rulează rezultatul pe un emulator pe care îl poți parcurge instrucțiune cu instrucțiune.

Ai scris o buclă for de zece mii de ori. Stack86 îți arată ce face, de fapt, mașina cu ea.

  • Scrie cod în C, C++, C#, Go, Java, JavaScript, Python, Rust sau TypeScript
  • Citește codul assembly 8086 rezultat
  • Parcurge-l pas cu pas și urmărește cum se schimbă registrele, flag-urile, stiva și memoria
Licența de probă compilează C; licența completă, toate cele nouă limbaje.
RolSingurul autor: backend, frontend și toolchain
StructurăMonolit modular ASP.NET Core plus un SPA Angular 22
Limbaje de intrareC, C++, C#, Go, Java, JavaScript, Python, Rust, TypeScript
Platformă țintăAssembly 8086, executat de un emulator din browser
Teste956 de metode de test pe backend, 864 de spec-uri pe frontend, 100 end-to-end
Repository publicO variantă redusă, fără autentificare și salvare

Arhitectură

Un monolit modular, cu o singură direcție a dependențelor și o singură graniță de proces, aleasă intenționat.

Linia punctată e granița de proces: compilare pe server, execuție în browser.
  • Compilarea rămâne pe server, unde fiecare limbaj e verificat de propriul toolchain: TCC, javac, rustc, gofmt, Node, Python.
  • Execuția rămâne în browser, pentru că un buton Step ținut apăsat nu poate aștepta după rețea.
  • Fiecare etapă e un filtru, iar fiecare limbaj își ia lanțul de etape dintr-un singur registry, așa că toată a doua jumătate e comună.
  • Am scris stratul CQRS în loc să iau MediatR: două interfețe și un dispatcher erau tot ce trebuia.

Proiectarea domeniului

O reprezentare intermediară mică, în care trebuie să încapă orice limbaj.

Nouă limbaje la intrare, un singur IR la mijloc, un singur back end 8086 la ieșire.
  • Front end-urile nu știu nimic despre 8086. Produc IR și diagnostice, nimic altceva.
  • Registrele, segmentele și INT 21h există doar în spatele generatorului de cod.
  • Ca să adaugi un limbaj, îl înregistrezi în registry, nu scrii un caz special.

Fluxul de date și de control

Un build, de la apăsarea unei taste până la emulatorul care rulează pas cu pas.

Log-ul se actualizează cât timp rulează etapele; după aceea, fiecare pas e un simplu apel local de funcție.

Strategia de testare

956 de teste de backend, 864 de spec-uri de frontend, 100 end-to-end și un build care pică la orice avertisment.

  • O etapă din pipeline sau un front end înseamnă test unitar. Rutarea, autentificarea sau baza de date îl fac test de integrare.
  • Testele verzi nu au observat că editorul se strânsese la cinci pixeli, așa că păstrez și capturi de ecran Playwright.
  • StyleCop și ESLint, cu avertismentele tratate ca erori și fără nicio portiță pentru any, în niciunul dintre limbaje.

Ce aș schimba

  • Încă nu am un alocator de registre: fiecare valoare primește un slot pe stivă, așa că assembly-ul e de două-trei ori mai lung decât e nevoie.
  • Optimizatorul face o singură trecere, de copy propagation. Constant folding și eliminarea dead store-urilor încă lipsesc.
  • Dacă pe server lipsește un toolchain, eroarea arată ca un bug de compilator, nu ca o dependență lipsă.
  • Limbajele nu sunt acoperite la fel de bine, iar selectorul de limbaj ar trebui să spună asta.