( apal | 2022. 09. 30., p – 17:22 )

Az MMU nagyon kicsi reakcióidővel kell hogy működjön, ugye minden memória művelet előtt ott van.

Azert ez nem teljesen igy van - vagyis pontosan igy van, attol fugg honnan nezzuk :) Azaz: ha van egy cimzesed, es feloldhato a fizikai cim, akkor nem lesz semmivel sem lassabb mint egy MMU nelkuli rendszer. Ha pedig nem oldhato fel, akkor a CPU/MMU general egy kivetelt. Ezt az oprendszer elkapja es megprobalja lerendezni a dolgot (pl alalapoz fizikai memoriat, visszaolvassa a swap-bol, barmi). Ha sikerul, akkor jo, ha nem, akkor meg jon a segmentation fault. Nyilvan ez csak egy egyszerusitett kep, mert van meg DMA is meg egyeb hasonlo nyalanksag (de az tisztan oprendszer oldalon van), plusz a memoria-eleresnek is tobb modja lehet (read, write, execute), de az alapelv az ez: a cimbuszra kimegy a request (address + alignment + access mode) , az MMU-n atfolyik, par ciklussal kesobb pedig visszajon amit kert (addig meg ugye wait cycle-t kap vissza a CPU). Vagy megy a megszakitas a CPU-nak. 

Szerintem a fejlődés ésszerű iránya az volna, ha minden szoftver valamilyen "virtualizált nyelven" íródna

Na, viszont a fentiek tukreben pont ez lesz baromira lassu ;) Ha minden i/o access elott meg egy komplett MMU lookupot is le kellene szimulalnod szoftverbol, es nincs hozza offload hardvered. Es ezek tipikusan olyan dolgok amiket cel-hardverbol sokkal gyorsabban lehet tolni mint szoftverbol (lasd pl bitmuveletes dolgok meg popcount meg finite field muveletek meg hasonlo operaciok, nem veletlenul jelentek meg instruction set tamogatassal a crypto utasitasok is eleg hamar).