Miért építek olyan CPU-t, ami natívan futtatja a .NET-et

A kérdés

Mi lenne, ha a C# kódod közvetlenül a szilíciumon futna, JIT nélkül, interpreter nélkül, futtatókörnyezet nélkül? Mi lenne, ha maga a CPU értené a .NET bytecode-ot — minden ldc.i4-et, minden call-t, minden stloc-ot — natív utasításkészletként?

Ez nem gondolatkísérlet. Pontosan ezt építem az elmúlt hónapokban, és a referencia-implementáció már kész: 48 opkód, 259+ sikeres teszt, működő linker, CLI futtatóeszköz, és egy Verilog ALU modul 41 zöld cocotb teszttel. A projekt neve CLI-CPU, és teljes egészében nyílt forráskódú, CERN-OHL-S v2 licenc alatt.

De mielőtt elmagyaráznám, mi a CLI-CPU, hadd meséljek arról, miért bukott el minden korábbi próbálkozás — és miért más ez most.

A bytecode-hardver kísértetei

1997-ben a Sun Microsystems kiadta a picoJava-t — egy processzort, ami képes volt Java bytecode-ot közvetlenül hardverben végrehajtani. Az ötlet meggyőző volt: hagyjuk ki az interpretálás és a JIT-fordítás többletköltségét, futtassuk a Java-t natív sebességgel. A Sun két iterációt épített (picoJava-I és picoJava-II), licencelte a dizájnt, és várta, hogy a világ átvegye.

A világ nem vette át. 2001-re a HotSpot JIT-fordítója már a legtöbb terheléstípuson túlteljesítette a picoJava-t. A hardveres bytecode-végrehajtás nem tudott lépést tartani egy szoftveres JIT-tel, ami képes volt specializálni, inline-olni és a program tényleges futási viselkedésére optimalizálni. A Sun csendben kivezette az architektúrát.

Az ARM más megközelítést próbált a Jazelle DBX-szel (2001): egy dedikált bytecode-CPU helyett egy speciális végrehajtási módot adott a meglévő ARM magokhoz, ami hardveres gyorsítással tudott Java bytecode-ot értelmezni. A Jazelle okos volt — összetett opkódoknál visszaesett szoftverre, és csak a gyakoriakat gyorsította hardverből. Több százmillió ARM9-es és ARM11-es chipben szállították.

És mégis, a Jazelle is elbukott. Amikor az ARM bevezette a Thumb-2-t, majd később az egyre kifinomultabb soron-kívüli (out-of-order) pipeline-nal rendelkező Cortex-A sorozatot, a JIT-megközelítés (Dalvik, majd ART az Androidon) egyértelműen nyert. A Jazelle-t elavultnak nyilvánították, majd gyakorlatilag elhagyták. Az utolsó ARM architektúra, ami tartalmazta, az ARMv7 volt. Az ARMv8 (AArch64) teljes egészében elhagyta.

A tanulság egyértelműnek tűnt: az általános célú hardveren futó szoftveres JIT mindig legyőzi a dedikált bytecode-hardvert. A JIT alkalmazkodik; a szilícium nem. Ügy lezárva.

Csakhogy ez a tanulság téves. Pontosabban: hiányos. A picoJava és a Jazelle nem azért bukott el, mert a bytecode-hardver rossz ötlet — hanem azért, mert rossz tengely mentén versenyeztek.

Rossz verseny

Mind a picoJava, mind a Jazelle az általános célú CPU-kat próbálta legyőzni egymagos teljesítményben. Ez mindig vesztes csata volt. Egy modern, soron-kívüli végrehajtású CPU kifinomult JIT-fordítóval képes kódútvonalakat specializálni, hívásokat devirtualizálni, holt kódot eliminálni, és több ezer mikroarchitekturális trükköt alkalmazni, amivel egy egyszerű bytecode-pipeline nem veheti fel a versenyt. A JIT látja a futásidejű viselkedést; a hardver csak a statikus utasításokat.

De az egymagos teljesítmény már évek óta nem a legfontosabb mérőszám. A Dennard-skálázás 2006 körül véget ért. Az órajelek beálltak. Felütötte a fejét a teljesítmény-fal. Az egész ipar a többmagos irányba fordult, és azóta is küzd a következményekkel.

A probléma az, hogy a hagyományos értelemben vett többmagos feldolgozás — osztott memória, gyorsítótár-koherencia, mutex-zárak — nem skálázódik. Magok hozzáadása egy osztott memóriájú rendszerhez legjobb esetben Amdahl-törvényt követ, legrosszabb esetben katasztrofális versengéshez vezet. A MESI protokoll (és leszármazottai), ami a magok közötti gyorsítótár-koherenciát biztosítja, egyre abszurdabb hányadát emészti fel a chipterületnek, az energiabudgetnek és a tervezési komplexitásnak, ahogy nő a magok száma. Az Intel mesh összekötése szerver chipeken, az AMD Infinity Fabric, az Apple rendszerszintű gyorsítótára — ezek mind hősi mérnöki erőfeszítések egy alapvető architekturális hiba elfedésére: az osztott, módosítható állapot nem skálázódik.

Itt lép be a CLI-CPU — nem gyorsabb egymagos bytecode-processzorként, hanem alapvetően más architektúraként.

Shared-nothing: az egyetlen út előre

A CLI-CPU-ban nincs osztott memória. Pont. Minden mag saját privát SRAM-mal rendelkezik — kód, adat és verem — és semmilyen más mag nem férhet hozzá. Ez nem szoftveres konvenció; ez a szilícium fizikai tulajdonsága. Nincsenek buszvonalak, amelyek az egyik mag memóriáját a másikéhoz kötnék.

A magok kizárólag hardveres mailbox FIFO-kon keresztül kommunikálnak. Egy mag egy 32 bites üzenetet ír a kimenő mailbox-ába; a hardver kézbesíti a célmag bejövő mailbox-ába. A küldő mag nem blokkolódik. A fogadó mag felébredl alvásból, amikor üzenet érkezik, feldolgozza, és visszaalszik. Ez az actor modell szilíciumban.

„A jelenlegi szoftverrendszerek alapvetően hibás modellekre épülnek. Olyan hardver kell, ahol minden mag egy actor."
— Joe Armstrong, az Erlang megalkotója, 2014

Ennek a tervezési döntésnek mélyreható következményei vannak:

• Nincs gyorsítótár-koherencia protokoll. Nulla. Semmi. Nincs MESI, nincs MOESI, nincs könyvtáralapú koherencia. Már ez önmagában hatalmas chipterületet és energiát takarít meg.
• Nincs zár, nincs mutex, nincs atomi művelet. Nincs osztott állapot, amit védeni kellene. Az adatverseny fizikailag lehetetlen.
• Lineáris skálázás. Több mag hozzáadása arányosan több számítási kapacitást ad. Nincs Amdahl-szűk keresztmetszet, mert nincs soros szakasz — minden mag független.
• Determinisztikus végrehajtás. Minden mag viselkedése kizárólag a kódjától és a bejövő üzeneteitől függ. Nincsenek időzítésfüggő hibák, nincsenek heisenbugok, nincsenek memória-rendezési meglepetések.
• Eseményvezérelt energiaprofil. A magok alapértelmezetten alszanak. Mailbox-megszakításra ébrednek, feldolgozzák az üzenetet, és visszaalszanak. Az üresjárati fogyasztás közelít a nullához.

Ez szoftverben nem új ötlet. Az Erlang 1986 óta csinálja. Az Akka (2009) és az Akka.NET (2014) elhozta a JVM-re és a .NET ökoszisztémába. Az Orleans (2015) a mainstream C# fejlesztők számára is elérhetővé tette. Az actor modell éles környezetben, hatalmas léptékben bizonyított — WhatsApp (Erlang), Discord (Elixir), Microsoft Azure (Orleans), és számtalan más rendszer.

De mindezek hagyományos, osztott memóriájú hardveren futnak, ami azt jelenti, hogy a futtatókörnyezetnek szoftveres absztrakciókkal kell szimulálnia az üzenet-izolációt — szálkészletek, mailbox-sorok, GC-terhelés, ütemező-költség. A CLI-CPU ezt az egész réteget eltávolítja. A hardver maga a futtatókörnyezet.

Miért most?

A picoJava 1997-ben egyetlen feltétellel sem rendelkezett, ami ehhez a megközelítéshez szükséges. 2026-ban mindegyik adott:

• Nyílt PDK-k. A Google és a SkyWater 2020-ban kiadta a Sky130 process design kit-et. Az IHP követte az SG13G2-vel. A történelemben először bárki tervezhet és gyárthat chipet milliós licencdíjak nélkül. A CLI-CPU teljes szilícium-útvonala nyílt eszközöket használ: Yosys szintézishez, OpenLane2 elhelyezéshez és huzalozáshoz, Magic DRC/LVS-hez.
• Tiny Tapeout. Matt Venn Tiny Tapeout projektje demokratizálta a chipgyártást. Körülbelül 150 dollárért egy kis dizájn valódi Sky130 szilíciumra kerülhet. A CLI-CPU első fizikai chipje (egyetlen Nano core + hardveres mailbox) ezen a programon keresztül kerül gyártásra.
• Megfizethető FPGA-k. A MicroPhase A7-Lite kártya Xilinx XC7A200T-vel — 200 000 logikai cella — körülbelül 320 dollárba kerül. Három ilyen kártya Etherneten összekötve egy több kártyás Cognitive Fabric hálózatot alkothat, 1000 dollár alatt. Ez egy évtizeddel ezelőtt elképzelhetetlen volt.
• Az actor modell mainstreamé vált. Akka.NET, Orleans, Dapr, Proto.Actor — a .NET ökoszisztéma befogadta az üzenetküldésen alapuló párhuzamosságot. Nyolcmillió .NET fejlesztő már olyan kódot ír, ami természetesen illeszkedik a CLI-CPU végrehajtási modelljéhez. Nem kell új nyelvet vagy paradigmát tanulniuk; csak olyan hardver kell, ami natívan futtatja.
• A Dennard-skálázás halott. Az órajelek 20 éve stagnálnak. A nagyobb teljesítményhez vezető egyetlen út a több mag. De az osztott memóriájú többmagos rendszerek csökkenő hozadékot mutatnak. A shared-nothing sokmagos feldolgozás a logikus következő lépés, és a CLI-CPU az alapoktól erre tervezve készült.

Mit építettünk eddig

A CLI-CPU nem whitepaper. Nem „vízió dokumentum" a jövőbeli lehetőségekről szóló kézlegyintéssel. Működő kód, tesztelt kód, és — egyre inkább — működő hardver leírás.

Az F1.5 fázis kész. Ez magában foglalja:

• Egy referencia szimulátort (TCpu), ami mind a 48 CIL-T0 opkódot implementálja — az ECMA-335 CIL egész szám részhalmazát, plusz mailbox MMIO kiterjesztéseket. A szimulátor a teljes memóriatérképet modellezi: CODE, DATA, STACK és MMIO régiókat.
• Egy CIL-T0 linkert (TCliCpuLinker), ami egy szabványos .NET assembly-t (.dll, Roslyn fordítás) átalakít lapos bináris formátumba (.t0), amiből a hardver bootolhat. Nincs transzláció — a .dll-ben lévő CIL opkódok ugyanazok, amiket a CPU végrehajt.
• Egy CLI futtatóeszközt run és link parancsokkal.
• 259+ xUnit tesztet, ami lefedi az összes opkódot, minden trap-feltételt, minden szélsőséges esetet. Szigorú TDD — minden teszt az implementáció előtt készült.
• Egy Verilog ALU modult teljes cocotb tesztpaddal (41/41 teszt zöld). Ez az RTL fázis (F2) kezdete.

A teljes kódbázis — szimulátor, linker, futtatóeszköz, tesztek, Verilog, cocotb, dokumentáció — nyílt forráskódú a GitHubon.

A Cognitive Fabric One vízió

A célchip — Cognitive Fabric One — a Sky130 technológiára tervezett, hozzávetőleg 15 mm² területen:

	Cognitive Fabric One	Tipikus RISC-V SoC
Magok	6 Rich + 16 Nano + 1 Secure	4-8 homogén
Memória modell	Privát SRAM magonként, nincs osztott memória	Osztott L1/L2 gyorsítótár-hierarchia
Magok közti komm.	Hardveres mailbox FIFO-k (OPI busz)	Osztott memória + gyorsítótár-koherencia
Koherencia-költség	Nulla	Jelentős (MESI/könyvtáralapú)
Skálázási viselkedés	Lineáris a magszámmal	Szublineáris (Amdahl-törvény)
Üresjárati fogyasztás	Közel nulla (alvás mailbox-ig)	Jelentős (gyorsítótár, koherencia-logika)
Biztonsági izoláció	Fizikai (nincs osztott memória)	Szoftveres (TrustZone, TEE)
ISA	CIL (verem, kompakt)	RISC-V (regiszter, szélesebb kódolás)
I/O	USB 1.1 FS, UART, SPI, GPIO	Változó

A Rich core-ok a felügyeleti logikát, összetett domain kódot, GC-kezelt objektumokat, lebegőpontos műveleteket és kivételkezelést végzik — a teljes ECMA-335 CIL utasításkészlettel (~220 opkód). A Nano core-ok apróak (~10k standard cella egyenként) és a CIL-T0 egész szám részhalmazát futtatják — ideálisak dolgozókhoz, neuronokhoz, szűrőkhöz, egyszerű aktorokhoz. A Secure Core egy megerősített Rich core kriptográfiai gyorsítással, TRNG-vel és PUF-fal — az egész fabric bizalmi horgonypontja.

Ez a heterogén kialakítás hasonló az ARM big.LITTLE-höz vagy az Apple P-core + E-core megoldásához, de a .NET világra alkalmazva. Egy C# fejlesztő [RunsOn(CoreType.Nano)] vagy [RunsOn(CoreType.Rich)] attribútummal jelöli az osztályait, és egy Roslyn forrásgenerátor fordítási időben ellenőrzi, hogy a Nano-ra célzott kód a CIL-T0 részhalmazon belül marad.

Biztonság: dizájn szintjén immunis

Az elmúlt évtized minden jelentős CPU-sebezhetősége — Spectre, Meltdown, L1 Terminal Fault, Rowhammer, Retbleed, Inception — három dolog egyikét használja ki: spekulatív végrehajtás, osztott gyorsítótár vagy osztott memória. A CLI-CPU-ban ezek egyike sincs.

• Nincs spekulatív végrehajtás. A CLI-CPU magok egyszerűek, sorrendben végrehajtók, determinisztikusak. Nincs elágazás-előrejelző, amit mérgezni lehetne, nincs spekulatív betöltés, ami oldalsó csatornán szivárogtathatna adatot.
• Nincs osztott gyorsítótár. Minden mag saját privát SRAM-mal rendelkezik. Nincs L2, nincs L3, nincs rendszerszintű gyorsítótár. Nincs Flush+Reload, nincs Prime+Probe, nincsenek gyorsítótár-időzítési támadások.
• Nincs osztott memória. A magok közötti információáramlás kizárólag explicit mailbox-üzenetekre korlátozódik. Egy kompromittált mag nem tudja kiolvasni egy másik mag állapotát — se szoftveren keresztül, se mikroarchitekturális oldalsó csatornákon, se bármi máson, ami a fizikai dekapsulációnál kisebb beavatkozást igényel.

Ezen felül a CIL végrehajtási modell hardveresen kényszerített típusbiztonságot és vezérlésfolyam-integritást biztosít. Minden memória-hozzáférés hardverben határellenőrzött. Minden metódushívás a deklarált szignatúra alapján verifikált. A verem-túlcsordulás és -alulcsordulás hardveres trap-et generál. ROP és JOP támadások lehetetlenek, mert a hardver kikényszeríti, hogy a végrehajtás csak érvényes metódus-belépési pontokra ugorhat.

Ez nem utólag rácsapott biztonság. Ez a biztonság mint a szilícium fizikai tulajdonsága. Nem lehet körbefoltozni, és nem lehet körbe kihasználni.

Mi jön ezután

A következő mérföldkövek az ütemtervben:

• F2 — RTL: Egyetlen Nano core teljes Verilog/Amaranth HDL implementációja. Minden opkód verifikálása a C# szimulátorral, cocotb golden-vector teszteléssel. Szintézis Sky130-ra Yosys-szal.
• F2.7 — FPGA validáció: Az egyetlen Nano core futtatása valós FPGA-n (MicroPhase A7-Lite XC7A200T) a szilícium tape-out előtt. Fibonacci(20) UART-on, valós hardveren. Elv: nincs tape-out FPGA validáció nélkül.
• F3 — Első szilícium: Az FPGA-n validált Nano core + hardveres mailbox tape-out a Tiny Tapeout-on. Fibonacci(20) és egy „echo neuron" demó valódi szilíciumon. A történelem első fizikai CIL-natív processzora.
• F4 — Cognitive Fabric fordulópont: 4 Nano core demonstrálása FPGA-n, hardveres mailbox-okon keresztüli kommunikációval, shared-nothing eseményvezérelt fabric-ban. Az architektúra skálázhatóságának bizonyítása.
• F5 — Rich Core: A teljes CIL utasításkészlet hozzáadása — objektumok, GC-támogatás, kivételkezelés, FPU. Heterogén Nano + Rich működés demonstrálása.
• F6 — Cognitive Fabric One: A célchip. Először FPGA-n (több kártyás hálózat), majd valódi szilíciumon ChipIgnite vagy IHP MPW programon keresztül.
• F7 — Neuron OS: Egy actor-alapú operációs rendszer, ami az alapoktól shared-nothing hardverre tervezve készül. Nincs kernel. Nincsenek rendszerhívások. Nincs virtuális memória. Csak aktorok, üzeneteken keresztül kommunikálva.

A teljes projekt — hardver, szoftver, dokumentáció — nyílt forráskódú és az is marad, CERN-OHL-S v2 licenc alatt.