Assembler - Christian-Ioan Szasz

Aplicația desktop Assembler: editorul de sursă, schema procesorului cu magistrale și registre și panourile suprapuse de memorie, cod mașină și microcod. — assembler · simulator pentru desktop

Privire de ansamblu

Un simulator de procesor pentru desktop care asamblează un set de 47 de instrucțiuni și le execută pas cu pas, la nivel de microcod, evidențiind calea de date pe măsură ce avansează.

Un student scrie zece linii de assembly, apasă Step și urmărește cum o valoare trece pe magistrală într-un registru.

Scrie sau deschide cod assembly în editor
Rulează, pune pe pauză, avansează pas cu pas sau resetează, la viteza pe care o alegi
Urmărește cum se aprind pe schema procesorului magistralele și registrele active

Pe scurt
Rol	Singurul autor; o rescriere pe straturi a unui simulator didactic
Structură	Patru proiecte, săgeata dependențelor într-o singură direcție, domeniul nu depinde de nimic
Set de instrucțiuni	47 de mnemonice în patru clase de codificare, patru moduri de adresare
Platforme țintă	Windows și Mac Catalyst, engleză și română
Teste	83 de metode de test, cu 80 de rânduri de date, în trei proiecte de test
Control al calității	StyleCop și analizoarele .NET, avertismentele tratate ca erori
Sursă	Cod sursă închis

Arhitectură

Patru straturi și un domeniu care ar putea rula mâine dintr-o consolă.

textDirecția dependențelor: Maui către Presentation, către UseCases, către Domain

src/
├── Assembler.Domain/        Pure CLR: ISA, assembler, microcode, simulator core
├── Assembler.UseCases/      Facades and fluent builders over the domain
├── Assembler.Presentation/  AppPresenter (MVP), AppStateMachine (FSM), view ports
└── Assembler.Maui/          .NET MAUI: one ViewModel per pane, drawn schematic, dialogs

Domeniul nu folosește niciun framework de UI și nu pornește timere. Întârzierile vin de la un clock injectat.
Orice efect iese din domeniu ca eveniment tipizat, printr-un channel.
Am ales MVP în locul MVVM-ului simplu, ca un singur presenter să țină coordonarea, nu fiecare panou.
Singurele pachete sunt MAUI și CommunityToolkit.Mvvm. Schema e desenată de mână.

Proiectarea domeniului

Un set de instrucțiuni în care opcode-ul e calculat, nu căutat într-un tabel.

47 de mnemonice în patru clase de codificare, patru moduri de adresare, șaisprezece registre.
Fiecare instrucțiune rulează ca un program de microcod care specifică exact ce magistrală folosește.
Domeniul spune „magistrala S a fost activată”, niciodată „evidențiază asta”, așa că desenul se poate schimba fără să ating simulatorul.

Fluxul de date și de control

O apăsare pe Step, de la buton până la magistrala aprinsă.

Presenter-ul trimite un trigger mașinii de stări. O tranziție respinsă nu face nimic.
Simulatorul aduce, decodifică și rulează microcodul unei instrucțiuni.
Fiecare pas publică ce a atins: magistrală, registre, flag-uri.
Presenter-ul trimite fiecare eveniment panourilor deschise, iar schema se redesenează.

Strategia de testare

Trei proiecte de teste sub UI și niciunul deasupra presenter-ului.

O suită golden-encoding fixează exact codul mașină în care se asamblează fiecare instrucțiune.
Mașina de stări e testată exhaustiv: 42 de rânduri, fiecare tranziție acceptată și respinsă.
Datorită clock-ului injectat, o rulare de douăzeci de secunde se termină în microsecunde în teste.
StyleCop și analizoarele .NET, cu avertismentele tratate ca erori. Un membru nedocumentat pică build-ul.

Ce aș schimba

Schema își păstrează paleta deschisă, deși toate celelalte panouri sunt întunecate. Ar trebui să urmeze tema.
Nimic de deasupra presenter-ului nu e testat. Un smoke test automatizat e următorul pas realist.
Mașina de stări nu are acțiuni de intrare sau ieșire: merge la nouă stări, nu și la treizeci.
Catalogul de microcod e încorporat. Studenții ar câștiga cel mai mult dacă l-ar putea încărca dintr-un fișier.