Windows 95 mostrato in esecuzione su Nintendo 3DS: è il sogno dei retrogamer?

Un utente del forum GBATemp è riuscito ad eseguire Windows 95 su un Nintendo 3DS. Sebbene possa sembrare un esercizio di stile e poco altro, l'operazione potrebbe avere parecchi risvolti interessanti
di Nino Grasso pubblicata il 05 Gennaio 2016, alle 17:01 nel canale VideogamesNintendo
16 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoE con quella cache l2 potrei azzardare che rivaleggi o superi la ps vita, che ha un cortex a9 a 333-444 MHz e non 1-2 GHz come dicono i siti per boccaloni
non credo ci giri molto, se non roba dos o per windows 3.1
Esattamente.
E con quella cache l2 potrei azzardare che rivaleggi o superi la ps vita, che ha un cortex a9 a 333-444 MHz e non 1-2 GHz come dicono i siti per boccaloni
Beh, se le altre fonti dicono cazzate, non è che tu ne abbia portato qualcuna a tuo sostegno.
L'unico dato concreto è che dovrebbe essere un quad core, ma per emulare un processore x86 non te ne fai proprio nulla degli altri core, e il tallone d'Achille di un PC da emulare è rappresentato proprio dal processore.
Poi rimane pur sempre un ARM11, che non è certo un campione di efficienza/prestazioni, e un x86 è un processore CISC abbastanza complesso, per cui non è facile da emulare quanto potrebbe essere un RISC.
Vuoi un esempio pratico? Guardati le slide di un talk (Writing an 8086 emulator in Python) che ho tenuto lo scorso anno alla PyCon 6. In particolare la slide 39 che mostra come calcolare i flag del processore a seguito di un'operazione aritmetica.
E stiamo parlando di un semplicissimo 8086: immagina quanto sia incasinato emulare un 386 o superiore, specialmente in modalità protetta...
Dimenticavo: la cache L2 è importante (ma è da verificare se ci sia o meno) e contribuisce alle prestazioni, ma non fa certo miracoli.
Beh, se le altre fonti dicono cazzate, non è che tu ne abbia portato qualcuna a tuo sostegno.
L'unico dato concreto è che dovrebbe essere un quad core, ma per emulare un processore x86 non te ne fai proprio nulla degli altri core, e il tallone d'Achille di un PC da emulare è rappresentato proprio dal processore.
Poi rimane pur sempre un ARM11, che non è certo un campione di efficienza/prestazioni, e un x86 è un processore CISC abbastanza complesso, per cui non è facile da emulare quanto potrebbe essere un RISC.
Vuoi un esempio pratico? Guardati le slide di un talk (Writing an 8086 emulator in Python) che ho tenuto lo scorso anno alla PyCon 6. In particolare la slide 39 che mostra come calcolare i flag del processore a seguito di un'operazione aritmetica.
E stiamo parlando di un semplicissimo 8086: immagina quanto sia incasinato emulare un 386 o superiore, specialmente in modalità protetta...
Dimenticavo: la cache L2 è importante (ma è da verificare se ci sia o meno) e contribuisce alle prestazioni, ma non fa certo miracoli.
domandone immane: premesso che io ne capisco piu' o meno zero, ipotizzando di avere un arm con almeno due core disponibili per l'emulazione, non si potrebbe usare un core per fare i calcoli e in parallelo un core per impostare i flag del finto 8086? o come sono associate le due cose?
edit: se non erro, la cpu originale del raspberry pi dicevano che era equivalente a spanne a un p2 300 (con grafica pompata), escludendo ovviamente l'overhead dell'emulazione
riedit: dopo aver visto la slide, ho capito che 1)l'architettura x86 e' un casino immane 2)e' stato scelto aros perche' kitty e' sempre kitty
Assolutamente no, perché l'emulazione di un processore/singolo core/singolo thread hardware è un processo/algoritmo intrinsecamente, irrimediabilmente seriale, che fa e può fare uso soltanto di un singolo core/thread hardware.
Puoi avere migliaia di core, ma sempre e soltanto uno ne sarà usato per l'esecuzione delle istruzioni del processore. Ovviamente a meno che il processore emulato abbia più core e/o thread hardware, e in questo caso a ognuno di essi può essere assegnato un core/thread hardware che ne esegue le istruzioni (e sto semplificando molto, perché non ho nemmeno parlato dei problemi di sincronizzazione che ci sono fra i diversi core/thread hardware del processore emulato. Per maggiori informazioni in merito c'è un interessante articolo sul blog dell'emulatore PCSX2, che entra nel dettaglio).
Sì, ma il paragone è fra il codice ARM che gira nativamente sul Raspberry, e il codice altrettanto nativo che gira(va) sul Pentium-II. Quindi non c'è nessuna emulazione di mezzo: si tratta di confrontare i due processori col normale codice che macinano.
Da questo si può vedere quanto poco performante sia un ARM11 (anche il vecchio Raspberry ne usa uno), anche perché non dotato di superpipeline (al contrario del P-II, che può eseguire fino a due istruzioni per ciclo di clock, sebbene "in-order", e può contare su una buona FPU).
Hai capito tutto.
x86 è un casino, ma da emulare. Per il resto la sua complessità è ormai relegata a qualche milionata di transistor utilizzati per il decoder delle istruzioni e, in misura minore, per l'FPU x87.
Beh, se le altre fonti dicono cazzate, non è che tu ne abbia portato qualcuna a tuo sostegno.
L'unico dato concreto è che dovrebbe essere un quad core, ma per emulare un processore x86 non te ne fai proprio nulla degli altri core, e il tallone d'Achille di un PC da emulare è rappresentato proprio dal processore.
Poi rimane pur sempre un ARM11, che non è certo un campione di efficienza/prestazioni, e un x86 è un processore CISC abbastanza complesso, per cui non è facile da emulare quanto potrebbe essere un RISC.
Vuoi un esempio pratico? Guardati le slide di un talk (Writing an 8086 emulator in Python) che ho tenuto lo scorso anno alla PyCon 6. In particolare la slide 39 che mostra come calcolare i flag del processore a seguito di un'operazione aritmetica.
E stiamo parlando di un semplicissimo 8086: immagina quanto sia incasinato emulare un 386 o superiore, specialmente in modalità protetta...
Dimenticavo: la cache L2 è importante (ma è da verificare se ci sia o meno) e contribuisce alle prestazioni, ma non fa certo miracoli.
Per cui le prestazioni in emulazione saranno molto simili, con un leggero vantaggio per il New 3DS, rispetto al R-Pi con clock standard.
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".