Emulazione di MMU che accede al contenuto dei registri

but that seems unwieldy

No, è esattamente come dovrebbe essere fatto. Hai bisogno di un argomento per un metodo? Passa l'argomento. È una funzionalità linguistica di base! Un esempio di come questo può essere utile è se la MMU carica dalla memoria dove il puntatore è un valore nel registro - potrebbe trattarsi di qualsiasi registro. Passa semplicemente nel registro appropriato come argomento del metodo.

Gli argomenti del costruttore non dovrebbero essere realmente usati per dipendenze casuali; dovrebbero essere usati solo per cose in cui la classe fondamentalmente non può esistere o ha senso senza di loro.

Fondamentalmente, gran parte dei terribili errori e delle persone che progettano lo fanno è solo perché odiano il passaggio dei parametri. Ma in realtà le altre alternative sono peggiori . Fanno solo molto più male a lungo termine e sembrano facili a breve termine. È di gran lunga la cosa migliore per passare il parametro.

La seconda parte della tua domanda si legge come il classico riferimento al problema della copia con gli oggetti. Se si inizializza la classe MMU con un riferimento ai registri, tale riferimento punta al vero oggetto del registro (si pensi a un riferimento come un puntatore automaticamente non referenziato). Se copi l'oggetto registro nel tuo costruttore, questo è tutto ciò che hai - una copia istantanea dello stato al momento della costruzione.

Tipicamente la CPU ha un "pezzo interno" che ha registri, esegue istruzioni, ecc. L'unica comunicazione tra "pezzo interno" e cose al di fuori di esso sono "richieste di lettura" e "richieste di scrittura". Nulla al di fuori del "pezzo interno" ha accesso ai registri del pezzo interno, alle unità di esecuzione, ecc.

Se non ci sono MMU, le "richieste di lettura" e le "richieste di scrittura" emesse dal "pezzo interno" si riferiscono ad indirizzi fisici (ad es. quale posizione viene letta / scritta nella RAM effettiva).

Se c'è una MMU, allora si trova tra il "pezzo interno" e l'altra roba al di fuori del "pezzo interno" (il controller RAM, ecc.) e modifica gli indirizzi in "richieste di lettura" e "richieste di scrittura" in qualche modo. In questo caso, le richieste di lettura / scrittura dal "pezzo interno" sono indirizzi virtuali e la MMU (al di fuori del "pezzo interno") le converte in indirizzi fisici.

Come ogni cosa al di fuori del "pezzo interno", la MMU non ha accesso ai registri e non c'è motivo di volere l'accesso ai registri.

Nota: per un sistema pratico le cose diventano più complesse, ad es. diversi tipi di spazi di indirizzamento (porte IO, spazio di configurazione PCI, ecc.), dispositivi (e relativi registri) mappati nello / o spazio indirizzo in vari modi, vari tipi di cache in vari luoghi e cose che agiscono un po 'come rete / router di pacchetti (bridge PCI), ecc. Con l'aumentare della complessità tende a pensare meglio al sistema come a una sorta di rete, in cui si hanno pezzi indipendenti collegati da bus e / o collegamenti e dove ogni pezzo indipendente invia pacchetti di richiesta ad altri pezzi, risponde ai pacchetti ricevuti da altri pezzi e invia pacchetti di risposta ad altri pezzi. Per lo stesso motivo, per un modello più realistico nel software, sarebbe meglio utilizzare (ad esempio) un approccio "un thread per pezzo indipendente" in cui i thread inviano messaggi (o pacchetti in senso letterale "pacchetti UDP / IP") a l'un l'altro. Essenzialmente, sarebbe meglio usare il modello attore e non OOP.