Juuri nC$in! TC$mC$ on aivan tC$ydellinen vertauskuva ja kiteyttC$C$
X-MESH-BASICin sielun. Se ei ole perinteinen ohjelmointikieli, vaan **The Dark
Meshin oma CISC-tyyppinen virtuaaliprosessori (vCPU)**.

Kun ajattelemme sitC$ prosessorina, kaikki tC$hC$n asti rakentamamme asiat
loksahtavat loogisesti paikoilleen:

* **Rivinumerot:** Ovat suoraan prosessorin ohjelmalaskurin (Program Counter,
PC) muistiosoitteita. `GOTO`, `GOSUB` ja `RESTORE` siirtC$vC$t suoraan
suoritusosoitinta.
* **Komennot (OMEGA, KV, HTTP):** EivC$t ole aliohjelmakutsuja, vaan
mikrokoodattuja, laajoja konekielikC$skyjC$ (Opcodes), jotka suorittavat
valtavia asynkronisia taustatehtC$viC$ yhdellC$ BASIC-kellojaksolla.
* **Taustaverkot (M-BUS, OMEGANET):** Toimivat kuin laitteiston DMA-ohjain
(Direct Memory Access), joka siirtC$C$ dataa verkkokortilta puskureihin
riippumatta siitC$, mitC$ prosessori tekee.
* **SUSPEND ja EVENT POLL:** Ovat aitoja laitteistokeskeytyksiC$ (Hardware
Interrupts). Prosessori siirtyy vC$hC$virtaiseen tilaan (vastaa aitojen
prosessorien `WFI` eli Wait For Interrupt -kC$skyC$) ja herC$C$
nanosekunnissa, kun I/O-vC$ylC$ antaa keskeytyssignaalin.

TC$mC$ ajattelutapa tekee tuosta aiemmin ideoimastasi "jaetun muistin
mappaamisesta rivinumeroihin" tC$ysin luonnollisen ja arkkitehtuurisesti
oikeaoppisen askeleen. Verkosta valuva ZFS-striimi ei ole ohjelman kannalta
mikC$C$n erillinen JSON-paketti, vaan taustalla pyC6rivC$ verkkodaemon toimii
DMA-ohjaimena, joka kirjoittaa saapuvan datan suoraan virtuaaliprosessorin
muistiavaruuteen (esimerkiksi riveille `50000-59999`) reaaliajassa. Ohjelmoija
vain kC$C$ntC$C$ lukupC$C$n sinne ja antaa prosessorin raksuttaa.

Aloitetaanko tC$mC$n ainutlaatuisen Memory-Mapped DATA -arkkitehtuurin
(asynkronisen verkkostriimin sitominen lennossa pC$ivittyviksi BASIC-riveiksi)
protoilu suoraan X-MESH-BASICin ytimeen, vai viedC$C$nkC6 tuo CRM-asiakkaiden
vesiputous ensin loppuun asti johonkin lokaaliin tietokantaan tai
nC$yttC6liittymC$lle?