Confronto fra i486 e Motorola 68000

[jappilas]

Originariamente inviato da lowenz

Io voglio il parere di repne scasb

un po' in effetti mancano, quei suoi post privi (gli ultimi a parte) di emozione, ma ricchi di assembly...

[DioBrando]

Originariamente inviato da lowenz

Io voglio il parere di repne scasb

scusate l'OT...cmq è un peccato che non partecipi +

sicuramente ci sn altre teste con quel livello di preparazione tecnica cmq una in + male n faceva...

Fine OT


continuo a seguire con interesse il thread e complimenti a tutti cmq per le nozioni sviscerate

[fek]

Originariamente inviato da fantoibed

Io non sto facendo proprio nulla. Assisto solo sbalordito ai tuoi comportamenti.
Chi sa leggere si rende conto del mio atteggiamento e del tuo, e sa valutare le mistificazioni...

Esatto. E a quanto pare chi ha letto mi ha gia' dato ampiamente ragione. Ti ripeto che se i miei comportamenti non ti aggradano puoi comunicarmelo in PM. Ma non sembra che a te interessino i miei comportamenti, sei piu' interessato a farmi una member war dopo essere rimasto scottato dall'andamento della discussione.

Continua a piagnucolare da solo adesso...

[fantoibed]

Originariamente inviato da fek

Esatto. E a quanto pare chi ha letto mi ha gia' dato ampiamente ragione. Ti ripeto che se i miei comportamenti non ti aggradano puoi comunicarmelo in PM. Ma non sembra che a te interessino i miei comportamenti, sei piu' interessato a farmi una member war dopo essere rimasto scottato dall'andamento della discussione.

Continua a piagnucolare da solo adesso...

Continua così che vai forte!

[jappilas]

O_o sperando di abbagliarmi, ho l' impressione che il thread stia proseguendo su incomprensioni reciproche e la tensione stia salendo

questo imho dovrebbe restare un reference thread su una comparativa architetturale... non litigate, vi scongiuro

[fantoibed]

Originariamente inviato da jappilas

O_o sperando di abbagliarmi, ho l' impressione che il thread stia proseguendo su incomprensioni reciproche e la tensione stia salendo

questo imho dovrebbe restare un reference thread su una comparativa architetturale... non litigate, vi scongiuro

Infatti sto cercando di evitare di rispondere alle provocazioni di fek.
Aspetto di vedere se i moderatori prenderanno provvedimenti oppure no.

[MadRat]

Originariamente inviato da cdimauro

Non c'è bisogno: so anch'io che molti hanno classificato e classificano ancora il 68000 come processore a 16 bit.
Io ti ho dimostrato che internamente l'architettura è a 32 bit, con tanto di registri dati/indirizzi a 32 bit e bus dati interno e indirizzi a 32 bit, e che soltanto il bus dati esterno è a 16 bit e quello indirizzi a 24 bit.
PERSONALMENTE (notare il maiuscolo) la ritengo, quindi, un'architettura a 32 bit.
Adesso rinnovo la domanda: mi porti un CRITERIO OGGETTIVO per definire un'architettura a "n bit"? Bada bene: non un link a una rivista, ma uno studio che mi dia una DEFINIZIONE FORMALE di architettura a "n bit" e che mi consenta quindi di classificare in maniera precisa, univoca e oggettiva una determinata architettura in base alle sue caratteristiche.
Inoltre ti faccio nuovamente notare che il 68008 ha la STESSA ARCHITETTURA INTERNA di un 68000, ma il bus dati esterno è a 8 bit (indirizzi a 20): lo classificheresti come processore a 8 bit soltanto per questo?

Esattamente, un processore "castrato", non vale quanto un processore che possa lavorare al suo massimo. Ma a quanto pare il tuo parere "tecnico" vale piu' di quello del resto del mondo.

Originariamente inviato da cdimauro

Era discretamente fluido, dai miei ricordi. Purtroppo non ho sotto mano un Amiga, ma appena posso lancio WinUAE, lo configuro come un Amiga 500 con emulazione perfetta (al ciclo di clock, quindi né più lento né più veloce sulle mie macchine), e lo riprovo.

I tuoi ricordi sono offuscati, non girerebbe fluido come un st nemmeno su un A4000.
Quasi quasi me lo ricarico su un amiga vero e non emulato.

Originariamente inviato da cdimauro

Hai un ricordo molto confuso e poco attinente alla realtà.

Riporto qualche stralcio, giusto per farti prendere coscienza dell'erroneità delle tue informazioni.
Partiamo dall'Amiga 1000 (il primo modello) e dalle sue caratteristiche tecniche:

Ed ecco quelle dell'ST:


Proprio la stessa cosa, vero? E non ho riportato informazioni su tante altre caratteristiche...
Mi limito a riportare qualche commento:

Un bel computer, non c'è che dire...

Dipende tutto dal sito dal quale prendi i link.. Se noti quello dell'amiga e' farcito di commenti e spiegazioni, quello ST e' solo un elenco tecnico poco completo per altro.
Ad esempio TI SEI SCORDATO di dire che l'st usci' con le porte midi, non solo per conquistare il mercato musicale (come fece), ma anche per surrogare il chip audio poco costoso implementato nella macchina e molti giochi, se collegati ad un economicissimo roland mt32, uscivano in audio con questo (dopo che il gioco stesso lo aveva programmato) e ti assicuro che il cio' ridicolizzava il fantomatico audio dell'amiga, soprattutto dal punto di vista musicale ed in oltre risparmiava memoria preziosa. La soluzione non e' logicamente stata usata quanto le caratteristiche avanzate dell'amiga (vista la ovviamente scarsa diffusione dell'MT32 se paragonato ad un chip di serie), ma ne hanno ridotto il costo facendo sì che l'ST fosse il computer piu' vendto del mondo (fino al guinnes dei primati del 97, poi oltre non l'ho piu' comprato). Tant'e' vero che la commodore e' fallita assai prima dell'Atari. (94).

Secondo poi la schiacciante superiorita' architetturale del'Amiga, generava un gap prestazionale notevole in ogni gioco che facesse uso di grafica poligonale. Questo lo motiviamo con 0.84 mhz in meno??
Se prendi una punto e la vesti da rolce royce, hai la comodita' di quest'ultima e le prestazioni di una bicicletta.

Il progetto Amiga ne 94 rischio il crash vista l'esosita' dello stesso. Richedeva troppe risorse finanziarie e di tempo. Fu comprato incompleto dalla Comodore (avrebbe dovuto comprarlo l'atari che era gia' in trattative e possedeva parte del team di sviluppo, situazione dalla quale scaturi' una controversia legale tra le due case).
Sta di fatto che la Comodore si trovo' in mano un computer incompleto e complesso, privo anche di un amiga dos finito e di un qualunque altro sistema operativo degno di questo nome, il workbench infatti non era su rom e non era certamente degno della concorrenza. (la complessita' dell'hardware portò vantaggi e svantaggi). Assolutamente non paragonabile con il TOS della digital, forse scopiazzato da quello che vendette anche apple, ma decisamente il migliore all'epoca (so bene come non fosse multitasking, ma sarebbe stato prematuro per le conoscienze del tempo).

Io sul mio ST usavo tranquillamente 512 colori contemporaneamente e sull'STE ne usavo 4096.
In ogni caso i due computer primeggiavano nei loro rispettivi campi ed a parer mio il vantaggio dell'amiga non giustificava un costo DOPPIO rispetto a quello dell'ST.
La grafica evoluta cosi' come l'audio, richiedevano grandi quantitativi di ram, al tempo molto costosa. Anche questo io giudico nell'equilibrio di un progetto.

Non nego che L'Amiga fosse una grande idea, ma conservava dei punti deboli e per di piu' finì nelle mani gestionali piu' errate. La commodore senza Tramiel non valeva piu' nulla.

Originariamente inviato da cdimauro

Risaputo... Allora doveva essere un fatto noto: com'è che nelle riviste dell'epoca, in cui è stato recensito, non trasparivano questi dati?

Non lo so, forse all'epoca ancora non sapevi leggere?? o piu' probabilmente eri chiuso nel mondo amiga.

Originariamente inviato da cdimauro

Anche per l'Amiga valeva lo stesso, e tra l'altro non era necessario avere un'interfaccia esterna per la rom.

Forse non sai ancora leggere ora che ci penso; io ho detto che esisteva **"ANCHE"** una versione con le ROM sulla porta d'espansione. Questo era utile per accendere il computer e senza caricare nulla, avere un MAC piu' potente dell'originale e "con tutta la ram libera".. Difficile da intuire vero??

Originariamente inviato da cdimauro

La risoluzione video era maggiore di quella offerta dall'ST(640x400 per NTSC e 640x512 PAL, e inoltre erano disponibili le modelità overscan con A-Max: 704x480 NTSC e 704x576 PAL).
Inoltre grazie all'uso del Blitter tutta la parte grafica del Mac veniva scaricata su questo processore, e le prestazioni erano superiori al Mac Plus a col 68000 a 8Mhz (nell'ST, come nel Mac, doveva essere il 68000 a gestirle; gli ST col Blitter sono arrivati dopo, con l'STE, e sono state poche le applicazioni ad usarlo).

Indubbiamente dal punto di vista grafico (solo se si parla di bitmap) l'amiga era piu' prestante, ma a me risulta che l'impiego di overscreen e piu' colori di quanti imposti dal SO, fosse una realta' anche su ST (certamente meno diffusa e piu' limitata).
Per quanto riguarda l'STE, era un'ottima macchina poco sfruttata. La parte audio era il doppio piu' potente di quella dell'amiga (4 ch a 50khz o 8 a 25khz).
Un evoluzione possibile grazie all'abbassamento dei costi dell'hardware e ad un armonico potenziamento della macchina. C'e' da dire che Atari (come comodore) riteneva il proprio ST "perfetto" e ritardo' per questo l'uscita della versione "E", cosi' come quella del falcon. Quest'ultimo usci castrato per via della nascente crisi economica (avrebbe dovuto avere un 60030/40 a 32mhz e due dsp56001).
Se poi il tuo concetto di superiorita' e' dettato solo da un audio ed una grafica piu' evoluti, senza badare alla funzionalita', ai costi ed alle altre prestazioni.. beh, allora parliamo di x68000.. L'Amiga scompare d'incanto.
Fortunatamente un computer non e' fatto solo d'apparenza e di giochi.

Originariamente inviato da cdimauro

Le idee confuse le hai tu, invece. Guarda qui: http://www.emuita.it/emu.php?cat=Atari%20ST e in particolare

"CPU audio: AY-3-8910 ed interfaccia MIDI (la cui gestione era a carico della CPU)"

Come accadeva con tutti gli altri computer dell'epoca: veniva generato un interrupt quando c'era un byte disponibile da leggere, ed era possibile generare un interrupt quando il buffer di invio poteva accettare un altro byte da spedire.

Un programma di annotazione midi su pc, mac o amiga quando va in crash e torna al desk smette di suonare, con l'st non succedeva. Questo fa la differenza per un professionista. Qualunque spiegazione tu abbia.

Originariamente inviato da cdimauro

Assembly (il linguaggio), non assembler (il compilatore).

Non li ho fatti io né ho i sorgenti a disposizione per poter controllare.

Alla fine quando si parla con te, finisce tutto per essere ricondotto ad una mala programmazine. Mentre secondo me, se una determinata tipologia di programmi girava "sempre" meglio, si puo' parlare di comprovata superiorita' hardware (almeno nel segmanto).

Originariamente inviato da cdimauro

Anche qui hai le idee un po' confuse. Sempre dal link di cui sopra che parla dell'Atari ST:

Le origini sono sempre le stesse... Con un po' di lifting...

A parte la poca pertinenza con l'argomento, le idee confuse le hai tu.
Il TT era l'evoluzione a 32bit (anche se per te e' inoncepibile questo argomento), dell'ST, venduto come postazione professionale!!. Il falcon usci molto tempo dopo come macchina completamente nuova che, dall'ST avrebbe dovuto ereditare solo la fascia di mercato, il case ed una discreta retrocompatibilita'. L'unico difetto fu la data di lancio, come detto prima, il progetto era pronto nel 90/91 e fu lanciato a meta' 93.

Originariamente inviato da cdimauro

No, hanno molto in comune coi 386, invece. Hanno tagliato i ponti con l'8086 e il 286 (anche se non è del tutto vero: è sempre possibile eseguire codice 8086 e 286, ma ciò non comporta alcun handicap per tutto il resto dell'architettura), ma il 386 è stato sostanzialmente il progenitore di tutte le architetture x86 moderne.
Quindi, anche se "partita male" (a me non è mai piaciuto né l'8086 né il 286), col 386 si è messa sulla giusta strada.

Non era una questione di inferiorita' architetturale quella che causo la dismissione evolutiva dei 68k, bensi' il diffondersi di un'altra piattaforma. La motorola provo' anche a creare uan versione RISC del 68000, chiamata inizialmente 78000 e poi 88000, ma a nulla servi', passo quasi inosservata.

Originariamente inviato da cdimauro

E qual è il problema? Le schede grafiche dei PC, dopo la VGA, erano diventate molto efficienti e competitive, mentre l'hardware dell'Amiga rimaneva sostanzialmente fermo (l'ST navigava in acque peggiori).

E chi ha parlato di problemi?? Io non di certo!!
Era solo la motivazione per la quale i pc, grazie alla loro modularita' ed espandibilita', (che e' il loro unico punto di forza) e grazie a taiwan, sopraffecero i computer che "puzzavano" di stantio (incredibile, siamo d'accordo su qualcosa).
Ma se non fosse stato per il mercato orientale, il pc sarebbe rimasto per sempre relegato al ruolo di macchina da ufficio, vistone il costo assurdo per l'uso domestico ed i vantaggi inesitenti.

Originariamente inviato da cdimauro

Questo cosa c'entra con l'abbandono dei 680x0 da parte di Motorola? Nulla.

Ma no, certo, come posso non averci pensato prima!! La motorola avrebbe dovuto sprecare milioni di dollari per lo sviluppo di una cpu che oramai non era piu' usata da nessuno!!
Comuqnue alla fine il ppc eredita parte delle caratteristiche del 68k, ma paragonato ad un 68060, (di pari epoca) e inferiore. Alla fine sono solo scelte commerciali dettate non solo dalla motorola, ma anche dai suoi partner.

Originariamente inviato da cdimauro

L'Amiga fino al 1996 è rimasta la piattaforma d'elezione per i giochi, ed esistevano già da parecchi anni le schede SuperVGA: poi la Commodore è morta e così il mercato dei giochi si è definitivamente spostato sui PC (gli ST, come al solito, non erano molto considerati).

Gli ST non furono considerati solo negli ultimi anni, quando l'Amiga riusci a raggiungere un prezzo decente. E questo riguarda solo ed ESCLUSIVAMENTE il mercato vudeoludico, del quale parli tu, mercato che ha fatto affermare i pc come standard, ma che tuttavia non e' l'unico target di un utente (né di ora, né del tempo).

Comuqnue sono d'accordissimo con chiunque sostenga che dal punto di vista ludico, l'amiga fosse piu' idoneo. Questo perche' aveva grandi capacita' di manipolazione delle bitmap, che al tempo erano il fulcro dei giochi. Mentre l'evoluzione del mercato ha poi decretato la vittoria della grafica poligonale.

Originariamente inviato da cdimauro

Ripeto: schede video e bontà del processore sono due cose completamente diverse che vanno valutate separatamente.

Non ho mai affrontato quest'argomento.

Originariamente inviato da cdimauro

A me non fa ridere: continuo a ritenerla un'ottima architettura. Con tutti i suoi limiti, ovviamente. E un 386 fa tutt'altro che ridere...

Non è così e te l'ho già spiegato quando ti ho mostrato le difficoltà intrinseche della realizzazione di un 680x0 utilizzando le tecnologie attuali.

Ti avevo già detto che se avevi bisogno di ulteriori chiarimenti, ero disponibile a fornirteli: non hai né capito né chiesto spiegazioni.

Ok, spiegami perche' da un'evoluzione teorica di un 68060, non si potrebbe arrivare a processori piu' potenti degli attuali. Al tempo uno 060 lasciava ben poco spazio ad un pentium, eppure il pentuim era venduto un milione di volte piu' del motorola.
Credo che il commercio c'entri poco con la qualita', basti vedere lo standard vhs.. contro i portentosi video2000.

Originariamente inviato da cdimauro

Non mettermi in bocca parole che non ho detto. Tu hai detto questo:

"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)"

e io ho risposto con questo:

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

E molto prima dicesti: "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.

Poi l'elogio alla semplicita' dell'architettura x86 continuava.. Mah..

Originariamente inviato da cdimauro

Non ho negato il fatto che altre architetture potessero far uso delle medesime tecnologie (e infatti è ciò che fa IBM con la famiglia Power, che sono dei RISC), ma ho anche detto che bisogna valutare le PROBLEMATICHE INTRINSECHE che si portano dietro.

Ne ho parlato pocanzi

Originariamente inviato da cdimauro

Invece dimostra esattamente ciò che ho detto: che la conversione ha subito delle modifiche consistenti (e ciò traspare anche da quella recensione, e da tutte le altre) che hanno appesantito molto il gioco, elevando i requisiti per poter godere di una giocabilità equivalente a quella dell'X-Box.

Insomma, io sotengo che a parita' di hardware, un pc sia drasticamente meno performante, tu sostieni che questo non sia vero, ma all'atto pratico halo su pc richiede un HW 2 volte piu' potente. Gia', dimenticavo, tu riconduci tutto a problemi di porting anche su piattaforme similisime. I credo piu' che altro che il pc sia ridicolo dal punto di vista prestazionale e l'xbox sia la palese dimostrazione di quello che si potrebbe fare abbandonando le strutture che tu dici non esistere piu' o quantomeno non essere limitative.

Per quanto mi riguarda, l'oggettivita degli eventi va ben oltre a qualunque "teoria".

Originariamente inviato da cdimauro

Appunto. Mentre prima tu prima hai COMPLETAMENTE NEGATO questa possibilità.

La mia negazione era assoluta non meno di quanto lo fosse la tua relativamente ai dsp cell.

Originariamente inviato da cdimauro

Se l'intorno lo prendi con lo scarto di 1Ghz, sono d'accordo con te. Ma mi sembra un po' troppo...

Che simpatico, tuttavia AMD lavorando sull'efficienza, piu' che sulla potenza bruta dei mhz, vendeva un 2,2ghz come oppositore di un 3,2 (scarto di un ghz ancora presente, rispetto ai processori Intel) e questa differenza si e' accumilata per lo piu' durante il 2003. Solo con l'avvento dei K8 si e' spinta oltre i 2,2 ghz.. frequenza che raggiunse molto tempo prima.

Originariamente inviato da cdimauro

Non è che lo penso: E' possibile.

Tra il dire ed il fare..

Originariamente inviato da cdimauro

Non è esatto: per adesso non ci si è messo nessuno...
MAME e MESS emulano già sistemi molto più complessi del Falcon. Perfino il Jaguar, che ha un hardware superiore e più complicato di quello del Falcon, viene già emulato dal MESS a piena velocità (ho due Athlon64 2800+ a casa).

Mi dai un link con un emulatore Jaguar degno di questo nome??
Per ora io uso quello vero.

Originariamente inviato da cdimauro

Non credo proprio. Non solo l'IDE, ma anche lo SCSI viene già emulato tranquillamente da MAME e MESS e non presenta i problemi di cui parli.

Infatti non parlo di problemi emulativi.. ma del pc stesso, al difuori di ogni emulazione. Sono problemi che tutt'ora affliggono questi sistemi ed (nel campo musicale si riflettono in particolar modo), rendono praticamente inutilizzabile un pc privo di una costosa scheda che lavori per conto proprio.
Se questa me la chiami evoluzione..

Originariamente inviato da cdimauro

Non c'è problema: se la chiave hardware è collegata alla porta seriale o parallela, che vengono già emulate perfettamente, ti basterebbe attaccarla e lasciarle credere che sta girando su un vero computer...

Purtroppo quasi tutte le chiavi di protezione dell'atari, come anche quella del cubase Audio, erano inserite nella porta laterale per cartucce d'espansione. (come lo spectre gcr).. Dunque mi sembra un po' difficile inserirla in un pc. Il problema purtoppo non si pone, vista l'inesitenza dell'emulatore.
Non sai che darei per averlo, ma purtroppo nemmeno quello dell'ST e' ancora perfetto.

[MadRat]

Originariamente inviato da fantoibed

Hai ragione. Hai ragione perché non si può discutere con te.
A certe persone è meglio dare ragione anche quando dicono che la Luna è fatta di formaggio.

Originariamente inviato da fek

[img]
Con me si puo' discutere, e me lo dicono tutti a parte te. Ci sara' un perche'
E quando si parla di processori, gpu e programmazione, so di che cosa sto parlando, non mi invento che una memoria locale e' un processore.

Ora devi continuare a metterla sul personale oppure la smetti con questa pagliacciata? E' la terza volta che te lo chiedo. Se non ti piace come mi comporto puoi sempre comunicarmelo in PM.

Fek, discutere con te e' molto difficile, tendi a prevaricare non ascoltando, travisando le argomentazioni e puntando su tematiche tecniche spesso non chiamate in causa, questo solo per spiazzare un eventuale interlocutore piu' inesperto nell'ambito al quale vuoi sempre ricondurre i tuoi discorsi.
L'impressione che si ha, tuttavia, e' che tu voglia affermare tramite spiegazioni, che la terra giri al contrario.

Purtroppo non tutte le "battaglie" si possono combattere in casa, altrimenti ti direi "giochiamoci la soluzione alle nostre controversie su due ruote" o "vediamo chi disegna meglio una vignetta al riguardo" o ancora a chi la musica meglio..

Forse ti manca una bella dose di umilta' e la capacita' di ascoltare cio' che la gente ha da dire.

[fantoibed]

MadRat, pensa che finora mi ero interessato solo di sviscerare l'architettura di Cell ma visto che spesso in queste discussioni si contrappone il Xenon, il processore di Xbox360, mi sono incuriosito e sono andato a leggermi qualche articolo e..... sorpresa! E' anch'esso basato sull'esecuzione in-order:

http://arstechnica.com/articles/paed...box360-2.ars/3

L'articolo è aggiornato, il sito è affidabile, l'autore è molto conosciuto e preparato....
Poi ognuno tragga le sue conclusioni....

Tra l'altro a pag.4 di quell'articolo dicono che Xenon avrà una pipeline lunga (21 stadi, come il Pentium4 Northwood).
Ma come? La Intel sta per pensionare il netburst e la CPU dell'Xbox360 inizia ora la strada delle pipeline lunghe?

Bah, io non vedo proprio tutta questa differenza tra Xbox e PS3 nella CPU, almeno non tanto da paragonarli ad una Punto e una Ferrari. Per me la differenza è minima e la pipeline corta del Cell potrebbe portare a dei vantaggi. Alla fine penso che, con queste premesse, la differenza di prestazioni si giocherà tutta sulla GPU.
Aspetteremo e vedremo.

[MadRat]

Originariamente inviato da fantoibed

MadRat, pensa che finora mi ero interessato solo di sviscerare l'architettura di Cell ma visto che spesso in queste discussioni si contrappone il Xenon, il processore di Xbox360, mi sono incuriosito e sono andato a leggermi qualche articolo e..... sorpresa! E' anch'esso basato sull'esecuzione in-order:

http://arstechnica.com/articles/paed...box360-2.ars/3

L'articolo è aggiornato, il sito è affidabile, l'autore è molto conosciuto e preparato....
Poi ognuno tragga le sue conclusioni....

Sorpresa!!

Originariamente inviato da fantoibed

Tra l'altro a pag.4 di quell'articolo dicono che Xenon avrà una pipeline lunga (21 stadi, come il Pentium4 Northwood).
Ma come? La Intel sta per pensionare il netburst e la CPU dell'Xbox360 inizia ora la strada delle pipeline lunghe?

Bella ca... che hanno fatto, pure intel sta tornando sui propri passi, il pentium m, basato sull'architettura del vecchio P3, e' molto piu' efficace e potente dei P4 EE a frequenze spropositatamente piu' elevate, e soprattutto nei giochi, si e' rivelato sorprendentemente piu' veloce anche di AMD64 (ovviamente a 32bit).

Per chi volesse dare un'occhiata..
http://www.tomshw.it/cpu.php?guide=20050525
Sempbra assurdo come una cpu piu' simile ad un pentium3 costruito a 90nm, possa ridicolizzare cosi' un P4EE ed un Athlon FX!! Gli unici cali sono sui bench delle memorie, ma all'atto pratico, nel vero utilizzo non pesa affatto.
Senza tener conto del non utilizzo da parte del P-M di tecnologie avanzate e costose come le ddr2 del P4 ad esempio.
Credo che quest'argomento possa meritare un Thread tutto per se!!


Mi chiedo dopo l'esperienza Intel, come si faccia a perseguire la strada delle pipe lunghe.. e quanto lunghe!!

Originariamente inviato da fantoibed

Bah, io non vedo proprio tutta questa differenza tra Xbox e PS3 nella CPU, almeno non tanto da paragonarli ad una Punto e una Ferrari. Per me la differenza è minima e la pipeline corta del Cell potrebbe portare a dei vantaggi. Alla fine penso che, con queste premesse, la differenza di prestazioni si giocherà tutta sulla GPU.
Aspetteremo e vedremo.

Io seguito a credere molto nell'efficienza del Cell, soprattutto inserito in una console.. Il P4 e' gia' un fiasco di suo, ma nell'impiego ludico ha dei limiti allucinanti.

[cdimauro]

Originariamente inviato da fantoibed

Su questo non c'è dubbio, ma considera che il branch prediction hardware su CPU OOO non è infallibile, soprattutto nei videogiochi in cui è difficile prevedere le azioni di tutti i giocatori, delle AI, ecc...

Cerchiamo di chiarire le cose: tutti i processori più moderni, siano essi Out-Of-Order o In-Order, utilizzano dei sistemi di branch prediction.
Per cui è chiaro che i branch miss sono legati alla loro implementazione, non al tipo di architettura OOO o IO in cui sono inseriti.

Qui:http://www.research.ibm.com/people/m...s/2004_msp.pdf vengono stimate su un PPC970 ed un FPS: sono circa il 10%. Teniamo conto, poi, che in un'architettura OOO con pipeline lunga le latenze sono elevate e una misprediction fa' perdere moltissimi cicli di clock.

Innazitutto in quell'articolo sono confrontati 3 FPS, di questi due arrivano quasi all'8% di misprediction e uno circa al 4%.

Poi bisogna vedere, appunto, la lunghezza della pipeline e quanti stadi sono necessari prima di invalidare la pipeline a causa di un branch miss, perché si tratta di cose diverse.

Per il primo punto, dipende dall'architettura: PPC970 è soltanto un'architettura dotata di pipeline (intera, chiaramente: in questi discorsi generalmente si esclude la pipeline delle istruzioni floating point), ma ce ne sono tante altre che sono dotate di pipeline più corte. Questo soltanto per puntualizzare: tu hai parlato di PPC970, che ha 16 stadi di pipeline e possimo prendere pure questo come punto di riferimento, non c'è problema.

Il secondo punto è molto importante, perché indica l'efficienza dell'implementazione, A PRESCINDERE DALLA LUNGHEZZA DELLA PIPELINE.
Ad esempio, posso avere un processore con una pipeline di 30 stadi, ma se il controllo dei branch miss viene effettuato al quarto stadio, la penalizzazione sarà soltanto di 4 cicli di clock per riempire nuovamente la pipeline.

In un'architettura a pipeline molto corta come quella del Cell, una misprediction crea un danno molto ma molto minore,

Non è esatto. La PPE ha ben 21 stadi di pipeline: 5 in più del PPC970, e le SPE hanno una lunghezza paragonabile.

anche pensando che le unità di esecuzione sono molte e se una stalla le altre mandano comunque avanti i thread.

Ci sono solamente due thread che si possono mandare avanti.
Inoltre le unità di esecuzione della PPE sono decisamente poche e molto specializzate, per cui per utilizzarle al meglio e non andare in problemi di stallo dovuti all'attesa che si liberi l'unità interessata, sarebbe meglio avere due thread che svolgano lavori piuttosto diversi (es: uno si occupa di calcoli interi, l'altro di quelli FP o VMX, o altri pattern simili).

Qui http://www-306.ibm.com/chips/techlib...cle-021405.pdf stimano una perdita di 8 cicli per la PPU e 18 per una SPE:

Appunto perché la PPE, pur avendo 21 stadi, ha il controllo della validità dei salti che termina all'ottavo stadio di pipeline, per cui è meno penalizzato rispetto ad altre architetture che lo protraggono fino agli ultimi stadi.
Per la SPE ciò non è stato necessario, perché il tipo di codice da eseguire è molto meno soggetto da eseguire (il codice eseguito dagli stream processor è piuttosto lineare).

Per quanto riguarda il PPC970, ad esempio, sono necessari 12 cicli di clock (http://www-1.ibm.com/servers/eserver...power4_3.html).

Ho visto che, dalla prima stesura del tuo messaggio, hai rimosso il fatto che il PPC970 abbia 100 cicli di clock di penalizzazione.

Edit: inoltre vorrei far notare che, stando a quando dice Jon "Hannibal" Stokes di ArsTechnica, anche Xenon (il triple-core di Xbox360) come Cell richiede un'ottimizzazione statica per ILP e TLP: From ILP to TLP, from the processor to the programmer e soprattutto, stando a quanto dicono quelli di ArsTechnica, utilizzerà un'architettura in-order proprio come quella di Cell: http://arstechnica.com/articles/paed...box360-2.ars/3

Diciamo che Xenon ha 3 PPE, MOLTO simili a quella presente in Cell (con la differenza di integrare in ognuna qualcosa di simile all'SPE).

Io non so se ha preso un granchio anche Hannibal, di sicuro se avesse ragione i sostenitori di Xbox360 dovrebbero trovare un'altra motivazione per celebrare la superiorità della console Microsoft non valendo più il OOO vs IOO...

Per applicazioni general purpose, sicuramente vale lo stesso discorso fatto per il Cell.

Il vantaggio di Xenon è che, avendo 3 core in grado di eseguire ognuno due thread diversi, per applicazioni multi-threaded (non di tipo SIMD / stream) presenterà prestazioni superiori al Cell.

Nel testo viene spiegato come vengono generati i workloads

No: vengono elecante le applicazioni usate. Non c'è un riferimento che permetta di riprodurre esattamente i test effettuati.

e comunque le prestazioni sono allineate su quasi tutti i test tranne uno (MS-Office2000), dove è PentiumIII-650 a prevalere sul Crusoe-533 e non il contrario come dici tu, visto che il workload viene eseguito in un tempo inferiore (=prestazione migliore).

Su questo hai ragione. Generalmente nei benchmark in cui i numeri più bassi indicano prestazioni maggiori c'è sempre un'indicazione: qui mancava del tutto.

D'altra parte fek contestava il fatto che il Crusoe-667 potesse avere prestazioni simili al PentiumIII-500, mentre nella fattispecie il confronto viene fatto con un Crusoe a frequenza più bassa rispetto a quella del PentiumIII.

Non è esatto: è vero che il P3 è a 650Mhz, ma viene fatto girare a 500Mhz. E' scritto chiaramente su ogni immagine dei test effettuati.

Non solo: il Crusoe utilizza memorie PC133 e il P3 invece PC100.

Un'altra cosa strana è che entrambi i computer vengono fatti girare con le impostazioni al massimo risparmio energetico: mi sembra un po' una forzatura. Se volevano testare la bontà del processore per quanto riguarda le prestazioni, perché non testare il sistema al massimo delle capacità (e minimo consumo, chiaramente)? Insomma, sento puzza di bruciato...

Il punto, comunque, non era se fosse più veloce il Crusoe o il PentiumIII quanto se fosse una traduzione obiettiva o no
"Transmeta has claimed that the performance of a 667-MHz Crusoe TM5400 is about the same as a 500-MHz Pentium III"
=
"parlano genericamente di un processore Transmeta a 666 Mhz che viaggia piu' piano di un Pentium3 a 500 Mhz, come volevasi dimostrare"

Mi spiace, ma sono d'accordo con fek. Le sue parole mi sembrano molto chiare e lo stesso vale per la "traduzione".

Tra l'altro, proprio il fatto che nel benchmark di Office il Crusoe (a 667Mhz) presenta prestazioni inferiori al P3 (a 500Mhz), e non il contrario come pensavo io, dimostra che il Crusoe è performante about/quasi (e quindi per me inferiore, nell'accezione comunque di questo termine in entrambe le lingue) come un P3.

Se poi teniamo in considerazioni i dubbi di cui sopra che ho espresso su questi "benchmark" (e considera che, per il tipo di lavoro fatto da Crusoe, la banda verso la memoria è particolarmente importante per riempire velocemente la sua cache di blocchi di codice tradotto), direi che il quadro generale si commenta da sé.

[cdimauro]

Originariamente inviato da lowenz

Io voglio il parere di repne scasb

IMHO è sufficiente leggere tutta la discussione...

Poi è chiaro che il contributo di repne scasb è ben accetto, data la sua esperienza.

[cdimauro]

Originariamente inviato da jappilas

O_o sperando di abbagliarmi, ho l' impressione che il thread stia proseguendo su incomprensioni reciproche e la tensione stia salendo

questo imho dovrebbe restare un reference thread su una comparativa architetturale... non litigate, vi scongiuro

Quoto. Visto che è un thread molto interessante, preferirei che si mantenesse sul piano esclusivamente tecnico.

Gradirei inoltre, che nel caso in cui si effettuassero delle contestazioni su frasi dette, si riportassero sempre (per intero, se necessario): così evitiamo parte dei problemi di "miscomprensione" che si possono generare (e relativi accesi diverbi).

[fek]

Originariamente inviato da MadRat

Fek, discutere con te e' molto difficile, tendi a prevaricare non ascoltando, travisando le argomentazioni e puntando su tematiche tecniche spesso non chiamate in causa, questo solo per spiazzare un eventuale interlocutore piu' inesperto nell'ambito al quale vuoi sempre ricondurre i tuoi discorsi.
L'impressione che si ha, tuttavia, e' che tu voglia affermare tramite spiegazioni, che la terra giri al contrario.

Purtroppo non tutte le "battaglie" si possono combattere in casa, altrimenti ti direi "giochiamoci la soluzione alle nostre controversie su due ruote" o "vediamo chi disegna meglio una vignetta al riguardo" o ancora a chi la musica meglio..

E' una vostra opinione che non trova riscontro con gli altri utenti e dico anche a te che sei hai rimostranze da fare sul mio atteggiamento sul forum puoi parlarmene in privato.
Facendolo in pubblico dimostri solamente di esserti scottato per una discussione e voler cercare rivalsa sul piano personale.

Se fornisci informazioni palesemente sbagliate come come l'RSX con pipeline unificate, il Cell che non e' uno stream processor, l'RSX che non e' derivato dal G70 e' giusto che qualcuno corregga civilmente le tue affermazioni come e' giusto che le mie vengano corrette quando sono sbagliate.

Non capisco perche' a seguito di tuoi errori che sono stati corretto tu la debba voler buttare sul personale. Non e' un modo civile di affrontare discussioni su un forum tecnico come questo.

Forse ti manca una bella dose di umilta' e la capacita' di ascoltare cio' che la gente ha da dire.

Tutti gli altri mi dicono al contrario che non faccio mai pesare la mia preparazione e sono sempre pronto ad ascoltare cio' che mi viene detto. La verita' e' che non si puo' essere simpatici a tutti e purtroppo qualcuno per orgoglio reagisce male a normali correzioni su un forum che io personalmente accetto sempre con grande piacere.

Ed ho abbastanza umilta' e capacita' di ascoltare per capire che le questioni personali si risolvono in privato e non in pubblico. Le tue critiche pubbliche su una persona che non conosci lasciano il tempo che trovano.
E risolverle in privato non vuol dire minacciarmi di guerre sui forum come all'asilo

[fek]

Originariamente inviato da cdimauro

Quoto. Visto che è un thread molto interessante, preferirei che si mantenesse sul piano esclusivamente tecnico.

Gradirei inoltre, che nel caso in cui si effettuassero delle contestazioni su frasi dette, si riportassero sempre (per intero, se necessario): così evitiamo parte dei problemi di "miscomprensione" che si possono generare (e relativi accesi diverbi).

Sarebbe molto bello, ma purtroppo in questo caso non e' una incomprensione, ma c'e' qualcosa sotto di piu' profondo. Nulla che l'ignore list non curi

[fantoibed]

Originariamente inviato da cdimauro

Ad esempio, posso avere un processore con una pipeline di 30 stadi, ma se il controllo dei branch miss viene effettuato al quarto stadio, la penalizzazione sarà soltanto di 4 cicli di clock per riempire nuovamente la pipeline.

Ok, ma allora ti chiedo (perché non lo so, non per provocare! E' meglio precisarlo visti i tempi...): spostando indietro il controllo sul branch si ha il vantaggio della minor penalizzazione ma si avranno anche degli svantaggi suppongo. Quali sono?

E poi, se c'è stato un branch misprediction, le istruzioni caricate nella cache non saranno più quelle giuste (quelle che secondo il branch predictor si sarebbero dovute eseguire) e quindi la cache va scaricata e ricaricata di nuovo, quindi in totale i cicli persi saranno molto più di 4.

Originariamente inviato da cdimauro

Non è esatto. La PPE ha ben 21 stadi di pipeline: 5 in più del PPC970, e le SPE hanno una lunghezza paragonabile.

Io ho sempre sentito parlare di pipeline molto corta degli SPE..

Originariamente inviato da cdimauro

Ho visto che, dalla prima stesura del tuo messaggio, hai rimosso il fatto che il PPC970 abbia 100 cicli di clock di penalizzazione.

Infatti, l'avevo letto in un documento che non riesco più a trovare. Dicevano che per caricare la cache normalmente servono circa 20 cicli di preavviso, nel senso che da quando parte l'ordine sul "cosa" caricare a quando te lo trovi in cache passano 20 cicli. Nel caso di un errore della predizione devi svuotare la cache delle istruzioni caricate erroneamente, individuare quelle giuste da caricare e poi caricarle e che in totale servono circa 100 cicli di clock. Siccome non trovo il documento, trovo troppo pessimistiche queste informazioni e soprattutto stavo editando il messaggio per aggiungere il link all'architettura dello Xenon ho eliminato anche quell'informazione per evitare che qualcuno ci trolleggiasse sopra...
D'altra parte potrei andare a prendere un bel po' di thread in cui alcune persone sostengono la superiorità di Xbox360 rispetto alla PS3 in virtù del esecuzione OOO della prima, ma non lo faccio...

Originariamente inviato da cdimauro

Mi spiace, ma sono d'accordo con fek. Le sue parole mi sembrano molto chiare e lo stesso vale per la "traduzione".

Vabbè, allora d'ora in poi dirò che le prestazioni delle Minardi rispetto a quelle delle McLaren sono "about the same" perché fek ha dimostrato fuori da ogni dubbio e vocabolario alla mano che "about the same" significa "più lento di".

[^TiGeRShArK^]

Originariamente inviato da DioBrando

scusate l'OT...cmq è un peccato che non partecipi +

sicuramente ci sn altre teste con quel livello di preparazione tecnica cmq una in + male n faceva...

Fine OT


continuo a seguire con interesse il thread e complimenti a tutti cmq per le nozioni sviscerate

l'altra volta era tornata in programmazione...
ma ora in effetti è da un pò ke nn si fa vedere....

[leoneazzurro]

Originariamente inviato da fantoibed

Ok, ma allora ti chiedo (perché non lo so, non per provocare! E' meglio precisarlo visti i tempi...): spostando indietro il controllo sul branch si ha il vantaggio della minor penalizzazione ma si avranno anche degli svantaggi suppongo. Quali sono?

E poi, se c'è stato un branch misprediction, le istruzioni caricate nella cache non saranno più quelle giuste (quelle che secondo il branch predictor si sarebbero dovute eseguire) e quindi la cache va scaricata e ricaricata di nuovo, quindi in totale i cicli persi saranno molto più di 4.

La pipeline, non la cache in generale . Potresti avere le istruzioni giuste in cache anche se devi svuotare la pipe per intero.
Per quanto riguarda il branch predictor, il discorso è molto complesso, in quanto dipende enormamente da come è implementato, dal grado di affidabilità, ecc.

[^TiGeRShArK^]

Originariamente inviato da MadRat

Esattamente, un processore "castrato", non vale quanto un processore che possa lavorare al suo massimo. Ma a quanto pare il tuo parere "tecnico" vale piu' di quello del resto del mondo.

si vede ke anke lui, come me, ha programmato qualcosina in assembly 68000 e capisce le differenze tra un processore a 32 bit e uno a 16 bit....
se la sua architettura interna è a 32 bit IMHO non c'entra assolutamente niente il fatto ke il bus sia dimezzato. Questo implica solo delle penalità prestazionali (un pò come il 386 sx ke rispetto al dx aveva il bus dimezzato, ma nn mi pare ke nessuno abbia mai definito un 386 sx come un processore a 16 bit.....).

Ok, spiegami perche' da un'evoluzione teorica di un 68060, non si potrebbe arrivare a processori piu' potenti degli attuali. Al tempo uno 060 lasciava ben poco spazio ad un pentium, eppure il pentuim era venduto un milione di volte piu' del motorola.
Credo che il commercio c'entri poco con la qualita', basti vedere lo standard vhs.. contro i portentosi video2000.

l'ha già spiegato.Per la difficoltà implementativa delle istruzioni CISC utilizzate nell'assembly 68000, ke erano fantastiche x scrivere direttamente in assembly, ma MOLTO pesanti.

E molto prima dicesti: "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.

Poi l'elogio alla semplicita' dell'architettura x86 continuava.. Mah..

non mi pare ke cdimauro abbia mai detto ke l'assembly x86 è pià facile da programmare dell'equivalente 68000...anzi mi sembra il contrario.
Casomai diceva ke uqnato affermato da te ke gli x86 sono un'accrokkio nato da 8 bit e 640 kb (o qualcosa del genere) non corrispondeva affatto a verità.

Insomma, io sotengo che a parita' di hardware, un pc sia drasticamente meno performante, tu sostieni che questo non sia vero, ma all'atto pratico halo su pc richiede un HW 2 volte piu' potente. Gia', dimenticavo, tu riconduci tutto a problemi di porting anche su piattaforme similisime. I credo piu' che altro che il pc sia ridicolo dal punto di vista prestazionale e l'xbox sia la palese dimostrazione di quello che si potrebbe fare abbandonando le strutture che tu dici non esistere piu' o quantomeno non essere limitative.

questo è palesemente falso.I gioki su xbox giravano a 640X480.
L'unico vantaggio ke si ha x le console è ke si conosce esattamente l'hardware su cui far girare il gioco e qdi è possibile ottimizzare SOLO ed ESCLUSIVAMENTE x quella piattaforma. Sui pc invece sono necessari differenti path x mantenere la compatibilità con le skede di fascia bassa (ke tra l'altro sono la maggior parte tra tutte quelle in circolazione) e in questo modo ovviamente il lavoro dei programmatori è maggiore in quanto devono lavorare su pià fronti.
Qdi qdo dici ke se si abbandonassero le infrastrutture attuali si otterrebbero prestazioni migliori non è assolutamente vero. O meglio, potrebbe anche accadere, ma non ha alcun collegamento col discorso ke hai fatto con l'xbox....anke tenendo conto del fatto ke in realtà l'xbox è un pc e anke piuttosto scarso. Le prestazioni "relativamente" migilori dell'xbox sono dovute a qto appena spiegato.

[cdimauro]

Originariamente inviato da MadRat

Esattamente, un processore "castrato", non vale quanto un processore che possa lavorare al suo massimo. Ma a quanto pare il tuo parere "tecnico" vale piu' di quello del resto del mondo.

Il parere di una rivista lascia il tempo che trova, visto che i redattori normalmente non sono studiosi o professionisti competenti in materia.
Preferisco un criterio oggettivo di uno studioso di architetture degli elaboratori.

Quanto a 68000 e 68008, l'unica cosa che gli puoi contestare è che abbiano i soli bus esterni "castrati", non che lo sia la loro architettura.
Se Motorola avesse prodotto un 68000 con bus dati esterno a 32 bit, avresti detto che è un processore a 32 bit? Eppure avrebbe condiviso la STESSA ARCHITETTURA degli altri due.

Non hai ancora risposto alla mia domanda: per te un 68008 è un processore a 8 bit? E quindi al pari di Rockwell 6510, Zilog Z80, Intel 8085, Intel 8088 (a questo punto) e addirittura del suo "progenitore", il Motorola 6800?

I tuoi ricordi sono offuscati, non girerebbe fluido come un st nemmeno su un A4000.

Vedremo.

Quasi quasi me lo ricarico su un amiga vero e non emulato.

Provalo.

Dipende tutto dal sito dal quale prendi i link.. Se noti quello dell'amiga e' farcito di commenti e spiegazioni, quello ST e' solo un elenco tecnico poco completo per altro.

Non c'è problema. Qui http://atari-ste.anvil-soft.com/html/devdocu6.htm trovi un confronto fra i vari modelli si Atari ST/TT/Falcon.

Ad esempio TI SEI SCORDATO di dire che l'st usci' con le porte midi, non solo per conquistare il mercato musicale (come fece), ma anche per surrogare il chip audio poco costoso implementato nella macchina e molti giochi, se collegati ad un economicissimo roland mt32, uscivano in audio con questo (dopo che il gioco stesso lo aveva programmato)

Quanti giochi hanno sfruttato questa possibilità? Non numeri "che ricordi tu", ma un elenco

e ti assicuro che il cio' ridicolizzava il fantomatico audio dell'amiga,

Non credo proprio, visto che i canali Amiga riproducevano sample, e non soltanto delle note.

soprattutto dal punto di vista musicale ed in oltre risparmiava memoria preziosa.

Certamente, ma l'esperienza sonora era parecchio limitata con la MIDI, a causa della mancanza dei sample. Infatti il sonoro nei giochi con l'Amiga è stato qualitativamente elevato rispetto alle altre piattaforme.

La soluzione non e' logicamente stata usata quanto le caratteristiche avanzate dell'amiga (vista la ovviamente scarsa diffusione dell'MT32 se paragonato ad un chip di serie),

Appunto, e vorrei vedere i numeri.

ma ne hanno ridotto il costo facendo sì che l'ST fosse il computer piu' vendto del mondo (fino al guinnes dei primati del 97, poi oltre non l'ho piu' comprato).

Il guiness ce l'ha ancora oggi il Commodore 64.

Tant'e' vero che la commodore e' fallita assai prima dell'Atari. (94).

Questo non c'entra nulla col resto del discorso. Gli ST sono sempre stati inferiori all'Amiga nel campo multimediale, e in quello dei giochi in particolare: questo è un dato di fatto.
Vogliamo vedere quanti giochi sono stati sviluppati per Amiga e ST? Dici che hai una notevole collezione di retrogaming: prova a contarli.
Dopo averli contati facciamo un confronto sulla qualità video e audio dei titoli disponibili su entrambe le piattaforme, così ci facciamo quattro risate...

Secondo poi la schiacciante superiorita' architetturale del'Amiga, generava un gap prestazionale notevole in ogni gioco che facesse uso di grafica poligonale. Questo lo motiviamo con 0.84 mhz in meno??
Se prendi una punto e la vesti da rolce royce, hai la comodita' di quest'ultima e le prestazioni di una bicicletta.

Anche nel campo del poligonale l'Amiga si è sempre distinta. Anzi, ha introdotto il genere, se vogliamo essere pignoli. E non soffriva di particolari gap prestazionali: anche se il Blitter era stato pensato per la grafica bitmap / bitplane, è stato sfruttato molto bene anche per la generazione di linee (poteva generare quasi un milione di pixel al secondo per questo compito) e per il riempimento dei poligoni (aveva una logica hardware di fill mentre copiava porzioni di memoria).

Basti vedere i titoli 3D disponibili: Stunt Car Racer era estremamente fluido (ancora oggi merita di essere giocato), così come Elite, Falcon F16, FA/18 Interceptor, ecc. Vogliamo confrontare gli stessi titoli disponibili per ST?

Il progetto Amiga ne 94 rischio il crash vista l'esosita' dello stesso.

Era l'84.

Richedeva troppe risorse finanziarie e di tempo.

Specifica: per quella piccola società che l'aveva fatto partire.

Fu comprato incompleto dalla Comodore (avrebbe dovuto comprarlo l'atari che era gia' in trattative e possedeva parte del team di sviluppo, situazione dalla quale scaturi' una controversia legale tra le due case).

Vinta dalla Commodore. E il progetto non era incompleto, ma in uno stadio avanzato: i chip custom erano stati completati.

Sta di fatto che la Comodore si trovo' in mano un computer incompleto e complesso, privo anche di un amiga dos finito e di un qualunque altro sistema operativo degno di questo nome,

Le cose non stanno così. Ecco qui uno dei tanti link che si trovano in rete e che riportano la storia dell'Amiga: http://www.betatesting.it/backforthe...ianoframe.html

Poi l'AmigaDOS NON E' IL SISTEMA OPERATIVO DELL'AMIGA, ma soltanto la parte che si occupa dell'interfaccia con i filesystem.

il workbench infatti non era su rom e non era certamente degno della concorrenza. (la complessita' dell'hardware portò vantaggi e svantaggi). Assolutamente non paragonabile con il TOS della digital,

Infatti: il TOS si è rivelato sempre inferiore ad AmigaOS.

forse scopiazzato da quello che vendette anche apple,

Mi fai vedere dove l'avrebbe scopiazzato? Il s.o. ha poco a che spartire, e la GUI è completamente diversa visivamente, nelle API e nei concetti di programmazione.

ma decisamente il migliore all'epoca (so bene come non fosse multitasking, ma sarebbe stato prematuro per le conoscienze del tempo).

Il TOS era peggio perfino del MacOS, che almeno aveva un'interfaccia grafica decisamente più user friendly.

Quanto al multitasking, è la solita storia della volpe e l'uva: se non ce l'hai non è bello ed era prematuro. Intanto chi usava l'Amiga si divertiva a usarlo e a lanciare applicazioni a josa...

Io sul mio ST usavo tranquillamente 512 colori contemporaneamente e sull'STE ne usavo 4096.

Tanto tranquillamente no: per ogni riga video da visualizzare era necessario generare un interrupt ogni 16 pixel (per l'ST. Ogni 256 pixel per l'STE), per cambiare la palette dei colori. Un compito estremamente oneroso per la CPU: vai a vedere quanti cicli di clock sono necessari a un 68000 a seguito di un'interrupt e quanti ce ne vogliono per ritornare al task precedente; per non parlare poi del salvataggio e ripristino dei registri usati nello stack, e del lavoro vero e proprio di caricamento dei colori nella palette). Tu non hai la minima idea di quello che significa, visto che non hai mai programmato un 68000 in vita tua...

In ogni caso i due computer primeggiavano nei loro rispettivi campi

Gli ST solo nel MIDI.

ed a parer mio il vantaggio dell'amiga non giustificava un costo DOPPIO rispetto a quello dell'ST.

Doppio? Se lo confronti col primo Amiga, forse, il 1000. Il 500 era di poco più costoso di un ST.

La grafica evoluta cosi' come l'audio, richiedevano grandi quantitativi di ram, al tempo molto costosa. Anche questo io giudico nell'equilibrio di un progetto.

Sarà per questo che gli ST hanno sempre avuto dotazioni di memoria superiori agli Amiga...

Non nego che L'Amiga fosse una grande idea, ma conservava dei punti deboli e per di piu' finì nelle mani gestionali piu' errate. La commodore senza Tramiel non valeva piu' nulla.

E infatti s'è visto come s'è mangiato le mani per essersi fatto sfuggire l'Amiga.

Non lo so, forse all'epoca ancora non sapevi leggere?? o piu' probabilmente eri chiuso nel mondo amiga.

Leggevo di tutto. Usavo di tutto. E ho una buona memoria. Tant'è che trovo puntualmente riscontro a ciò che dico.

Forse non sai ancora leggere ora che ci penso;

Ti consiglio di risparmiare questi insulti. Piuttosto argomenta ciò che hai da dire.

io ho detto che esisteva **"ANCHE"** una versione con le ROM sulla porta d'espansione. Questo era utile per accendere il computer e senza caricare nulla, avere un MAC piu' potente dell'originale e "con tutta la ram libera".. Difficile da intuire vero??

L'unico vantaggio, ma costoso: meglio investire quei soldi per comprare della ram, che si poteva usare con tutte le applicazioni.

Indubbiamente dal punto di vista grafico (solo se si parla di bitmap) l'amiga era piu' prestante,

Anche per grafica non bitmap.

ma a me risulta che l'impiego di overscreen e piu' colori di quanti imposti dal SO, fosse una realta' anche su ST (certamente meno diffusa e piu' limitata).

Con l'Amiga potevi sfruttare overscan, HalfBrite (64 colori) e HAM (4096 colori) anche da s.o.: non era una prerogativa dei giochi e dell'applicazioni che accedevano direttamente all'hardware.
Quanto all'ST, per avere più colori visualizzati contemporaneamente dovevi per forza di cose ricorre alla tecnica di cui sopra, che consumava PARECCHIA potenza di calcolo.
Sull'overscan non saprei: hai delle informazioni tecniche a riguardo che dimostrano che era possibile farlo anche con l'ST?

Per quanto riguarda l'STE, era un'ottima macchina poco sfruttata. La parte audio era il doppio piu' potente di quella dell'amiga (4 ch a 50khz o 8 a 25khz).

Non mi risulta: http://atari-ste.anvil-soft.com/html/devdocu4.htm Qui trovi tutte le informazioni su come funziona il DMA audio degli STE e su COME PROGRAMMARLO. Come puoi vedere, è in grado di riprodurre soltanto due canali stereo, e a frequenze fisse.

Al contrario, Amiga ha 4 canali completamente indipendenti, su cui è possibile controllare singolarmente volumi ed effetti vari, e che permettevano di riprodurre frequenze arbitrarie fino a 28Khz. Il limite dei 28Khz si poteva superare programmando i canali direttamente con la CPU: Aegis AudioMaster è stato il primo programma a presentare e utilizzare questa tecnica per riprodurre suoni a 56Khz.

Quindi, come vedi, l'audio dell'Amiga è rimasto superiore anche con l'arrivo degli STE.

Se poi il tuo concetto di superiorita' e' dettato solo da un audio ed una grafica piu' evoluti, senza badare alla funzionalita', ai costi ed alle altre prestazioni..

Un Amiga 500 non costava molto, e aveva un hardware favoloso (per quei tempi). Il poco di più che si pagava rispetto all'ST permetteva di avere hardware e s.o. di livello notevolmente superiore: ampiamente giustificato IMHO, e non sono il solo visto l'enorme successo che ha avuto.

beh, allora parliamo di x68000.. L'Amiga scompare d'incanto.

Per forza: era stato progettato appositamente per realizzare dei giochi, con hardware dedicato molto simile a quello che si trovava in sala giochi.

Fortunatamente un computer non e' fatto solo d'apparenza e di giochi.

Infatti anche per tutto il resto l'Amiga è stato eccellente: l'unico campo in cui non ha sfondato è stato il settore audio professionale a causa della mancanza dell'interfaccia MIDI di serie.

Un programma di annotazione midi su pc, mac o amiga quando va in crash e torna al desk smette di suonare, con l'st non succedeva. Questo fa la differenza per un professionista. Qualunque spiegazione tu abbia.

Non mettere le mani avanti: tu non hai dato NESSUNA SPIEGAZIONE, e pretendi di tapparmi la bocca col nulla? Sei troppo presuntuoso.

I programmi che giravano in background su ST installavano un hook che veniva eseguito a intervalli regolari indipendetemente dal task corrente: in questo modo il suono poteva essere riprodotto mentre si faceva altro. La STESSA tecnica è stata usata con i player per il PC / DOS.

Tutto ciò era INUTILE con l'Amiga, perché era multitasking: bastava lanciare un player e dedicarsi ad altro.

Alla fine quando si parla con te, finisce tutto per essere ricondotto ad una mala programmazine. Mentre secondo me, se una determinata tipologia di programmi girava "sempre" meglio, si puo' parlare di comprovata superiorita' hardware (almeno nel segmanto).

I "secondo me" non dico niente e non valgono nulla: a me interessano i fatti. E per i fatti serve poter mettere le mani sui sorgenti o disassemblare gli eseguibili.

In mancanza di fatti, preferisco non espormi, come invece ami fare tu.

A parte la poca pertinenza con l'argomento, le idee confuse le hai tu.
Il TT era l'evoluzione a 32bit (anche se per te e' inoncepibile questo argomento), dell'ST, venduto come postazione professionale!!.

Mi ricorda un certo Amiga 3000: l'evoluzione "professionale" dell'Amiga 2000 con tanto di 68030.

Il falcon usci molto tempo dopo come macchina completamente nuova che, dall'ST avrebbe dovuto ereditare solo la fascia di mercato, il case ed una discreta retrocompatibilita'. L'unico difetto fu la data di lancio, come detto prima, il progetto era pronto nel 90/91 e fu lanciato a meta' 93.

Non era una macchina completamente nuova. Ecco qua: http://atari-ste.anvil-soft.com/html/devdocu6.htm puoi trovare un bel po' di informazioni, anche su come programmarlo (nelle 5 pagine precedenti). Te ne riporto uno stralcio:

"The Falcon030 and its features:

? How compatible is the Falcon to the STE ? Will my STE code work flawlessly on the Falcon ?

! Yes, the Falcon was meant to be an (68000-based) successor to the 1040 STE, therefore it is easy to code Falcon-compatible STE-code. The only exceptions are:

- The Falcon does not allow 6.125 KHz DMA sound

- The Falcon's screen base address has to be a multiple of 4

- The Falcon does not have the so-called "Shadow"registers of the YM2149

To also make sure that the timing of the CPU is (almost) correct, switch the processor caches off and the CPU and the Blitter down to 8 MHz. Now, the only obstacle is the DMA-sound matrix of the Falcon which might be setup wrongly."

Inoltre qui: ftp://ftp.lip6.fr/pub/atari/Docs/hardware.txt trovi l'elenco completo delle zone di memoria usate dai vari Atari, dall'ST al Falcon, e dei registri dei vari chip. Come vedi il Falcon è MOLTO simile ai suoi predecessori, nonché abbastanza compatibile.

Non era una questione di inferiorita' architetturale quella che causo la dismissione evolutiva dei 68k, bensi' il diffondersi di un'altra piattaforma.

Chi ha mai parlato di "inferiorità architetturale" (qualunque cosa tu voglia dire con ciò)? Motorola ha ammazzato i 680x0 in favore dei PowerPC. Più esattamente, ha mantenuto i 680x0 nell'ambito dei microcontroller ad alte prestazioni.

La motorola provo' anche a creare uan versione RISC del 68000, chiamata inizialmente 78000 e poi 88000, ma a nulla servi', passo quasi inosservata.

L'unica cosa che avevano in comune 68000 e 88000 era il produttore: Motorola.

E chi ha parlato di problemi?? Io non di certo!!
Era solo la motivazione per la quale i pc, grazie alla loro modularita' ed espandibilita', (che e' il loro unico punto di forza) e grazie a taiwan, sopraffecero i computer che "puzzavano" di stantio (incredibile, siamo d'accordo su qualcosa).
Ma se non fosse stato per il mercato orientale, il pc sarebbe rimasto per sempre relegato al ruolo di macchina da ufficio, vistone il costo assurdo per l'uso domestico ed i vantaggi inesitenti.

I vantaggi c'erano, altrimenti non si sarebbe affermata come piattaforma. Hai mai programmato un PC? Sai come funziona una SuperVGA? Sei in grado di confrontare un PC con SVGA con un Amiga o un ST dal punto di vista dell'hardware?

Ma no, certo, come posso non averci pensato prima!! La motorola avrebbe dovuto sprecare milioni di dollari per lo sviluppo di una cpu che oramai non era piu' usata da nessuno!!

Infatti non l'ha buttata nel cesso: l'ha riciclata per fare altro.

Comuqnue alla fine il ppc eredita parte delle caratteristiche del 68k,

Non vedo quali, visto che sono nettamente diversi. Inoltre i PowerPC derivano dalla famiglia Power di IBM, non dai 680x0 di Motorola.

ma paragonato ad un 68060, (di pari epoca) e inferiore. Alla fine sono solo scelte commerciali dettate non solo dalla motorola, ma anche dai suoi partner.

Certamente. A ciò aggiungi anche la lungimiranza di Motorola nel ritenere l'architettura 680x0 poco scalabile per il futuro.

Gli ST non furono considerati solo negli ultimi anni, quando l'Amiga riusci a raggiungere un prezzo decente.

Cioè nell'87, con l'introduzione dell'Amiga 500: sono passati soltanto due anni dalla commercializzazione dell'ST prima e dell'Amiga 1000 dopo.

E questo riguarda solo ed ESCLUSIVAMENTE il mercato vudeoludico, del quale parli tu,

No, l'Amiga s'è affermato e, anzi, ha inventato tanti altri settori (il termine multimedia è nato con Amiga).

mercato che ha fatto affermare i pc come standard, ma che tuttavia non e' l'unico target di un utente (né di ora, né del tempo).

E chi l'ha mai negato?

Comuqnue sono d'accordissimo con chiunque sostenga che dal punto di vista ludico, l'amiga fosse piu' idoneo. Questo perche' aveva grandi capacita' di manipolazione delle bitmap, che al tempo erano il fulcro dei giochi. Mentre l'evoluzione del mercato ha poi decretato la vittoria della grafica poligonale.

Questo è avvenuto coi PC, non con altre piattaforme.

Non ho mai affrontato quest'argomento.

Li hai mischiati.

Ok, spiegami perche' da un'evoluzione teorica di un 68060, non si potrebbe arrivare a processori piu' potenti degli attuali. Al tempo uno 060 lasciava ben poco spazio ad un pentium, eppure il pentuim era venduto un milione di volte piu' del motorola.
Credo che il commercio c'entri poco con la qualita', basti vedere lo standard vhs.. contro i portentosi video2000.

Infatti non c'entra la "qualità", ma ti ho già detto che è una questione puramente tecnica. Un 68020+ ha un'ISA molto versatile ma complesso da implementare rispetto a un 80386+, perché è dotato di istruzioni che eseguono parecchio lavoro e modalità d'indirizzamento estremamente avanzate.
Tutto ciò comporta il fatto che già la sola sezione di decodifica delle istruzioni sarebbe estremamente complessa, e richiederebbe parecchi milioni di transistor per poter garantire un throughput (erogazione) di microistruzioni paragonabili a quelli di x86.
Considera che un Athlon ha 4 decoder che sono in grado di decodificare ognuno fino a 4 istruzioni per ciclo di clock, ed è in grado di erogare fino a 3 microistruzioni per ciclo di clock. Soltanto che l'istruzione più complicata che può avere un Athlon è quella che presenta un indirizzo di memoria simile a questo: [Base + Indice * Fattore di scala + Offset a 32 bit], e questo per la sola sorgente o la sola destinazione.
Un 68020+ permette qualcosa come ([Base + Offset a 32 bit] + Indice * Fattore di scala + Offset a 32 bit). E questo per sorgente e destinazione nel caso di una MOVE.
Quindi puoi immaginare l'enorme lavoro che dovrebbe fare il decoder per tirare fuori le microistruzioni da spedire all'unita di esecuzione RISC-like.

E molto prima dicesti: "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.

Poi l'elogio alla semplicita' dell'architettura x86 continuava.. Mah..

Non cercare di rigirare le carte: i discorsi erano DIVERSI. Ciò che hai riportato è relativo all'IMPLEMENTAZIONE dell'architettura, mentre il mio commento sulla semplicità riguarda la sua PROGRAMMAZIONE.
Mi sembra di essere stato piuttosto chiaro su questo punto.

Ne ho parlato pocanzi

Di cosa?

Insomma, io sotengo che a parita' di hardware, un pc sia drasticamente meno performante, tu sostieni che questo non sia vero, ma all'atto pratico halo su pc richiede un HW 2 volte piu' potente.
Gia', dimenticavo, tu riconduci tutto a problemi di porting anche su piattaforme similisime.

Infatti è così, e le piattaforme non sono così simili, visto che non esiste una scheda video che funzioni come l'X-Box.

I credo piu' che altro che il pc sia ridicolo dal punto di vista prestazionale e l'xbox sia la palese dimostrazione di quello che si potrebbe fare abbandonando le strutture che tu dici non esistere piu' o quantomeno non essere limitative.

Non puoi confrontare capra e cavoli: Halo per X-Box e PC è un PRODOTTO DIVERSO CHE FUNZIONA IN MODO DIVERSO E RICHIEDE HARDWARE DIVERSO. Punto.

Per quanto mi riguarda, l'oggettivita degli eventi va ben oltre a qualunque "teoria".

Oggettività che è tutta da dimostrare, visto che manca un elemento fondamentale: il fatto che le due applicazioni NON SIANO IDENTICHE.

In mancanza di una valutazione che sia DIMOSTRATA oggettiva, sono le tue che rimangono soltanto teorie.

La mia negazione era assoluta non meno di quanto lo fosse la tua relativamente ai dsp cell.

E' inutile che provi a cambiare discorso: non attacca.

Quanto alla mia valutazione su Cell, cosa vorresti mettermi in bocca questa volta?

Che simpatico, tuttavia AMD lavorando sull'efficienza, piu' che sulla potenza bruta dei mhz, vendeva un 2,2ghz come oppositore di un 3,2 (scarto di un ghz ancora presente, rispetto ai processori Intel) e questa differenza si e' accumilata per lo piu' durante il 2003. Solo con l'avvento dei K8 si e' spinta oltre i 2,2 ghz.. frequenza che raggiunse molto tempo prima.

Athlon e P4 sono processori diversi con un'implementazione completamente diversa dell'architettura x86: non puoi confrontare i 2,2Ghz del primo coi 3,2Ghz del secondo. E' un confronto assolutamente privo di senso.

Tra il dire ed il fare..

Bastano le specifiche e la buona volontà di qualcuno. Come è sempre stato fatto nel campo degli emulatori, tra l'altro.

Mi dai un link con un emulatore Jaguar degno di questo nome??
Per ora io uso quello vero.

www.mess.org.

Infatti non parlo di problemi emulativi.. ma del pc stesso, al difuori di ogni emulazione. Sono problemi che tutt'ora affliggono questi sistemi ed (nel campo musicale si riflettono in particolar modo), rendono praticamente inutilizzabile un pc privo di una costosa scheda che lavori per conto proprio.
Se questa me la chiami evoluzione..

I problemi di cui non fai altro che parlare non li hai mai esplicitati: a cosa ti riferisci di preciso? E cerca di essere chiaro: dev'essere possibile riprodurlo su un PC nelle condizioni che elencherai (spero).

Purtroppo quasi tutte le chiavi di protezione dell'atari, come anche quella del cubase Audio, erano inserite nella porta laterale per cartucce d'espansione. (come lo spectre gcr).. Dunque mi sembra un po' difficile inserirla in un pc. Il problema purtoppo non si pone, vista l'inesitenza dell'emulatore.
Non sai che darei per averlo, ma purtroppo nemmeno quello dell'ST e' ancora perfetto.

Allora amen. Per emulare anche quella porta d'espansione sarebbe necessario sviluppare un dispositivo a cui collegare queste chiavi: non ha senso farlo, perché non ci sarebbe mercato.