Emuliamo di tutto!

Ormai sto cavalcando l'onda, e così ho preso in mano il vecchio ARM dell'Archimedes di 30 anni fa - che poi si è riciclato in ARM 7 ecc.ecc. ed è un po' ovunque. Mi aveva colpito, ai tempi, quel RISC, quello strano assembler...

Ci ho messo abbastanza poco a scrivere un emulatore in C: e devo dire che questa CPU è stata sicuramente una bella idea... MOLTO più semplice dell'8086 e così pratico, efficiente, semplice.

Edited by Dario Greggio - 15/1/2020, 20:09

mmmm no, non proprio....

Possiamo parlare dell'inefficienza di avere le istruzioni sempre lunghe 32bit: ma le potenzialità di quanto si può codificare in 32bit è notevole! l'idea delle istruzioni sempre condizionate è molto buona, la completa "ortogonalità" dei registri anche...

Ci sono 16 operazioni possibili, e bastano e avanzano. C'è lo shift incorporato...

Fatti un giro sul pdf
http://vision.gel.ulaval.ca/~jflalonde/cou...tructionset.pdf

E' curioso: analizzando e misurando i tempi dei 5 emulatori che ho realizzato (6502, Z80, 8086, 8051 e ARM), il ciclo di esecuzione per istruzione è più o meno sempre lo stesso, ossia intorno ai 700nS (PIC @200MHz). Dal che si deduce che più è "potente" la CPU emulata, meglio si sfrutta il processore!

Probabilmente ha un suo senso perché la CPU che lavora è 32bit a sua volta...

e ho trovato un bug nel compilatore, compilando per un dsPIC!!

ci sono e ovviamente è impossibili spiegarli si subumani callcenter-like del "support"... !

In questo caso è colpa delle CPU nuove, i famosi dual core (ma non solo), ossia la serie dsPIC33CH o CK. Se usi una struct/union PACKED (ossia con membri piccoli, per mappare pochi bit per volta), il compilatore cerca di usare le nuove istruzioni BFEXT (trovi su internet) che manipolano un certo numero di bit all'interno di una word e... sbaglia a passargli l'indirizzo dispari, così va in eccezione di Memory Address!
Solo con le ottimizzazioni attive... e solo sui membri della struct che si trovano ad indirizzi dispari (naturalmente)