cerco di dare una breve risposta a tutti i punti :D
cdimauro ha scritto:TheKaneB ha scritto:x86 non è un problema, semplicemente è "brutto" per gli sviluppatori (i processori PPC sono più semplici da programmare)
Questo è discutibile. Magari è una questione di gusti, ma da programmatore assembly di vecchia data preferisco x86 (in particolare AMD64) anziché PowerPC se proprio devo programmare in assembly.
Io non sono un programmatore assembly di vecchia data come te... probabilmente quando tu già programmavi io dovevo nascere, però ho lavorato parecchio su ARM e da lì è nata la mia passione per la programmazione in Assembly. PPC è in parte simile ad ARM, ma più complesso. Ho lavorato un po' anche su x86 e, questione di gusti sicuramente, ci sono tante cose che non mi piacciono. Probabilmente sono troppo abituato ad avere un'ISA ortogonale con tanti registri general purpose.
Non conosco AMD64, quindi non commento su quella parte :-p
Diciamo che essendomi formato professionalmente su dei RISC, sono abituato a quel modo di lavorare e lo trovo molto più semplice e lineare (con qualche eccezione, quando parliamo di PPC che sono abbastanza atipici, rispetto per lo meno a MIPS e ARM).
[...] ma in ogni caso con un RISC devi scrivere molto più codice per fare le stesse cose di un CISC.
E' vero, ci vuole mediamente più codice per fare le stesse cose. L'espressività del CISC risiede quasi tutta nella ricchezza delle modalità di indirizzamento degli operandi. Ma su RISC, una volta fatto il load degli operandi, ti ritrovi ad avere un set ortogonale più facile da padroneggiare. Il processo mentale di chi programma in RISC è lineare: load, compute, store. Se fai tua questa logica, puoi scrivere qualunque cosa senza essere per forza un guru.
Ecco perché continuo a preferire i CISC. Che poi x86 la possiamo considerare brutta se ci fermiamo ai 286. Dal 386 in poi ha guadagnato abbastanza. E non ne parliamo con AMD64.
Qualunque Computer Scientist ti direbbe che scrivere un OS multitasking basato su microkernel, NON HA SENSO in una piattaforma senza virtualizzazione degli address spaces (in pratica, senza la MMU). E anche quando hanno introdotto la MMU sui 68030, ormai era troppo tardi per fare il passo avanti, visto che la struttura stessa dell'OS era stata costruita attorno alle caratteristiche/mancanze del MC68000. Bisognava buttare l'OS e tutti i programmi e rifarli da capo.
L'MMU è apparsa molto prima che col 68020. Anzi, a volerla dire tutta, già col 68010 si sarebbe potuto fare non poco a livello di separazione fra kernel e user space, e al mapping dei task / processi in apposite zone di memoria (eventualmente anche protette), ricorrendo a un po' di logica esterna.
Hi-Toro prima e Commodore poi hanno scelto la strada dell'economicità. Un 68000, all'epoca, andava più che bene. E ne abbiamo pianto le conseguenze.
grazie per le precisazioni, come sai non conosco bene i processori motorola, sono un ARMeggiatore io :D
Da un po' di anni l'assembly si usa sempre meno. Persino per i più schifosi PIC ci sono compilatori C.
Certo, se c'è da spremere per bene una particolare sezione critica, lo si fa, ma personalmente preferisco perdere meno tempo possibile nello sviluppo.
le tue parole sono iniettate di Pythonismo, non fai testo
scherzi a parte, quello che dici lo condivido pienamente, ma per il mio lavoro saper scrivere pezzi di codice in assembly è fondamentale. Come ho già detto programmo soprattutto videogames su console, e non uso l'assembly solo per questioni di ottimizzazione, ma spesso anche per sfruttare certe tecniche particolari che non possono essere exploitate in linguaggi di alto livello. Questo comprende anche l'implementazione di semplici sistemi di debugging "fai da te", che completano la dotazione, a volte pietosa, dei tools di sviluppo ufficiali (qualcuno ha citato per caso IS Nitro Emulator?).
Ma il mio punto era un altro. Se ho 3 versioni di AmigaOS, per 68K, PPC e x86, gli eseguibili verrebbero creati con hunk 68K, PPC e x86 per il codice, cercando di generare un hunk "generale" per i dati comuni, e delegando a piccoli hunk dati specifici per le rispettive architetture quelli che non possono essere riciclati.
Un AmigaOS x86 che carica un siffatto binario provvede a caricare soltanto gli hunk che gli servono.
si, lo so come funziona. il problema è che alcuni importanti programmi che si usano quotidianamente sui sistemi Amiga-like attuali, o sono troppo legati alla piattaforma (e quindi una semplice ricompilazione non funzionerebbe nel modo sperato) oppure sono semplicemente "orfani" da parte dello sviluppatore e non sono nemmeno open source. Entrambi i casi fanno nascere la necessità di emulatori.
