Ed è sostanzialmente corretto, anche se non mi pare che la situazione dei ColdFire sia migliorata in termini di (retro)compatibilità coi 68000.
Poi se vogliamo andare più sul preciso, rispetto ai 68000 (sì, anche i primi processori, quelli che hanno spopolato su Amiga 1000, 2000, 500 e 600) la situazione coi ColdFire è la seguente:
- mancano delle istruzioni;
- mancano delle modalità d'indirizzamento (quelle più complesse; prime fra tutte quelle con doppia indirezione verso la memoria, ma anche e semplicemente quelle che hanno offset a 32 bit, ad esempio);
- le istruzioni possono essere lunghe al massimo 6 byte, per cui per alcune istruzioni è come se si verificasse uno dei precedenti punti.
Per i non addetti ai lavori questo si traduce nel fatto che è praticamente impossibile per un ColdFire riuscire a eseguire una qualunque applicazione 68000 (o, peggio ancora, superiori) senza una patch del s.o. che riesca e intercettare l'esecuzione di tutti i casi precedenti, perché sicuramente si troverà a eseguire qualche istruzione mancante o "castrata".
Tramite una siffatta patch non ci sarebbe alcun problema, a parte gli enormi costi in termini computazionali che richiede quest'emulazione, che è tutt'altro che semplice e richiede parecchio lavoro, cosa che i soli Mhz non possono compensare.
Per rendere grossolanamente l'idea, è come se il ColdFire dovesse eseguire un emulatore 68000, con alcune differenze.
Se è vero che molte istruzioni non verrebbero emulate (perché eseguite "nativamente", in quanto facenti parti di quelle disponibili) ed eseguite MOLTO velocemente (sono native!), è anche vero che per quelle mancanti (e non sono affatto poche o rare; dopo faccio un esempio) la situazione è DI GRAN LUNGA PEGGIORE rispetto a un emulatore, in quanto l'esecuzione di un'istruzione "assente" richiede:
- l'interruzione dell'esecuzione corrente, con conseguenze svuotamento della pipeline;
- salvataggio del contesto attuale (program counter e flag) sullo stack, con creazione del relativo frame (che a seconda del processore può richiedere molto spazio e parecchio tempo per completare già solo quest'operazione; questo era uno dei motivi per cui nei miei giochi NON usavao interrupt: per NON sprecare tempo in questo cambio di contesto);
- salvataggio di un certo numero di registri o sullo stack o su un'apposita memoria locale, perché dovranno essere "sporcati";
- interpretazione dell'istruzione fallace ed esecuzione del lavoro richiesto per considerarla eseguita correttamente (questo e soltanto questo è il lavoro svolto da un normale emulatore!);
- ripristino dei registri sporcati;
- ripristino del contesto precedente;
- ricaricamento della pipeline.
Va da sé che una roba del genere letteralmente ammazza le prestazioni di un processore. Anche perché quelle che mancano all'appello non sono mica tanto rare. Ad esempio questa:
- Codice: Seleziona tutto
MOVE.L #Valore,Offset(A6)
era comune nella programmazione dei chip custom dell'Amiga (supponendo che A6 fosse impostato a $DFF000, com'era abitudine), e già occupa 8 byte.
Altra cosa importante è la retrocompatibilità, che viene meno. La patch può servire per far funzionare le applicazioni col sistema operativo che gira, ma la stragrande maggioranza dei giochi per Amiga ammazzava il s.o. e gestiva l'hardware da sé. Quindi quella patch NON funzionerebbe.
Lo stesso vale per demo e/o giochi che girano all'interno del s.o., ma che lo ammazzano temporaneamente, eseguono il loro codice, e poi lo riportano in vita: se, come tante volte capitava, riscrivevano il vettore che punta alla routine di gestione delle istruzioni sconosciute, non funzionerebbero nemmeno.
Spero di essere stato chiaro.
@cip060: non vedo perché dovremmo fare "baruffa" per questioni tecniche.
Hai detto che tu non sei tecnico, ma non per questo dovrei offenderti o azzuffarmi con te.
Tempo permettendo non ho alcuna difficoltà a spiegarti il tutto, a qualunque livello di dettaglio necessario o che t'interessi.
).
