Confronto fra i486 e Motorola 68000

[fek]

Dalle News:
http://www.hwupgrade.it/forum/showth...=948317&page=5

Originariamente inviato da MadRat

Il processore in questione e' si un 32bit ma con un bus esterno a 16 bit ed un data bus a 24. almeno cosi' era in TUTTI i computer che lo usavano al tempo.
Che poi sia piu' flessibile dun un x86 e possa diventare un 32 full non vuol dire che lo fosse..
Il fatto che il 486 permettesse di eseguire le istruzioni in un solo ciclo di clk lo sanno piu' o meno tutti.. bisogna poi vedere la potenza di esse e l'efficacia.

http://www.cpu-world.com/CPUs/68000/

Per quanto riguarda tutto il resto non mi pare il caso di discutere riguardo le istruzioni e l'efficienza di esse (inquanto ho parlato anche di architetture), il punto sta nel fatto che i programmi li giravano molto piu' rapidamente.
Il cubase dava i numeri, non azzeccava una nota nemmeno su un 1000mhz!! tutt'oggi un un porcessore come il mio (un 64bit a 2,7ghz) ha degli scompensi quando si verivica un accesso "eccessivo" alle periferiche ide o quando si legge un floppy (per non parlare di quando e' rovinato!!).
Poi informati riguardo il falcon, perche' il 56001 non e' ovviamente in grado di eseguire istruzioni GP, poteva semplicemente accelerare i calcoli relativi alle elaborazioni audio. La parte midi era portata direttamente dal "vecchio" cubase per ST e nulla c'entrava con il DSP.

Il primo masterizzatore che comprammo fu uno 0,5X e montato su un "portentoso" 486 mi bruciava un disco ogni 2 e quando muovevi il mouse (anche con masterizzatori migliori usciti molto dopo) falliva all'istante. (ovviamente non parlo di masterizzatori moderni in grado di sospendere la masterizzazione). Al mio falcon che monta un "misero" 68030, ho attaccato un mast 4x (perche' quresto ho trovato scsi) e non mi ha mai sbagliato un disco, mentre faccio tutto cio' che voglio.
Con tutto che non ho mai portato simpatia eccessiva per l'architettura amiga (da te citata), ti invito ad immaginarti un'evoluzione tecnologica a queste frequenze di quella macchina (ed una conseguente evoluzione della famiglia 68k).. poi dimmi se sencondo te, avrebbe bisogno di una scheda video separata per far girare un giocho 3d decentemente..
In ogni caso non riesco a vedere come tu possa volermi paragonare un 68000 con un 486 uscito anni ed anni dopo.. paragoniamo le architetture o meglio i risultati. Se proprio vogliamo, paragoniamolo ad un 68060, gia' mi sembra piu' equo.

In fine direi che se un moderatore debba dire qualcosa a qualcuno, lo debba fare a te, vista la tua correzione "deltutto personale" punto punto. Per quanto mi riguarda la discussione finisce qui.

[MadRat]

Grazie per l'apertura.. ma non e' mai stato un confronto tra un 68000 ed nu 486.. ma tra architetture.. una vecchia 25 anni piu' dell'latra..
Comuqnue rimanesse convinto delle proprie idee, poco mi cambia.
Io sostenevo solamente che l'architetura dei "pc compatibili, x86" sia solo un limite prestazionale (da qui il semplice esempio portato da me dei computer basati su 68000) del quale non soffriranno le nuove console e dunque a parita' di gpu/cpu saranno considerevolmente piu' potenti di questi cassoni vincolati a concetti di 50 e passa anni fa.

Per chi volesse sapere di che si stia parlando..
http://www.hwupgrade.it/forum/showth...37#post8599237

[cdimauro]

Originariamente inviato da MadRat

Il processore in questione e' si un 32bit ma con un bus esterno a 16 bit ed un data bus a 24. almeno cosi' era in TUTTI i computer che lo usavano al tempo.

Se parli del 68000, sì, e tra l'altro l'avevo già scritto nel mio messaggio.

Il 68008, che internamente aveva la stessa architettura, era però più limitato, perché aveva 20 bit per il bus indirizzi e 8 bit per quello dei dati: secondo il tuo criterio avrei dovuto definirlo come processore a 8 bit? Oppure a 8 / 32 bit?

Che poi sia piu' flessibile dun un x86 e possa diventare un 32 full non vuol dire che lo fosse..

"Full 32 bit": ti ho già chiesto in base a quale criterio (oggettivo) classifichi un processore come "full x bit" o "non full x bit".

Quanto alla flessibilità, non so a cosa ti riferisci: dovresti essere più chiaro.

Il fatto che il 486 permettesse di eseguire le istruzioni in un solo ciclo di clk lo sanno piu' o meno tutti.. bisogna poi vedere la potenza di esse e l'efficacia.

Ti ricordo che tu hai confrontato un 68000 a 8 Mhz con un 486 a 66Mhz.
Ti ho fatto notare che un 68000, per eseguire una NOP (che è un'istruzione che non fa nulla), impiega ben 4 cicli di clock.
Ti ho fatto notare che un 486 esegue la maggior parte delle istruzioni (quindi anche ben più complicate di una NOP) in un solo ciclo di clock.
Questo avrebbe dovuto farti dedurre che la disparità fra la "potenza di calcolo / efficacia" (qualunque cosa tu intendi con questi termini) è MOSTRUOSAMENTE a favore di quest'ultimo.

Hai mai visto girare la prima versione di UAE (l'emulatore Amiga più conosciuto / diffuso / preciso / usabile) su un 486 (a 50Mhz)? Se lo ritieni così inefficiente / poco potente, mi spieghi come faceva ad emulare un 68000 a 7,09Mhz, con tanto di chip custom, discretamente?

Ovviamente l'emulazione dei chip custom era primordiale, ma in questo contesto m'interessa puntualizzare la capacità del 486 di emulare il 68000: in base a quanto hai scritto, come potrebbe un 486 emulare un processore che tu hai definito come "suo pari", un 68000 a 8Mhz?

http://www.cpu-world.com/CPUs/68000/

Questo perché l'hai postato? A me non serviva e non vedo cosa c'entri col resto del discorso.

Per quanto riguarda tutto il resto non mi pare il caso di discutere riguardo le istruzioni e l'efficienza di esse (inquanto ho parlato anche di architetture),

Anch'io ho parlato di architetture, e le ho messe in relazione in base a quel che erano in grado di fare (tipo di operazioni) e a come lo facevano (tempo di esecuzione), per dimostrare che il tuo confronto non era (e non è) assolutamente realistico.

il punto sta nel fatto che i programmi li giravano molto piu' rapidamente.

Ti ho già scritto che bisogna vedere in che modo sono stati realizzati i programmi / conversioni: non puoi giudicare soltanto in base all'apparenza.

Il cubase dava i numeri, non azzeccava una nota nemmeno su un 1000mhz!! tutt'oggi un un porcessore come il mio (un 64bit a 2,7ghz) ha degli scompensi quando si verivica un accesso "eccessivo" alle periferiche ide o quando si legge un floppy (per non parlare di quando e' rovinato!!).

Idem come sopra: non puoi effettuare dei confronti senza avere in mano dati chiari su come sono stati realizzati i programmi per le due architetture.

Esempio: Halo è un gioco per X-Box e per PC, ma è stato scritto e funziona in maniera diversa. Non hanno preso il programma così com'era, e semplicemente ricompilato (e anche qui bisognerebbe vedere come, ma tralascio questo dettaglio perché complicherebbe ulteriormente il discorso).

Poi informati riguardo il falcon, perche' il 56001 non e' ovviamente in grado di eseguire istruzioni GP,

Sono informato, ed è perfettamente in grado di farlo. Puoi dirmi che non è ciò per cui è stato pensato e realizzato, ma questo è UN ALTRO DISCORSO.

poteva semplicemente accelerare i calcoli relativi alle elaborazioni audio.

Vedi sopra: questo è il motivo per cui è stato integrato nel Falcon, ma non vuol dire che non lo si possa usare anche per altro (anche nel campo dell'elaborazione grafica avrebbe delle buone prestazioni).

La parte midi era portata direttamente dal "vecchio" cubase per ST e nulla c'entrava con il DSP.

Atari ST e Falcon hanno la stessa interfaccia MIDI, che altri non è se non una seriale che "viaggia" a circa 31000 baud: gestire una seriale a velocità così basse è capace di farlo anche il 6502 a 1Mhz del Vic20.

Il problema, come ti ho già detto, è che bisogna vedere IN CHE MODO è stato realizzato il programma che la usa.

Il primo masterizzatore che comprammo fu uno 0,5X e montato su un "portentoso" 486 mi bruciava un disco ogni 2 e quando muovevi il mouse (anche con masterizzatori migliori usciti molto dopo) falliva all'istante. (ovviamente non parlo di masterizzatori moderni in grado di sospendere la masterizzazione). Al mio falcon che monta un "misero" 68030, ho attaccato un mast 4x (perche' quresto ho trovato scsi) e non mi ha mai sbagliato un disco, mentre faccio tutto cio' che voglio.

Stai mischiando capra e cavoli: parli di sistemi completamente diversi, che usano programmi completamente diversi.
Addirittura stai affermando che il masterizzatore era SCSI: hai mai provato a collegarlo, sempre con un'interfaccia SCSI, al 486? Vedrai che difficilmente brucerai dei CD. Chissà perché...

Con tutto che non ho mai portato simpatia eccessiva per l'architettura amiga (da te citata),

La mia, ai tempi, era più che una simpatia. D'altra parte un Amiga permetteva di emulare tranquillamente anche un Mac o un Atari ST, ma il viceversa non è mai stato possibile...

ti invito ad immaginarti un'evoluzione tecnologica a queste frequenze di quella macchina (ed una conseguente evoluzione della famiglia 68k)..

Sono anni che ci penso, e penso che Motorola abbia avuto le sue buone ragioni per abbandonare quest'architettura. Anche se era molto "bella" (ti parlo come programmatore assembly), a livello di implementazione era estremamente complicata.

Un 68020, che è l'architettura su cui sono poi stati basati tutti gli altri processori, aveva istruzioni lunghe fino a 22 byte, che permettevano di accedere alla memoria, sia come sorgente sia come destinazione, con due livelli di indirezione (uno per "procurarsi" il puntatore, e l'altro per prelevare finalmente il dato).

Non so quali siano le tue conoscenze nell'ambito delle architetture degli elaboratori, di come funziona un processore, dei problemi di implementazione di un'architettura, ma ti assicuro che implementare istruzioni come quella di cui sopra farebbero aspirare al suicidio il miglior ingegnere.

Anche ipotizzando l'adozione di un "core RISC", come oggi avviene per la famiglia x86 (e i PowerPC di IBM), il lavoro sarebbe enorme. Per l'esempio di cui sopra, sarebbero necessarie almeno 5 microistruzioni per portare a termine l'operazione (una "semplice" MOVE), e i due accessi in memoria metterebbero sotto stress sia le cache dati sia la cache TLB.

Poi non parliamo nemmeno del decoder delle istruzioni, che risulterebbe MOSTRUOSAMENTE più complicato, rispetto a quello degli x86.

Quindi, in definitiva e per rispondere a quanto chiedevi, mi sembra alquanto difficile già soltanto pensare di implementare un'architettura come quella dei 68000 "secondo i canoni attuali", e sicuramente sarebbe impossibile raggiungere frequenze di lavoro comparabili, a parità di tecnologia produttiva utilizzata.

poi dimmi se sencondo te, avrebbe bisogno di una scheda video separata per far girare un giocho 3d decentemente..

Anche questo è un altro discorso, e non c'entra niente col confronto che hai tirato in ballo.

In ogni caso non riesco a vedere come tu possa volermi paragonare un 68000 con un 486 uscito anni ed anni dopo..

Ti ricordo che il paragone l'hai fatto tu: io non me lo sarei mai sognato.

paragoniamo le architetture o meglio i risultati.

Le architetture le possiamo anche paragonare, ma non ne salterebbe nulla di utile (che te ne fai?)

Per i risultati, bisognerebbe prima decidere il tipo di applicazioni da usare, e poi, simulatori alla mano (a meno che tu non abbia a disposizione i processori oggetto del confronto), verificare quanti cicli di clock sono necessari per portare a termine un ben preciso lavoro.

Se proprio vogliamo, paragoniamolo ad un 68060, gia' mi sembra piu' equo.

E' uno scherzo vero? Un 68060 lo confrontiamo con un Pentium, non con un 486...

In fine direi che se un moderatore debba dire qualcosa a qualcuno, lo debba fare a te, vista la tua correzione "deltutto personale" punto punto.

Non potevi capire: è un discorso che è stato affrontato in un altro thread.

Per quanto mi riguarda la discussione finisce qui.

Se volevi che finisse, ti sarebbe bastata una riga per farlo, non un romanzo in cui rispondevi a quanto ho scritto. Comodo uscirtene fuori così, sottraendoti al confronto dopo aver detto la tua.

[cdimauro]

Originariamente inviato da MadRat

Grazie per l'apertura.. ma non e' mai stato un confronto tra un 68000 ed nu 486.. ma tra architetture.. una vecchia 25 anni piu' dell'latra..

Questo:

(un motorola 68000 a 16 bit a 8mhz ha il potenziale di un 486 a 32bit a 66mhz),

l'hai scritto tu, o sbaglio?

Comuqnue rimanesse convinto delle proprie idee, poco mi cambia.
Io sostenevo solamente che l'architetura dei "pc compatibili, x86" sia solo un limite prestazionale (da qui il semplice esempio portato da me dei computer basati su 68000) del quale non soffriranno le nuove console e dunque a parita' di gpu/cpu saranno considerevolmente piu' potenti di questi cassoni vincolati a concetti di 50 e passa anni fa.

E ti ho risposto che non sono d'accordo, argomentando.

Puoi anche rimanere con le tue idee, e non ci sarebbe alcun problema, ma se lo fai pubblicamente devi anche sostenerle con qualcosa di più delle tue opinioni personali.

[MadRat]

Originariamente inviato da cdimauro

Se parli del 68000, sì, e tra l'altro l'avevo già scritto nel mio messaggio.
Il 68008, che internamente aveva la stessa architettura, era però più limitato, perché aveva 20 bit per il bus indirizzi e 8 bit per quello dei dati: secondo il tuo criterio avrei dovuto definirlo come processore a 8 bit? Oppure a 8 / 32 bit?
Quanto alla flessibilità, non so a cosa ti riferisci: dovresti essere più chiaro.

The 68000 architecture was much more flexible than other CPU familes (z80, 80x86, z80000, etc) as it could be very easily expanded to support full 32-bit data and address.
Questo viene dal link che non cpisci perche' io abbia postato..

Originariamente inviato da cdimauro

"Full 32 bit": ti ho già chiesto in base a quale criterio (oggettivo) classifichi un processore come "full x bit" o "non full x bit".

In base alle non restrizioni dei bus a bittaggi inferiori-

Originariamente inviato da cdimauro

Ti ricordo che tu hai confrontato un 68000 a 8 Mhz con un 486 a 66Mhz.

Hai mai visto girare la prima versione di UAE (l'emulatore Amiga più conosciuto / diffuso / preciso / usabile) su un 486 (a 50Mhz)? Se lo ritieni così inefficiente / poco potente, mi spieghi come faceva ad emulare un 68000 a 7,09Mhz, con tanto di chip custom, discretamente?

Ovviamente l'emulazione dei chip custom era primordiale, ma in questo contesto m'interessa puntualizzare la capacità del 486 di emulare il 68000: in base a quanto hai scritto, come potrebbe un 486 emulare un processore che tu hai definito come "suo pari", un 68000 a 8Mhz?"

Secondo me si dovrebbe far distinzione tra "emulare" ed "imitare", un 486 fa girare molto male l'emulatore amiga e per emulare un 68000 ha bisogno di frequenze spropositatamente superiori.
Se prendi un normalissimo 520st, e' in grado di far girare il 30% piu' velocemente (con lo spectre) un mac di pari frequrenza.
In oltre l'emulatore ST dell'amiga era pietoso, girava al 10% delle possibilita' di un vero st, era inusabile, poi, come provavi a lanciare un software entrava nella crisi piu' totale. Era si e no in grado di emulare il descktop con lentezza esasperante, assolutamente non in grado di eseguire tutte le operazioni assegnate al dma, un st poteva formattare un floppy in backgrund senza rallentare il computer in alcuna maniera e se cubase si impallava e tornava al desk, la song continuava a suonare senza sbagliare un 64esimo nemmeno durante la fase di crash.
Dunque mi sembra assurdo parlare d'emulatore st su amiga. (lo ho ed ho ancora diversi amiga assieme al loro software ed una bella collezione di retrocomputing a partire dal vectrex passando per l'archimedes e finendo al giorno d'oggi..) Tenendo presente che anche gli emulatori attuali non sono in grado di visualizzare ad esempio le demo che rappresentino raster in overscreen, riducendoli nei colori pesantemente. Non sono nemmeno in grado di far girare in cubase con la precisione dell'originale.

Originariamente inviato da cdimauro

Anch'io ho parlato di architetture, e le ho messe in relazione in base a quel che erano in grado di fare (tipo di operazioni) e a come lo facevano (tempo di esecuzione), per dimostrare che il tuo confronto non era (e non è) assolutamente realistico.

Ti ho già scritto che bisogna vedere in che modo sono stati realizzati i programmi / conversioni: non puoi giudicare soltanto in base all'apparenza.

Idem come sopra: non puoi effettuare dei confronti senza avere in mano dati chiari su come sono stati realizzati i programmi per le due architetture.

Bene, secondo questo tuo assunto, tutti i difetti sono riconducibili alla mala programmazione e pessimi porting.. sempre che di porting si tratti..
All'atto pratico TUTTI i software presenti su entrambe le piattaforme giravano meglio (infinitamente meglio a parita di cpu, frequenze e memoria impiegata) su sistemi 68000 based.
Sara' stata tuta incompetenza dei programmatori.. mah!!

Originariamente inviato da cdimauro

Esempio: Halo è un gioco per X-Box e per PC, ma è stato scritto e funziona in maniera diversa. Non hanno preso il programma così com'era, e semplicemente ricompilato (e anche qui bisognerebbe vedere come, ma tralascio questo dettaglio perché complicherebbe ulteriormente il discorso).

Riguardo Halo non sono informato, ma mi parrebbe strano leggere di queste grandi differenze, vista la similarita' (identicita', piu' che altro) delle piattaforme in questione. Se hai qualcosa postalo.

Originariamente inviato da cdimauro

Sono informato, ed è perfettamente in grado di farlo. Puoi dirmi che non è ciò per cui è stato pensato e realizzato, ma questo è UN ALTRO DISCORSO.

Vedi sopra: questo è il motivo per cui è stato integrato nel Falcon, ma non vuol dire che non lo si possa usare anche per altro (anche nel campo dell'elaborazione grafica avrebbe delle buone prestazioni).

Non mi risulta che il DSP 56001 sia quest'asso nelle istruzioni "General Purpose"
(ci rifacciamo al discorso degli pseudo-dsp del cell). Che poi possa essere usato per la gestione grafica anziché audio o quant'altro risulta ovvio.. accade anche oggi con alcuni software per pc che sfrutano le schede 3d per elaborare l'audio.
Cio' non toglie che la gestione di 160 ch midi (tramite un'interfaccia PASSIVA esterna e porta lan (di derivazione mac) in aggiunta a quelle di serie), non comporti minimamente l'utilizzo del dsp. Un 486 non e' assolutamente in grado di gestire 16ch midi con precisione. Molti miei amici musicisti fino al 2ghz e passa si sono disperati per questo motivo. E' anche il motivo per il quale alla fine io non ho ancora cambiato, anche se prima o poi accadra'. Tutt'oggi un pc per avere una vera prestazione midi/hdr, necessita di una costosa scheda dedicata. Ma tanto tu sostieni che si tratti di malaprogrammazione.

Originariamente inviato da cdimauro

Atari ST e Falcon hanno la stessa interfaccia MIDI, che altri non è se non una seriale che "viaggia" a circa 31000 baud: gestire una seriale a velocità così basse è capace di farlo anche il 6502 a 1Mhz del Vic20.

Come no.. si e' visto.. puo' farlo un vic venti ma non un 486.. nemmeno un athlon 1000..
Forse non si tratta solo di trasferire dati.. che ne dici??

Originariamente inviato da cdimauro

Il problema, come ti ho già detto, è che bisogna vedere IN CHE MODO è stato realizzato il programma che la usa.

E' proprio qui che non siamo d'accordo. Il problema e' che il pc e' un grosso accrocco costruito con molte toppe su fondamenta minuscole. (8bit e 640kb)

Originariamente inviato da cdimauro

Stai mischiando capra e cavoli: parli di sistemi completamente diversi, che usano programmi completamente diversi.
Addirittura stai affermando che il masterizzatore era SCSI: hai mai provato a collegarlo, sempre con un'interfaccia SCSI, al 486? Vedrai che difficilmente brucerai dei CD. Chissà perché...

Ma tu vivi nel mio studio?? Il primo masterizzatore comprato tantissimi anni fa era SOLO scsi e costava circa 13milioni di lire e mi sprecava CD del valore di 90mila.

Originariamente inviato da cdimauro

La mia, ai tempi, era più che una simpatia. D'altra parte un Amiga permetteva di emulare tranquillamente anche un Mac o un Atari ST, ma il viceversa non è mai stato possibile...

A questo ho risposto ampiamente sopra. Poi se vuoi ti racocnto bene come nacquero l'amiga e l'ST.

Originariamente inviato da cdimauro

Sono anni che ci penso, e penso che Motorola abbia avuto le sue buone ragioni per abbandonare quest'architettura. Anche se era molto "bella" (ti parlo come programmatore assembly), a livello di implementazione era estremamente complicata.

La motorola lo abbandonò perche' schiacciata dal mercato. Le schede a 256 colori a basso costo di produzione orientale fecero diffondere il pc in modo assurdo e rapido. Se ci fosse stata una pari evoluzione degli altri due sistemi, ora saremmo decisamente su un altro piano.
Il 680x0 aveva solo il limite di essere cisc, specialemnte nelle ultime versioni, possedeva potenza da vendere (060), ma un risc era sicuramente piu' efficace. (specialmente in ambito di malaprogrammazioneo o programmazione "facile"..)

Originariamente inviato da cdimauro

Non so quali siano le tue conoscenze nell'ambito delle architetture degli elaboratori, di come funziona un processore, dei problemi di implementazione di un'architettura, ma ti assicuro che implementare istruzioni come quella di cui sopra farebbero aspirare al suicidio il miglior ingegnere.

Guidare una lamborghini e' piu' difficile che guidare una panda.. ma se lo si sa fare (e sottoline il SE) si ottengono risultati differenti.

Originariamente inviato da cdimauro

Anche ipotizzando l'adozione di un "core RISC", come oggi avviene per la famiglia x86 (e i PowerPC di IBM), il lavoro sarebbe enorme. Per l'esempio di cui sopra, sarebbero necessarie almeno 5 microistruzioni per portare a termine l'operazione (una "semplice" MOVE), e i due accessi in memoria metterebbero sotto stress sia le cache dati sia la cache TLB.

A me il 680x0 piace perche' non e' risc.
anche se oggi non ha senso parlare di risc e cisc, i processori sono cosi' complessi da non poter essere piu' distinti in questo modo. Piu' che altro si adattano nell'evoluzione al tipo di istruzioni piu' richiesto.

Originariamente inviato da cdimauro

Poi non parliamo nemmeno del decoder delle istruzioni, che risulterebbe MOSTRUOSAMENTE più complicato, rispetto a quello degli x86.

Come sopra, a te piacicono le cose semplici, ma non e' una regola applicabile a tutti.

Originariamente inviato da cdimauro

Quindi, in definitiva e per rispondere a quanto chiedevi, mi sembra alquanto difficile già soltanto pensare di implementare un'architettura come quella dei 68000 "secondo i canoni attuali", e sicuramente sarebbe impossibile raggiungere frequenze di lavoro comparabili, a parità di tecnologia produttiva utilizzata.

Sarebbe possibilissimo iplementare le attuali tecnologie ad un'altra architettura.
Il discorso e' molto piu' complesso,in primis perche' oggi si richiede comuqnue un aggiornamento (politica del consumismo) continuo, che con certe architetture risulta piu' ostico (ma meno necessario).
C'e' da considerare anche che la tecnologia attuale e' cresciuta con i pc compatibili e dunque su misura per loro. Qualora fosse stata sviluppata su altre piattaforme, avrebbe sicuramente preso altre direzioni (quelle piu' opportune alle altre piattaforme, appunto). Sicuramente non ci sarebbe stata questa folle rincorsa alle frequenze, dalla quale per fortuna, AMD si sta (solo in parte) dissociando.

Originariamente inviato da cdimauro

Anche questo è un altro discorso, e non c'entra niente col confronto che hai tirato in ballo.

C'entra eccome, un pc oggi come oggi, senza schede dedicate e' ridicolo, entra in crisi in molti segmenti.

Originariamente inviato da cdimauro

Le architetture le possiamo anche paragonare, ma non ne salterebbe nulla di utile (che te ne fai?)

Ne abbiam gia' parlato

Originariamente inviato da cdimauro

Per i risultati, bisognerebbe prima decidere il tipo di applicazioni da usare, e poi, simulatori alla mano (a meno che tu non abbia a disposizione i processori oggetto del confronto), verificare quanti cicli di clock sono necessari per portare a termine un ben preciso lavoro.

Forse non hai mai usato tutte le istruzioni di un 680x0, non essendo risc richiede una programmazione piu' complessa e "fantasiosa", ma queste cose le sai.

Originariamente inviato da cdimauro

E' uno scherzo vero? Un 68060 lo confrontiamo con un Pentium, non con un 486...

No, non e' uno scherzo, dovremmo vedere le date di produzione, comunque regge il paragone con un pentim senza problemi.. direi.

Originariamente inviato da cdimauro

Non potevi capire: è un discorso che è stato affrontato in un altro thread.

Io affermai soltanto come il vincolo di compatibilita' con un'architettura di mezzo secolo fa, fosse un limite per gli attuali computer e che le nuove console potrebbero non esserne affette a tutto loro vantaggio.
Se oggi si costruisse dal nulla un nuovo computer a parita' di frequenze, questo sarebbe impressionantemente piu' prestante di questi attuali.
Poi tu ne hai iniziato un dibatito che io non avrei mai sostenuto (lì, almeno )

Originariamente inviato da cdimauro

Se volevi che finisse, ti sarebbe bastata una riga per farlo, non un romanzo in cui rispondevi a quanto ho scritto. Comodo uscirtene fuori così, sottraendoti al confronto dopo aver detto la tua.

Non ero d'accordo ed esistendo il diritto di replica (me lo concedi no??) deve finire chi ha parlato per secondo. Almeno cosi' si fa in democrazia.

Per quanto riguarda l'altro post, direi che le mie convinzioni riguardo l'indecenza dell'architettura di questi cassoni sia palesata ed anche la convinzione (mia e non solo mia) che le potenzialita' di macchine basate su 68000 siano maggiori di quelle basate su x86, sia altrettanto palesata.
Convengo con te riguardo la difficolta' di programmazine, che oggi come oggi sarebbe un gran limite, vista la frenesia del mercato, ma questo e' un altro discorso ancora.

Insomma, per ora il mio falcon non mi sbaglia una nota di un 128esimo, un pc senza schede costosissime fa slittare note di 16esimi anche solo se si legge un cd e scrive una cache su hd.

[fek]

E' proprio qui che non siamo d'accordo. Il problema e' che il pc e' un grosso accrocco costruito con molte toppe su fondamenta minuscole. (8bit e 640kb)

Ma questo e' semplicemente falso, basta sapere come e' fatto un PC all'interno. E' una totale evoluzione di quell'architettura, che ormai non condivide piu' nulla se non il fatto di avere una CPU e della memoria.

E' come dire che una Ferrari e' un grosso accrocco costruito con molte toppe perche' deriva dalle carrozze a cavallo e condivide con loro quattro ruote.

Mi citi una limitazione dell'architettura del PC di oggi dovuta ai PC ad 8bit e 640kb?

Io affermai soltanto come il vincolo di compatibilita' con un'architettura di mezzo secolo fa, fosse un limite per gli attuali computer e che le nuove console potrebbero non esserne affette a tutto loro vantaggio.
Se oggi si costruisse dal nulla un nuovo computer a parita' di frequenze, questo sarebbe impressionantemente piu' prestante di questi attuali.
Poi tu ne hai iniziato un dibatito che io non avrei mai sostenuto (lì, almeno )

I PC di oggi non sono compatibili con quelli di ieri infatti. E' possibile far girare alcune applicazioni in emulazione, ma questo non li rende compatibili piu' di quanto un PC sia compatibile con una Amiga perche' e' in grado di emularlo.

C'entra eccome, un pc oggi come oggi, senza schede dedicate e' ridicolo, entra in crisi in molti segmenti.

Lo credo bene, e' un'architettura general purpose. Tu hai citato il Cell come processore in grado di strapazzare le CPU Intel/AMD, ma hai ignorato il fatto che il Cell entra in crisi proprio in applicazioni general purpose, mentre e' molto veloce in applicazioni di calcolo su stream di vettori, che rappresentano una stretta minoranza delle applicazioni di computing.

Guidare una lamborghini e' piu' difficile che guidare una panda.. ma se lo si sa fare (e sottoline il SE) si ottengono risultati differenti.

Ma guidare una macchina non e' progettare software o hardware: in questo campo vince la semplicita'. Essere "complicato" da usare ma piu' veloce se usato bene e' uno svantaggio, non un vantaggio.

[MadRat]

Originariamente inviato da fek

Ma questo e' semplicemente falso, basta sapere come e' fatto un PC all'interno. E' una totale evoluzione di quell'architettura, che ormai non condivide piu' nulla se non il fatto di avere una CPU e della memoria.

E' come dire che una Ferrari e' un grosso accrocco costruito con molte toppe perche' deriva dalle carrozze a cavallo e condivide con loro quattro ruote.

No, assolutamente. E come dire che se oggi si proggettasse una macchina da zero, verrebbe reinventato il motore endotermico. Sicuramente si creerebbe un mezzo esponenzialmente piu' efficace, silenzioso, non inquinante e sicuro.

Fermo restando che una TVR con banalissimo motore a scoppio va a 388kmh e poco ha a che vedere con una topolino.. Una Ferrari (preferisco Lambo ) sara' un ottimo prodotto, altamente prestante, ma sempre uno sfregio alla tecnologia attuale resta. Cosi' come lo sono questi pc.

Originariamente inviato da fek

Mi citi una limitazione dell'architettura del PC di oggi dovuta ai PC ad 8bit e 640kb?
I PC di oggi non sono compatibili con quelli di ieri infatti. E' possibile far girare alcune applicazioni in emulazione, ma questo non li rende compatibili piu' di quanto un PC sia compatibile con una Amiga perche' e' in grado di emularlo.

Se metto un floppy con un dos dentro sul mio pc gira perfettamente e non in emulazione.. su un atari o un commodore non gira.. non mi pare che le infrastrutture siano poi cosi' cambiate..

Originariamente inviato da fek

Lo credo bene, e' un'architettura general purpose. Tu hai citato il Cell come processore in grado di strapazzare le CPU Intel/AMD, ma hai ignorato il fatto che il Cell entra in crisi proprio in applicazioni general purpose, mentre e' molto veloce in applicazioni di calcolo su stream di vettori, che rappresentano una stretta minoranza delle applicazioni di computing.

Mi chiedo come tu faccia a parlare di "entrare in crisi" addirittura, non credo che alla IBM (cosi' come alla Sony ed atutte le altre grandi multinazionali che lo inseriranno nei loro mainframe) ne sappiano meno di te.. Non credo nemeno che tu ne abbia avuto uno per le mani. Quello che posso dire e' che la tecdemo di The Getaway, fatta girare solo con un cell simile (o forse definitivo) a quello che stara' nella ps3, senza l'ausilio della scheda video d'appoggio, e' veramente sbalorditivo e fa impallidire qualunque cpu gli si possa paragonare attualmente in produzione.
Poi puo' pure essere finto quel demo, ma credo in quel progetto.

Originariamente inviato da fek

Ma guidare una macchina non e' progettare software o hardware: in questo campo vince la semplicita'. Essere "complicato" da usare ma piu' veloce se usato bene e' uno svantaggio, non un vantaggio.

Commercialmente ti do ragionissima, questo e' gia' chiarito e questo puo' relegarsi al discorso (pseudo inutile) che facevamo riguardo al 680x0.
Mentre l'architettura del Cell, che loro definiscono dicendo "abbiamo tolto le istruzioni meno usate o meno importanti, per incrementare drasticamente quelle piu' richieste e potenziarle all'estremo", concetto che somiglia molto ad un'estremizzazione del risc. Questo lo rendera' assai piu' semplice da programmare.

[homero]

scusate il motorola 68000 e' un progetto dei primi anni 80 montato su personal computer MAC, AMIGA, ATARI dal 1984 in poi....
di fatto era una versione base di una famiglia di processori che vedeva il punto di riferimento nel 68020+68881+MMU(adesso non ricordo la cifra che indica questo chip).
laprima era ULA+INTEGER 32bit/32bit la seconda era un FLOATING POINT UNIT e la aterza e' lA memory menagement unit.
il 486 non e' il processore piu' adatto al confronto.
piuttosto lo e' il 386+387 intel.
questo e' tutto.
appartiene alla storia....niente di piu'
ne esistono decine di emulatori che permettono di testarne le qualità dalpunto di vista della programmazione, molto facile da programmare in assembler...

[MadRat]

Originariamente inviato da homero

scusate il motorola 68000 e' un progetto dei primi anni 80 montato su personal computer MAC, AMIGA, ATARI dal 1984 in poi....
di fatto era una versione base di una famiglia di processori che vedeva il punto di riferimento nel 68020+68881+MMU(adesso non ricordo la cifra che indica questo chip).
laprima era ULA+INTEGER 32bit/32bit la seconda era un FLOATING POINT UNIT e la aterza e' lA memory menagement unit.
il 486 non e' il processore piu' adatto al confronto.
piuttosto lo e' il 386+387 intel.
questo e' tutto.
appartiene alla storia....niente di piu'
ne esistono decine di emulatori che permettono di testarne le qualità dalpunto di vista della programmazione, molto facile da programmare in assembler...

Beh, sicuramente sarebbe piu' appropriato, ma sarebbe ancor piu' logico il paragone tra il 68020 (e non il 68000) con il 386, meglio ancora sarebbe il 68030. Anche se differiscono troppo per date d'uscita ed architetture, per trovare un paragone corretto.

In ogni caso e' iniziato tutto (questo discorso) sostenendo non tanto la potenza su carta delle cpu, ma l'efficacia in azione dei sistemi basati su architetture x86, che io, tutt'oggi, trovo ridicola, vista anche la tecnologia che esse implementano allo stato attuale..
Per renderti conto di cio' che dico ti basta prendere una suonblaster economica o usare le porte onboard di un pc odierno, che sia anche a 3-4 ghz, caricarci un cubase e sentirai come non sia assolutamente in grado di mantenere un tempo preciso.. sempre che ti intenda di musica ed abbia un orecchio allenato all'intendere queste cose.
Un atari lo faceva con 512kb di ram, 8mhz e 16bit di bus; il tutto nell' 85.. Ora sono passati 20 lunghissimi anni.. per un uomo sono tanti, ma per il campo informatico sono un era.. ed ancora non ci siamo. Gli esempi ovviamente non si limitano a questo. Se ne hai voglia rileggi tutte le discussioni!! hehe
Questo concetto e' scaturito da una mia considerazione nella quale vedevo come vantaggio non da poco, la non derivazione delle nuove console dall'architettura x86/pc-compatibili di mezzo secolo fa.

[fantoibed]

Originariamente inviato da cdimauro

Ti ho fatto notare che un 68000, per eseguire una NOP (che è un'istruzione che non fa nulla), impiega ben 4 cicli di clock.
Ti ho fatto notare che un 486 esegue la maggior parte delle istruzioni (quindi anche ben più complicate di una NOP) in un solo ciclo di clock.
Questo avrebbe dovuto farti dedurre che la disparità fra la "potenza di calcolo / efficacia" (qualunque cosa tu intendi con questi termini) è MOSTRUOSAMENTE a favore di quest'ultimo.

Che vantaggio ci sarebbe nell'eseguire un'istruzione che non fa' nulla in meno cicli di clock? ...Per la serie "non fa' nulla ma lo fa' più rapidamente..." ? (scherzo, eh!)

Riporto come supporto alla discussione 2 link in cui sono riportati i timings delle istruzioni generiche+ALU (nel primo) e FPU (nel secondo) sui 486:
http://fux0r.phathookups.com/program...ly/opcode.html
http://fux0r.phathookups.com/program...fpuopcode.html

Qui, invece, ci sono i timings delle istruzioni FPU sul 68881:
http://hysteria.sk/~mikro/Coding/Atari/Maggie/FPU.TXT

Se trovo i timings dei 68030 faccio un edit....

[cdimauro]

Originariamente inviato da MadRat

The 68000 architecture was much more flexible than other CPU familes (z80, 80x86, z80000, etc) as it could be very easily expanded to support full 32-bit data and address.
Questo viene dal link che non cpisci perche' io abbia postato..

Che conferma quello che ho detto sul 68000 e sul 68008: che l'architettura è a 32 bit, non a 16 né a 16/32 bit, come sostenevi tu.

In base alle non restrizioni dei bus a bittaggi inferiori-

E' una TUA considerazione, non un criterio OGGETTIVO.

Secondo me si dovrebbe far distinzione tra "emulare" ed "imitare", un 486 fa girare molto male l'emulatore amiga e per emulare un 68000 ha bisogno di frequenze spropositatamente superiori.

Infatti ho parlato di emulazione per farti capire che il 486 le potenzialità le ha tutte, visto che riesce a emulare il 68000 con cui TU l'hai messo a confronto.
Solo che emulare un 68000 vuol dire fargli fare lo STESSO IDENTICO lavoro, ma in maniera MOLTO più inefficiente: immagina cosa sarebbe in grado di fare "nativamente".

Se prendi un normalissimo 520st, e' in grado di far girare il 30% piu' velocemente (con lo spectre) un mac di pari frequrenza.

Questi dati dove li hai presi?

In oltre l'emulatore ST dell'amiga era pietoso, girava al 10% delle possibilita' di un vero st, era inusabile, poi, come provavi a lanciare un software entrava nella crisi piu' totale.

Mi sembra ovvio: le applicazioni che accedevano direttamente all'hardware non trovavano nulla dell'ST.

Era si e no in grado di emulare il descktop con lentezza esasperante, assolutamente non in grado di eseguire tutte le operazioni assegnate al dma, un st poteva formattare un floppy in backgrund senza rallentare il computer in alcuna maniera e se cubase si impallava e tornava al desk, la song continuava a suonare senza sbagliare un 64esimo nemmeno durante la fase di crash.

Le applicazioni "canoniche" (che non sfruttavano l'hardware direttamente) giravano bene. Poi è chiaro che per certe operazioni non era particolarmente versatile.

Ad esempio, l'Amiga non aveva un controller per il floppy a cui diceva: "prendi questi 512 byte e infilali nel settore 7 della traccia 123". Doveva prima codificare in MFM l'INTERA TRACCIA, effettuare il seek per posizionarsi sulla traccia giusta, selezionare la testina, e soltanto dopo spedire i dati col DMA.

Dunque mi sembra assurdo parlare d'emulatore st su amiga.

Infatti non l'ho fatto in questo contesto, ma ne ho parlato dopo (in un altro): qui parlavo di un PC con 486 che emula un Amiga con 68000 a 7Mhz.

(lo ho ed ho ancora diversi amiga assieme al loro software ed una bella collezione di retrocomputing a partire dal vectrex passando per l'archimedes e finendo al giorno d'oggi..)

Idem. Ma questo non c'entra niente col discorso...

Tenendo presente che anche gli emulatori attuali non sono in grado di visualizzare ad esempio le demo che rappresentino raster in overscreen, riducendoli nei colori pesantemente. Non sono nemmeno in grado di far girare in cubase con la precisione dell'originale.

Non vuol dire che non saranno in grado di farlo.

L'Amiga ha un hardware custom MOLTO più complicato da emulare rispetto a quello dell'ST: eppure WinUAE è quasi perfetto e permette di emulare un Amiga (1000, 500, 1200, 3000, 4000, ecc.) in maniera fedele, fino al ciclo di clock se necessario.

Allo stesso modo, esistono emulatori C64 molto fedeli, in grado di emulare perfino la pipeline interna del 6510.

Il problema è di avere persone qualificate che siano in grado di realizzare emulatori di questa levatura (presupponendo di avere tutta la documentazione disponibile, ovviamente).

Bene, secondo questo tuo assunto, tutti i difetti sono riconducibili alla mala programmazione e pessimi porting.. sempre che di porting si tratti..
All'atto pratico TUTTI i software presenti su entrambe le piattaforme giravano meglio (infinitamente meglio a parita di cpu, frequenze e memoria impiegata) su sistemi 68000 based.
Sara' stata tuta incompetenza dei programmatori.. mah!!

E' difficile trarre giudizi senza avere sotto mano i sorgenti dei programmi in questione e analizzarli.

Per quanto mi riguarda, conoscendo discretamente entrambe le architetture, penso che a un 486 non manca certo la potenza di calcolo per far girare bene le applicazioni di cui parli.

D'altra parte non hai detto anche tu che i 68000 bisogna saperli programmare per spremerli bene? Lo stesso vale per i 486...

Riguardo Halo non sono informato, ma mi parrebbe strano leggere di queste grandi differenze, vista la similarita' (identicita', piu' che altro) delle piattaforme in questione. Se hai qualcosa postalo.

Su google trovi un sacco di informazioni. Qui http://www.multiplayer.it/articolo.php?id=9935&lang=it ne trovi una recensione in cui parlano anche della conversione e dei suoi problemi. Ti riporto uno stralcio delle conclusioni:

"[...]Ma la conversione presenta non vari problemi (non è comprensibile che un titolo che girava bene su un Xbox, ossia un Pentium III 733 con 128 kbyte di cache L2 e una Geforce 3 con la sola aggiunta di un’unità di Vertex Shader rispetto alla Geforce 3 originale, giri con difficoltà su macchine molto più aggiornate). Ed è per questo che il voto di Halo rimane quello di un titolo che, per quanto bello, subisce il peso di una realizzazione non eccezionale.[...]"

Non mi risulta che il DSP 56001 sia quest'asso nelle istruzioni "General Purpose"

Che già è MOLTO DIVERSO da quel che avevi affermato prima:

"Poi informati riguardo il falcon, perche' il 56001 non e' ovviamente in grado di eseguire istruzioni GP,"

Non puoi dire prima una cosa (per di più per te era "ovvio"), e poi un'altra diversa, altrimenti dimostri di non avere adeguate conoscenze o di non avere un'idea precisa di ciò di cui stai parlando.

Cio' non toglie che la gestione di 160 ch midi (tramite un'interfaccia PASSIVA esterna e porta lan (di derivazione mac) in aggiunta a quelle di serie), non comporti minimamente l'utilizzo del dsp.

Infatti ho separato i discorsi: gestione dei canali MIDI -> seriale a 31000 baud, manipolazione audio e effetti speciali -> DSP 56001.

Un 486 non e' assolutamente in grado di gestire 16ch midi con precisione. Molti miei amici musicisti fino al 2ghz e passa si sono disperati per questo motivo. E' anche il motivo per il quale alla fine io non ho ancora cambiato, anche se prima o poi accadra'. Tutt'oggi un pc per avere una vera prestazione midi/hdr, necessita di una costosa scheda dedicata. Ma tanto tu sostieni che si tratti di malaprogrammazione.

Il tuo problema è che tu mischi processori e hardware in un gran calderone, tentando di forzare dei confronti senza alcuna base consistente.
Se parli di un 486, è una cosa. Se parli di hardware per fare musica, è un'altra cosa.

Se vogliamo testare le capacità di un 486 in campo audio, avrebbe senso farlo a parità di dotazione hardware, non credi?
Altrimenti potrei anche dirti che l'8086 a 4Mhz disintegra un 68060 a 50Mhz soltanto perché la NASA l'ha usato per lo Shuttle...

Come no.. si e' visto.. puo' farlo un vic venti ma non un 486.. nemmeno un athlon 1000..
Forse non si tratta solo di trasferire dati.. che ne dici??

Esatto, ma questo l'avevo già ampiamente affermato prima...

Per chiarire il discorso, visto che la battuta non è stata colta, volevo dire questo: l'interfaccia MIDI è una banalissima seriale a 31000 baud che può pilotare tranquillamente anche un VIC20 con un 6502 a 1Mhz. Poi bisogna vedere come lo si fa, appunto: con quale programma.

In questo caso rientra il fatto di vedere come è stato realizzato il porting delle applicazioni che usano la MIDI. Se, quindi, ha avuto la stessa "cura".
Perché può essere molto comodo comodo confrontare un programma scritto in assembly 68000 (o quanto meno nelle parti critiche) che si interfaccia direttamente ai registri (hardware) alla seriale/MIDI, con uno scritto in C (o altro) e che fa uso delle API di Windows per comunicare con la seriale/MIDI.

Spero che adesso sia chiaro il concetto.

E' proprio qui che non siamo d'accordo. Il problema e' che il pc e' un grosso accrocco costruito con molte toppe su fondamenta minuscole. (8bit e 640kb)

Hai mai programmato un PC con 386 in vita tua? E' un TANTINO DIVERSO da quello di cui conservi un cattivo ricordo...

Ma tu vivi nel mio studio?? Il primo masterizzatore comprato tantissimi anni fa era SOLO scsi e costava circa 13milioni di lire e mi sprecava CD del valore di 90mila.

Hai letto bene quello che ho scritto? Te lo riporto:

"Addirittura stai affermando che il masterizzatore era SCSI: hai mai provato a collegarlo, sempre con un'interfaccia SCSI, al 486? Vedrai che difficilmente brucerai dei CD."

Parlavo dello stesso masterizzatore che usavi (o che usi ancora) col Falcon.

Inoltre non abbiamo considerato i controller SCSI, che sicuramente saranno diversi, come pure i loro driver e i software per masterizzare.

A questo ho risposto ampiamente sopra. Poi se vuoi ti racocnto bene come nacquero l'amiga e l'ST.

Idem. Quanto alla loro storia non ne ho bisogno, grazie: la conosco molto bene.

La motorola lo abbandonò perche' schiacciata dal mercato. Le schede a 256 colori a basso costo di produzione orientale fecero diffondere il pc in modo assurdo e rapido.

Si parla di processori e te ne vai alle schede video: lo vedi che metti assieme delle cose diverse, mischiando tutto? Io quando ho parlato di processori ho confrontato solo loro e le caratteristiche che avevano. Non ho infilato in mezzo il DSP 56001 per l'audio o la Tseng ET6000 per la grafica.

Se ci fosse stata una pari evoluzione degli altri due sistemi, ora saremmo decisamente su un altro piano.

Coi se e i ma non si va da nessuna parte...

E' stata Motorola ad abbandonare la sua famiglia più famosa e su chi ha costruito molta della sua fortuna: non pensi che avrà avuto i suoi buoni motivi per farlo? S'è resa conto che con l'enorme competizione a cui era soggetto il mercato dei processori, i limiti strutturali dei suoi 680x0 l'avrebbero portata prima o poi a un vicolo cieco.

Il 680x0 aveva solo il limite di essere cisc,

Anche gli x86 sono CISC.

specialemnte nelle ultime versioni, possedeva potenza da vendere (060),

Questo nessuno l'ha mai negato.

ma un risc era sicuramente piu' efficace.

Sicuramente no, ai tempi. Sicuramente un RISC più moderno sì, perché è stato più facile scalare in frequenza.

(specialmente in ambito di malaprogrammazioneo o programmazione "facile"..)

I RISC non si programmano in assembly, ma con linguaggi ad alto livello.
Quanto alla "malaprogrammazione", non dipende dall'architettura ma dai programmatori.

Guidare una lamborghini e' piu' difficile che guidare una panda.. ma se lo si sa fare (e sottoline il SE) si ottengono risultati differenti.

Non si pone neppure il problema: la Panda è il 68000 e la Lamborghini è il 486 (in base al confronto che hai fatto).

Comunque io parlavo d'altro: delle difficoltà che un ingegnere ha nell'implementare una determinata architettura. Difficoltà che sono notevoli per i 680x0, ed era questo che volevo rimarcare. Il confronto Panda <-> Lamborghini qui non c'entra assolutamente nulla.

A me il 680x0 piace perche' non e' risc.

Idem. E lo stesso vale per gli x86 (con x >= 3).

anche se oggi non ha senso parlare di risc e cisc, i processori sono cosi' complessi da non poter essere piu' distinti in questo modo. Piu' che altro si adattano nell'evoluzione al tipo di istruzioni piu' richiesto.

Più che altro le istruzioni vengon aggiunte.
Comunque la distizione fra RISC e CISC c'è ancora.

Inoltre quello che hai scritto non c'entra niente con la parte che hai quotato.

Come sopra, a te piacicono le cose semplici, ma non e' una regola applicabile a tutti.

Non parlavo di tutto, ma di una cosa BEN PRECISA: il decoder delle istruzioni di un processore.

Ho detto che quello per un 68020+ sarebbe MOLTO più complicato da realizzare, e ti ho spiegato anche il perché.

Se c'è qualcosa di non chiaro, non hai che da dirlo: non ho problemi a farti altri esempi.
Se non sei d'accordo con ciò che ho detto, non hai che da fornire un contro-esempio.

Sarebbe possibilissimo iplementare le attuali tecnologie ad un'altra architettura.
Il discorso e' molto piu' complesso,in primis perche' oggi si richiede comuqnue un aggiornamento (politica del consumismo) continuo, che con certe architetture risulta piu' ostico (ma meno necessario).

Ma infatti io non ho detto che non si potrebbe fare: ho illustrato alcune problematiche su cui ci si scontrebbe nella realizzazione.

Non c'entra niente il consumismo: è una questione PURAMENTE TECNICA. Attieniti a questo nelle tue valutazioni.

C'e' da considerare anche che la tecnologia attuale e' cresciuta con i pc compatibili e dunque su misura per loro. Qualora fosse stata sviluppata su altre piattaforme, avrebbe sicuramente preso altre direzioni (quelle piu' opportune alle altre piattaforme, appunto).

Sono motivazioni che non reggono: la stessa tecnologia è usata da IBM con la sua famiglia Power (RISC), che con gli x86 ha ben poco a che spartire.

Sicuramente non ci sarebbe stata questa folle rincorsa alle frequenze, dalla quale per fortuna, AMD si sta (solo in parte) dissociando.

AMD non si è affatta dissociata: infatti continua a sfornare processori a frequenze più elevata. Tra poco arriverà l'FX a 2,8Ghz.
Allo stesso modo, anche IBM coi Power, e adesso con Cell e il processore dell'X-Box360, ha puntato molto sulla frequenza di lavoro. E anche qui, le architetture che ho elencato non hanno nulla a che vedere con gli x86.

Comunque, ripeto quanto scritto: io ho fatto delle considerazioni di natura strettamente tecnica in merito al fatto di vedere implementata l'architettura 680x0 con le tecnologie disponibili ai giorni nostri.
Puoi non essere d'accordo, e in tal caso ti pregherei di portare altrettanti argomenti tecnici, ma non puoi spostare il discorso verso altri lidi.

C'entra eccome, un pc oggi come oggi, senza schede dedicate e' ridicolo, entra in crisi in molti segmenti.

Un Falcon senza l'hardware dedicato è ridicolo, entra in crisi in molti segmenti.

Ne abbiam gia' parlato

Appunto. E tecnicamente non sei stato molto convincente sull'intrinseca superiorità dell'architettura 680x0 su quella x86 (in particolare, ti ricordo il 68000 a 8Mhz e il 486 a 66Mhz).

Forse non hai mai usato tutte le istruzioni di un 680x0,

Direi proprio di no: ho una discreta conoscenza sia dei 680x0 che degli x86...

Tu invece cosa, cosa mi racconti di bello? C'hai mai lavorato (a basso livello intendo), o ti sei limitato soltanto a usarli (i computer che li montavano)?

non essendo risc richiede una programmazione piu' complessa e "fantasiosa", ma queste cose le sai.

Al contrario: proprio perché lo so come si programmano, visto che l'ho fatto per parecchi anni e non mi sono certo limitato al classico "Hello, world!", so che un 68000 era piuttosto semplice da programmare rispetto a tanti RISC, tant'è che l'assembly era molto usato come linguaggio, perfino per scrivere i comandi DOS.

No, non e' uno scherzo, dovremmo vedere le date di produzione, comunque regge il paragone con un pentim senza problemi.. direi.

Non ho mai detto che non sarebbe paragonabile, anzi (propendo più il 68060, se non si fosse capito ). Ho soltanto detto che non potevi confrontare un 486 con un 68060, ma che quest'ultimo andava paragonato con il suo "naturale antagonista", il pentium.

Quanto alle date di produzione, 80486 e Pentium sono arrivati prima dei "rispettivi" 68040 e 68060.

Io affermai soltanto come il vincolo di compatibilita' con un'architettura di mezzo secolo fa, fosse un limite per gli attuali computer e che le nuove console potrebbero non esserne affette a tutto loro vantaggio.

Diciamo che ne sono meno affette, proprio perché sono "nuove".

Ma il tuo problema è che non riesci a capire / vedere che l'architettura di mezzo secolo fa è soltanto un vago ricordo, e che gli x86 di oggi sono ALQUANTO DIVERSI.

Se oggi si costruisse dal nulla un nuovo computer a parita' di frequenze, questo sarebbe impressionantemente piu' prestante di questi attuali.

Ovvio: potendo progettare tutto da zero, si potrebbe utilizzare meglio il silicio.

Ma tu parlavi di un 68000 costruito con le tecnologie attuali, che invece si porterebbe dietro tutti i problemi della sua architettura.

Poi tu ne hai iniziato un dibatito che io non avrei mai sostenuto (lì, almeno )

Non ho iniziato nessun dibattito: quel che ho scritto era un piccolo e semplice messaggio di precisazione.

Non ero d'accordo ed esistendo il diritto di replica (me lo concedi no??) deve finire chi ha parlato per secondo. Almeno cosi' si fa in democrazia.

Questo è un forum libero: limitatamente al regolamento, hai piena libertà di dire ciò che vuoi, e questo nessuno l'ha negato.

Ho soltanto detto che è troppo comodo pontificare e poi fuggire dicendo che il discorso si chiude qua.

Se ti vuoi confrontare, accomodati pure: per me non c'è problema.

Per quanto riguarda l'altro post, direi che le mie convinzioni riguardo l'indecenza dell'architettura di questi cassoni sia palesata ed anche la convinzione (mia e non solo mia) che le potenzialita' di macchine basate su 68000 siano maggiori di quelle basate su x86, sia altrettanto palesata.

A me sembra, invece, che sia l'esatto contrario, e ho scritto anche il perché. Dovresti "palesare" meglio il tuo pensiero, magari intavolando una discussione tecnica, senza mischiare processori e hardware in un gran calderone, e portando argomenti tecnici a sostegno delle tue tesi, perché finora non hai fatto altro che riportare le tue convizioni.

Convengo con te riguardo la difficolta' di programmazine, che oggi come oggi sarebbe un gran limite, vista la frenesia del mercato, ma questo e' un altro discorso ancora.

Sì, ma è pure sbagliato, come ho già detto: i 680x0 sono fra i processori più semplici da programmare (lasciando perdere i dettagli specifici, che comunque si ritrovano in tutte le architetture), e proprio per questo chi ha avuto modo di lavorarci ne conserva ancora un gran bel ricordo.

Insomma, per ora il mio falcon non mi sbaglia una nota di un 128esimo, un pc senza schede costosissime fa slittare note di 16esimi anche solo se si legge un cd e scrive una cache su hd.

Vedi sopra.

Comunque se qualcuno si passerà il capriccio di emulare il Falcon su questi schifosissimi PC, magari potrai finalmente metterlo da parte e continuare a non sbagliare una nota di un 128esimo...

[cdimauro]

Originariamente inviato da MadRat

Se metto un floppy con un dos dentro sul mio pc gira perfettamente e non in emulazione.. su un atari o un commodore non gira.. non mi pare che le infrastrutture siano poi cosi' cambiate..

Puoi spiegarti meglio? Con l'Amiga e l'ST si potevano leggere tranquillamente i floppy dei PC (da 720KB), e con gli appositi emulatori far girare i programmi (limitatamente al PC emulato).

Mi chiedo come tu faccia a parlare di "entrare in crisi" addirittura, non credo che alla IBM (cosi' come alla Sony ed atutte le altre grandi multinazionali che lo inseriranno nei loro mainframe) ne sappiano meno di te..

Non in tutti i mainframe: solo in quelli per cui il Cell è particolarmente orientato a livello di calcoli.

Non credo nemeno che tu ne abbia avuto uno per le mani. Quello che posso dire e' che la tecdemo di The Getaway, fatta girare solo con un cell simile (o forse definitivo) a quello che stara' nella ps3, senza l'ausilio della scheda video d'appoggio, e' veramente sbalorditivo e fa impallidire qualunque cpu gli si possa paragonare attualmente in produzione.
Poi puo' pure essere finto quel demo, ma credo in quel progetto.

Appunto, e hai fatto l'esempio giusto: per QUELLE COSE il Cell va bene (e neanche tanto: per l'IA non è ben predisposto).

Per i calcoli general purpose, però, già i PC di oggi sono molto più potenti.

Commercialmente ti do ragionissima, questo e' gia' chiarito e questo puo' relegarsi al discorso (pseudo inutile) che facevamo riguardo al 680x0.
Mentre l'architettura del Cell, che loro definiscono dicendo "abbiamo tolto le istruzioni meno usate o meno importanti, per incrementare drasticamente quelle piu' richieste e potenziarle all'estremo", concetto che somiglia molto ad un'estremizzazione del risc. Questo lo rendera' assai piu' semplice da programmare.

Sì, ma sempre per ciò per cui è stato pensato e progettato: il calcolo massicciamente parallelo / distribuito.

Sulla tua risposta a homero non mi pronuncio, visto che ho trattato gli stessi argomenti nel messaggio precedente.

[cdimauro]

Originariamente inviato da fantoibed

Che vantaggio ci sarebbe nell'eseguire un'istruzione che non fa' nulla in meno cicli di clock? ...Per la serie "non fa' nulla ma lo fa' più rapidamente..." ? (scherzo, eh!)

Era soltanto un esempio. Il discorso è partito da qui http://www.hwupgrade.it/forum/showth...=948317&page=5 e in particolare da questa frase:

"(un motorola 68000 a 16 bit a 8mhz ha il potenziale di un 486 a 32bit a 66mhz)"

di MadRat.

Ti consiglio di leggere il thread dall'inizio, così ti sarà tutto più chiaro.

Riporto come supporto alla discussione 2 link in cui sono riportati i timings delle istruzioni generiche+ALU (nel primo) e FPU (nel secondo) sui 486:
http://fux0r.phathookups.com/program...ly/opcode.html
http://fux0r.phathookups.com/program...fpuopcode.html

Qui, invece, ci sono i timings delle istruzioni FPU sul 68881:
http://hysteria.sk/~mikro/Coding/Atari/Maggie/FPU.TXT

Se trovo i timings dei 68030 faccio un edit....

Non ho trovato niente in giro...

Proprio l'altro ieri ho buttato un listato con i timing precisi del 68030.
Vediamo se nel week-end trovo il file da cui era stato stampato, ed eventualmente ne riporto qualche stralcio, se interessa (o tutto: non erano molto lungo l'elenco).

[cdimauro]

Scusate per gli strafalcioni grammaticali: non ho tempo né voglia di correggerli, anche perché comunque si capisce tutto...

[Spectrum7glr]

Originariamente inviato da cdimauro

Scusate per gli strafalcioni grammaticali: non ho tempo né voglia di correggerli, anche perché comunque si capisce tutto...

non ti preoccupare: da quello che scrivi si capisce che hai studiato...e non poco

[fek]

Originariamente inviato da MadRat

Se metto un floppy con un dos dentro sul mio pc gira perfettamente e non in emulazione.. su un atari o un commodore non gira.. non mi pare che le infrastrutture siano poi cosi' cambiate..

Anche se metti quel floppy dentro un Mac o un'Amiga, viene letto. Non mi risulta che un Mac sia cosi' simile ad PC degli anni '80

Fai un altro esempio

Mi chiedo come tu faccia a parlare di "entrare in crisi" addirittura, non credo che alla IBM (cosi' come alla Sony ed atutte le altre grandi multinazionali che lo inseriranno nei loro mainframe) ne sappiano meno di te..

Ne sanno molto piu' di me, infatti il Cell e' uno streaming processor, non un processore General Purpose.

Non ci vuole chissa' quale preparazione per capire che un processore con esecuzione in order e core semplificato (il PPE) va molto piu' piano su codice general purpose di un processore con esecuzione out of order e svariati transistor spesi in cose come branch pradiction et simili (P4 o AMD) a frequenze paragonabili.

Non credo nemeno che tu ne abbia avuto uno per le mani. Quello che posso dire e' che la tecdemo di The Getaway, fatta girare solo con un cell simile (o forse definitivo) a quello che stara' nella ps3, senza l'ausilio della scheda video d'appoggio, e' veramente sbalorditivo e fa impallidire qualunque cpu gli si possa paragonare attualmente in produzione.

Il Cell non e' in grado di fare rasterizzazione, tanto e' vero che gli hanno affiancato una GPU nella PS3. Su su su non portiamo techdemo da marketing ad esempio.

Commercialmente ti do ragionissima, questo e' gia' chiarito e questo puo' relegarsi al discorso (pseudo inutile) che facevamo riguardo al 680x0.
Mentre l'architettura del Cell, che loro definiscono dicendo "abbiamo tolto le istruzioni meno usate o meno importanti, per incrementare drasticamente quelle piu' richieste e potenziarle all'estremo", concetto che somiglia molto ad un'estremizzazione del risc. Questo lo rendera' assai piu' semplice da programmare.

E' esattamente il contrario. Proprio perche' hanno tolto tutta una serie di facility come l'esecuzione out of order, il multithreading nelle SPE, le cache sostituite con memoria privata da programmare esplicitamente, il Cell ha un paradigma di programmazione molto piu' complicato di una CPU general purpose. Infatti e' uno stream processor.

[Hal2001]

Masterizzatore 0,5X

[fantoibed]

Originariamente inviato da fek

Non ci vuole chissa' quale preparazione per capire che un processore con esecuzione in order e core semplificato (il PPE) va molto piu' piano su codice general purpose di un processore con esecuzione out of order e svariati transistor spesi in cose come branch pradiction et simili (P4 o AMD) a frequenze paragonabili.

Sinceramente non sono convinto che lo spostamento dall'hardware al software dei sistemi di esecuzione out-of-order, branch prediction, register renaming, speculation, delle varie tecniche per ottimizzare il parallellismo ILP e TLP (tipo hyperthreading), ridurre la latenza, eccetera porti sicuramente ad un peggioramento delle prestazioni. D'altra parte tutti quei milioni di transistor risparmiati per l'assenza di queste tecnologie in hardware possono essere sfruttati per poter inserire più unità di calcolo o una cache più grande, ecc...

La maggiore complessità per il programmatore potrebbe essere relativa, nel senso che sistemi di code morphing e API ad alto livello potrebbero spostare la parte "rognosa" di codice a kernel level!

Tu che programmi videogiochi, suppongo che scriverai codice ad alto livello interfacciandoti a qualche libreria apposita per la gestione della scena 3D, tipo OpenGL o DirectX e non ti tocca molto da vicino il fatto che l'ISA di questa o quella GPU sia "rognosa" da programmare in assembly: questo problema casomai sarà di chi sviluppa i drivers, non di chi scrive i giochi.

Analogamente, se realizzassero una virtual machine di alto livello (cosa che va sempre più di moda, vedasi Java prima, .Net poi e via dicendo) non sarebbe difficile scrivere software per la macchina virtuale. Il problema dell'ISA ostica verrebbe affrontato una volta per tutte da chi sviluppa la virtual machine....

....mi rendo conto che il discorso potrebbe aprire molti filoni e, vista anche la carenza di informazioni, resta moooolto "fumoso". Visto anche che siamo OT qui e che ci sono molti thread aperti in cui si parla di TheCell, perchè non ci accodiamo a qualche altra discussione o, ancor meglio, perché non apriamo su "Processori" un thread tipo "The Cell - il thread ufficiale" o qualcosa del genere?

[fek]

Originariamente inviato da fantoibed

Sinceramente non sono convinto che lo spostamento dall'hardware al software dei sistemi di esecuzione out-of-order, branch prediction, register renaming, speculation, delle varie tecniche per ottimizzare il parallellismo ILP e TLP (tipo hyperthreading), ridurre la latenza, eccetera porti sicuramente ad un peggioramento delle prestazioni. D'altra parte tutti quei milioni di transistor risparmiati per l'assenza di queste tecnologie in hardware possono essere sfruttati per poter inserire più unità di calcolo o una cache più grande, ecc...

Purtroppo non abbiamo la controprova perche' questi tool e questi compilatori non sono stati ancora scritti. Per quello che ne sappiamo ora, allo stato attuale delle cose, una CPU con esecuzione in-order e con cache limitata come il PPE va piu' piano sul codice general purpose. Poi, se ci saranno i tool, se i compilatori saranno in grado di fare il lavoro che oggi fa la CPU, se la cache minore non sara' un problema (cosa che non credo), allora se tutte queste condizioni saranno vere potremmo fare considerazione differenti. Al momento queste condizioni non sono ne' vere ne' dimostrati tali, anzi, ci sono fortissimi dubbi che i compilatori saranno in grado staticamente di fare quello che la CPU fa dinamicamente in base alle condizioni di esecuzione. Lo stesso codice, ad esempio, puo' avere profili prestazionali di esecuzione totalmente differenti a seconda di quando e' eseguito e dopo che cosa e' eseguito, ed e' una cosa che un compilatore non sara' mai in grado di prevedere per ovvi motivi.

Tu che programmi videogiochi, suppongo che scriverai codice ad alto livello interfacciandoti a qualche libreria apposita per la gestione della scena 3D, tipo OpenGL o DirectX e non ti tocca molto da vicino il fatto che l'ISA di questa o quella GPU sia "rognosa" da programmare in assembly: questo problema casomai sarà di chi sviluppa i drivers, non di chi scrive i giochi.

Il discorso sul Cell facile o difficile da programmare non e' sull'ISA, ma sul modello di programmazione inerentemente complicato al di la' del set di istruzioni e questo non puo' essere nascosto ne' dalla libreria' ne' dai tool. Il Cell si programmera' in maniera totalmente diversa da una CPU classica, bisognera' suddividere il problema in maniera che si adatti ad un'architettura che lavora in streaming, senza cache e la stragrande maggioranza dei problemi non si adatta a queste condizioni. Ad esempio, ricerche in grafi, rasterizzazione di poligoni, IA sono tutti problemi che non sono agevoli da trattare come un "flusso di dati sul quale esegui operazioni". Qui non c'e' tool di sviluppo o compilatore o code morphing che tenga: il Cell si inchioda perche' non e' progettato per fare quelle cose.

Avevo fatto una volta l'esempio dell'idraulico: se gli chiedi di aggiustarti un rubinetto e' un missile, se gli chiedi di tagliarti l'erba magari ci riesce anche, ma un giardiniere e' piu' veloce.

Usare OGL o D3D non toglie che se voglio far andare le cose veloci devo sapere come e' fatta all'interno la GPU anche in minimi particolari, altrimenti quello che scrivo va... ma piano. Quando si tratta di fare andare le cose veloci e' necessario sapere come l'hardware e' implementato all'interno e il suo design detta le ottimizzazioni e gli algoritmi.

Un esempio: l'API per usare una Texture3D e' la medesima in OpenGL e D3D su NVIDIA e ATI. Ma se non so che su ATI un pattern di accesso ad una Texture3D che segue solo l'asse z e' lento, mi trovo lo stesso codice che va 10 volte piu' lento su un R4X0 rispetto ad un NV4X.

....mi rendo conto che il discorso potrebbe aprire molti filoni e, vista anche la carenza di informazioni, resta moooolto "fumoso". Visto anche che siamo OT qui e che ci sono molti thread aperti in cui si parla di TheCell, perchè non ci accodiamo a qualche altra discussione o, ancor meglio, perché non apriamo su "Processori" un thread tipo "The Cell - il thread ufficiale" o qualcosa del genere?

Ci sono molte informazioni sul Cell, la sua architettura non e' piu' un mistero ormai.

[fantoibed]

Originariamente inviato da fek

... ci sono fortissimi dubbi che i compilatori saranno in grado staticamente di fare quello che la CPU fa dinamicamente in base alle condizioni di esecuzione.

Infatti dovrebbe farlo dinamicamente il sistema operativo (o la virtual machine) e non staticamente il compilatore...

Originariamente inviato da fek

Ci sono molte informazioni sul Cell, la sua architettura non e' piu' un mistero ormai.

Sull'architettura no, ma sul software (vm, api, os, compilatori, ecc...) sì...