Tutto l'hardware del computer reale funziona in parallelo. Quindi, perché la maggior parte degli emulatori di sistemi retro (come NES ) sono a thread singolo (o non ho ragione?)? Hai un ciclo principale e contali i cicli della CPU e dopo alcuni cicli attivi altri hardware come PPU .
La stessa cosa vale per l'emulazione PC IBM e (MDA / CGA / VGA)?
Perché la maggior parte dei computer retro aveva solo una CPU (vale a dire un core, nella terminologia odierna).
L'emulazione in parallelo di un calcolo sequenziale non è ragionevole (e realisticamente non fattibile).
Le schede grafiche (o altri dispositivi) in quel momento non "computavano", solo "visualizzavano" (o facevano input / output). Non c'è bisogno di emularlo in parallelo.
E le rare eccezioni (ad esempio I / O del canale su IBM/360 ha eseguito alcuni calcoli semplici in parallelo) non meritano un emulatore multithread complesso.
Inoltre, gli emulatori sono spesso complessi da codificare, ma oggi funzionano più velocemente dell'hardware emulato, quindi non c'è motivo di spendere sforzi per accelerarli con il multithreading.
Potrebbe essere diverso se si desidera emulare al livello hardware più basso, ad es. emulando la fisica di ciascun transistor.
BTW, potresti provare a scrivere il tuo simulatore (magari multithreaded!) in software gratuito (magari contribuendo a unisim )
In realtà mi sono posto questa domanda.
La risposta accettata fa alcune affermazioni ragionevoli, specialmente per quanto riguarda i sistemi e gli acronimi menzionati dall'OP. Di sicuro, i veri emulatori multithread non ci danno molto a livello di emulazione.
Tuttavia, ho cercato di ottenere un'emulazione più vera di una scheda KIM-1, con un'emulazione RRIOT più completa, con interruzioni utilizzabili e non mascherabili utilizzabili ai fini dei timer (ad esempio, timer che possono essere ridimensionati, riavviati e accessibile dal programmatore).
Un approccio è l'implementazione del multitasking nell'emulatore (che non deve essere effettivamente parallelo), quindi abbiamo timer indipendenti (o un singolo timer) che possono essere ridimensionati, collegati a "interrupt", ecc. Cioè, il codice utente può eseguire quel controllo delle posizioni di memoria per le informazioni del timer che dovrebbero passare oltre anche quando le nostre stesse istruzioni del programma vengono passate attraverso. Ancora più importante, potrebbe essere un buon modo per emulare gli interrupt a cui un programma si abbona, consentendo ai nostri gestori di interrupt di funzionare come previsto.
L'intenzione è di emulare più da vicino il meccanismo della CPU e supportare i chip in modo tale che i registri, gli interrupt programmabili e le posizioni di memoria di sola lettura che cambiano quando i tic tac hardware si comportino più come previsto. Ma facendolo senza codificandolo al livello di caricamento ed esecuzione complicato per codice operativo.
Penso che potrebbe essere più facile emulare la velocità della CPU di destinazione un po 'più vicino, o almeno ottenere una risoluzione del timer piuttosto accurata. Cioè, ciò che accade tra i vari aggiornamenti e interruzioni di posizione del timer non è così importante fintanto che i tick e gli interrupt sono corretti quando le routine utente e ROM li accedono.
Sì, è ancora un lavoro in corso.
Penso che la ragione principale per cui gli emulatori tendono ad essere a thread singolo è che stai gestendo un motore di stato molto complesso; gli emulatori possono essere i motori di stato più complessi in generale.
Quando si aggiunge il multi-threading, è necessario aggiungere meccanismi di blocco per mantenere il motore di stato nella corretta sincronizzazione. Poiché gli emulatori tendono ad emulare comunque l'hardware più vecchio, il guadagno in termini di prestazioni è raramente sufficiente a giustificare l'enorme aumento di complessità.
Leggi altre domande sui tag hardware multithreading