Confronto fra i486 e Motorola 68000

[^TiGeRShArK^]

Originariamente inviato da MadRat

Questo dimostra solo che il cel sia un ottimo stream processor.. Non vedo dichiarazioni cosi' palesi.
Io non ho mai detto che non sia un potente stream processor.

credo si riferisse al fatto ke dicevi ke il cell non è uno stream processor....

[^TiGeRShArK^]

x quanto riguarda il crusoe e il code-morphing:

The Crusoe chips that were announced yesterday translate x86 instructions into 128-bit Very Long Instruction Word (VLIW) instructions that can be run directly on the Crusoe chip. This translation is handled by software called "Code Morphing" software. Transmeta estimates that the Code Morphing software is 3/4 of the logic behind the Crusoe, with the other 1/4 being the hardware chip itself.

The Crusoe chips can go without any register renamers, reorder buffers, and stack arithmetic units since the Code Morphing software takes care of all of this stuff. Without this excess baggage, the chips themselves can be smaller, feature less transistors, and run cooler than traditional mobile chips such as the Intel mobile Pentium II and Pentium III. As you would guess, the Crusoe processors are aimed specifically at mobile applications. One flavor is aimed at Internet appliances, and the other is aimed at mini-notebooks.

So, that's all well and good, but what is the meaning of "software?" I mean, we all know what software is: code that runs on a processor. What Transmeta didn't make a big point of is that the Crusoe chips require a bootable ROM chip on the motherboard. This ROM chip holds the Code Morphing software. When you turn on your laptop or other device with a Crusoe chip in it, the ROM chip loads up the Code Morphing software into memory and Crusoe runs it before doing anything else. Then, whenever a call is made to the processor, the software intercepts it and translates it into code that runs natively on the Crusoe. The native Crusoe instructions are stored in a 16MB cache that the x86 OS is forbidden from accessing. So, if the proper ROM chip is in place for running x86 instructions, you can install Linux, Windows, BeOS, or whatever OS you want on a Crusoe-based system.

Il "software" x il code morphing è dunque contenuto nella ROM.
Non mi risulta ke nel CELL sia stato utilizzato un qualsiasi sistema anke lontanamente paragonabile a quello utilizzato nel Crusoe x la traduzione al volo del codice x86 in codice VLIW.

[Athlon]

Messa in rilievo perche' a mio parere si tratta di una bella discussione di quelle che non si vedono molto di frequente ai giorni nostri.


P.S. per un attimo mi e' sembrato di essere tornato negli anni 90

[fantoibed]

Originariamente inviato da ^TiGeRShArK^

Il "software" x il code morphing è dunque contenuto nella ROM.
Non mi risulta ke nel CELL sia stato utilizzato un qualsiasi sistema anke lontanamente paragonabile a quello utilizzato nel Crusoe x la traduzione al volo del codice x86 in codice VLIW.

E' più probabile che venga implementato un sistema analogo ma con con traduzione di codice PowerPC-to-PowerPC come avviene nei processori sperimentali della IBM "BOA" e "DAISY" sviluppati dallo stesso team che sta sviluppando Cell. Da http://www.research.ibm.com/people/m.../2002_wced.pdf

[...]While BOA uses special-purpose hardware support in the form of the checkpointing and rollback facilities for the architecting of precise exceptions, the DAISY uses in-order software-managed commit operations. This allows to take exceptions without rolling back the processor state to the previous checkpoint by determining the corresponding original program point for any optimized trace fragment.
To ensure correct correspondence of the program state between the optimized code fragments and the original program, DAISY has to compute the entire state and commit it in original program order. Because DAISY was targeted at wide high-performance VLIW architectures [27], this did not result in performance degradation. Later work extends this approach to allow for the elimination of dead state during the optimization of trace fragments [28, 29], and thus allows to perform more aggressive optimization of trace fragments on architectures with more limited issue bandwidth, such as for PowerPC-to-PowerPC dynamic optimization.
The present approach is different from the DIF approach of Nair and Hopkins [30], and trace processors [31]. By choosing to implement the trace formation and scheduling in software, BOA can generate perform more extensive profiling to determine which trace paths are frequently executed, assemble longer traces, perform more aggressive optimizations and generate better schedules. Also, the underlying hardware only has to support a single execution mode whereas DIF and trace processors require almost three machines: a frontend processor used when executing normal code which has not been collected and preprocessed, a system for preparing, cracking and pre-scheduling the traces to be stored in the trace cache, and the execution engine optimized for executing code from the trace cache.
Our trace-based dynamic optimization is related to the idea of optimizing for the most likely execution path described by Fisher [32]. Trace scheduling requires to estimate the likelihood of a given path being executed and thus requires information about the runtime behavior of programs. Modern compilation systems attempt to address this issue by collecting execution profiles to be used by the compiler. Alas, this profile-directed feedback approach does not allow to optimize the program for different execution profiles according to specific workloads, or for phased program behavior. Unlike the static compilation techniques assumed in this work, dynamic optimization profits from the ability to collect and process profile information at runtime and to react to execution profile changes.

Ho citato il Transmeta perché è sicuramente più conosciuto come processore VLIW rispetto al DAISY. D'altra parte mi vien difficile pensare che S/T/I sviluppino una CPU simile al DAISY come concezione di fondo e decidano di non utilizzare un software di ottimizzazione dinamica già scritto per il DAISY...

[MadRat]

Originariamente inviato da ^TiGeRShArK^

credo si riferisse al fatto ke dicevi ke il cell non è uno stream processor....

Ma chi lo ha mai detto.. ho detto che nessuno lo ha mai dichiarato tale. Potrebbe rivelarsi molto piu' flessibile di quanto non sembri in prim'analisi.

[cdimauro]

Intel Itanium ed Efficeon Transmeta sono gli esempi più noti di architetture "in order", e testimoniano il fatto che spostare il problema del miglioramento delle prestazioni dall'hardware (transistor per implementare unità out-of-order, predizione dei salti, ecc.) al software (compilatori) non paga, anche mettendo a disposizione parecchie altre risorse (Efficeon, in particolare, esegue bundle di ben 8 istruzioni ed è dotato di parecchie unità di esecuzione).

La motivazione principale l'ha portata fek: soltanto nel momento stesso dell'esecuzione è possibile conoscere le condizioni in cui si trova il processore, e scegliere in che modo è possibile sfruttare al meglio le risorse disponibili.

In particolare, per cercare di risolvere questo problema, il CodeMorph di Transmeta era in grado di ricompilare i blocchi di codice (già compilati) nel caso in cui il profiling della precedente esecuzione mettesse in evidenza la possibilità di ottenere qualche guadagno prestazionale rilevante.

Nonostante tutto, nonostante Efficeon avesse anche delle caratteristiche appositamente pensate per facilitare la traduzione del codice, il profiling e per intercettare e gestire il più velocemente possibile le eccezioni sollevate dall'ISA emulato, le prestazioni sono sempre rimaste piuttosto scarse (e la cache del processore fa un lavoro decisamente migliore rispetto al DMA di Cell, per questo particolare tipo di compito).
I benchmark postati sono molto vecchi, bisogna vedere effettivamente come viene generato il workload, e mi sembra alquanto strano che in tre test i risultati dei due processori siano ESATTAMENTE identici, in due differiscono di pochissimo, e soltanto uno è molto diverso (a favore di Transmeta, ovviamente): numeri così non si vedono neppure fra processori x86 con caratteristiche simili...

Se ciò non basta a dimostrare che quest'approccio non è una buona soluzione, certamente non gli fa una buona pubblicità e scoraggia chi avesse intenzione di riabbracciarla.

Quanto a Cell, le prestazioni nell'ambito del calcolo general purpose e dell'emulazione in particolare non possono che essere ben peggiori (almeno Efficeon possiede dell'hardware dedicato che ne facilita il compito).

Innanzitutto c'è da dire che, non solo sono unità in ordine, ma le SPE sono sostanzialmente delle unità SIMD con l'aggiunta di qualche caratteristica all'ISA per renderle "indipendenti", per cui sanno fare (molto) bene ciò per cui sono state progettate: calcolo massicciamente parallelo (di tipo streaming).
Basta prendere un problema "classico" (ordinamento, hash table, ricerca in un albero binario, cammino minimo di un grafo, ecc. ecc.) per capire che, a parte la notevole difficoltà implementativa (immaginate di implementare le stesse cose con le MMX/SSE o Altivec), le prestazioni sarebbero veramente troppo scarse.
Immagino già una SPE che prova a emulare il 6510 a 1Mhz del Commodore 64: chissà che fatica, anche se lei gira a 3,2Ghz...

L'unica per cui ha senso e che rimane in grado di eseguire calcoli general purpose è quindi l'unità PPE, anch'essa in-order, ma che proprio per questo motivo risulta abbastanza scarsa (anche se enormemente meglio delle SPE), per tutto ciò che già è stato detto. A ciò aggiungiamo anche il fatto che è dotata di poche unità di esecuzione (condivise da entrambi i thread) molto specializzate, e il quadro diventa decisamente desolante...

Certo, rispetto a un Efficeon Cell ha la possibilità di utilizzare il DMA per caricare velocemente dei blocchi di dati nella memoria locale, e accedervi poi molto velocemente, ma è un vantaggio apparente: il codice general purpose non è sequenziale (quindi richiederebbe frequenti "cambi di blocco"), e peggio ancora è l'accesso ai dati (non locale -> continui caricamenti di blocchi di dati -> il DMA che perde parecchio del suo tempo e della sua efficienza a recuperare i pochi dati che realmente servono in un preciso momento).

Visto che si parlava di emulazione, basterebbe dare un'occhiata al codice di un emulatore, anche dotato di un compilatore Just in Time, per rendersi conto che proprio questo tipo di problema è fra quelli che in assoluto mettono in ginocchio già un processore particolarmente orientato al calcolo general purpose: un'architettura in-order è quanto di peggio si possa desiderare, per quanta buona volontà ci si possa mettere nell'implementazione.

Anzi, possiamo anche prendere un qualunque emulatore, prelevare a caso il sorgente di alcune istruzioni dell'ISA emulata, e analizzare il codice: si vedrà molto facilmente che esistono delle dipendenze assolutamente ineliminabili già per un processore ooo, e che per un'architettura in order sarebbero fatali (dovrebbe forzatamente aspettare il completamento dell'istruzione che crea la dipendeza prima di proseguire).

I miracoli non esistono: se tutte le CPU general purpose continuano, DA ANNI, a integrare logica out-of-order, branch prediction, register rename, ecc., non lo fanno certo per sport o perché gli ingegneri conoscono soltanto certe tecnologie, ma perché è evidente che in questo campo sono quelle che garantiscono le migliori prestazioni.

D'altra parte Intel con Itanium c'ha provato: tolta la cache L3 da questo, anche un Duron con 192KB di cache L2 (Itanium ne ha 256KB) è in grado di competergli (e ad avere prestazioni mediamente migliori) nel calcolo general purpose, a parità di clock.

Adesso veniamo al link riportato da cui è possibile prelevare un PDF del 18 luglio 2000 con le informazioni su DAISY (Dynamic Binary Translation and Optimization) di IBM, e di cui ho riportato degli stralci:

The DAISY architecture defines execution primitives similar to the PowerPC architecture in both semantics and scope. However, not all PowerPC operations have an equivalent DAISY primitive. Complex PowerPC operations (such as "Load Multiple Registers") are intended to be layered, i.e., implemented as a sequence of simpler DAISY primitives to enable an aggressive high-frequency implementation. To this end, instruction semantics and data formats in the DAISY architecture are similar to the PowerPC architecture to eliminate data representation issues which could necessitate potentially expensive data format conversion operations.

The DAISY architecture provides extra machine registers to support efficient code scheduling and aggressive speculation using register renaming.
Data are stored in one of 64 integer registers, 64 floating point registers, and 16 condition code registers. This represents a twofold increase over the architected resources available in the PowerPC architecture. The architecture supports renaming of the carry and overflow bits in conjunction with the general purpose register. Thus, each register has extra bits to contain carry and overflow. This rename capability enables changes to global state (such as the carry and cumulative overflow information) to be renamed in conjunction with the speculative destination register until the point where the state change would occur in the original in-order PowerPC program.

The DAISY VLIW also has the usual support for speculative execution in the form of non-excepting instructions which propagate and defer exception information with renamed registers [6][17][13][14][18]. Each register of the VLIW has an additional exception tag bit, indicating that the register contains the result of an operation that caused an error.

The DAISY VLIW supports a memory hierarchy which is very similar to the emulated PowerPC architecture. This choice reduces the cost of implementing operations accessing the memory. Our experience indicates that if memory operations have to be implemented using a sequence of operations to emulate the memory management structure of the base architecture, severe performance degradation can result. If multiple platforms are to be supported by a common core, then this core must provide an efficient way of emulating the memory management structure of all supported base architectures appropriately. In particular, it is important to ensure that frequently executed memory operations do not incur emulation burden, whereas updates to the memory map (such as changes to the page tables, segment registers, etc.) might require additional logic to update the DAISY VLIW core's native memory management system.

The DAISY VLIW processor contains hardware support for profiling in the form of an 8K entry 8-way set associative (hardware) array of cached counters indexed by the exit point id of a tree region. These counters are automatically incremented upon exit from a tree region and can be inspected to see which tips are consuming the most time. They oer the additional advantages of not disrupting the data cache and being reasonably accurate.

However, some older architectures, e.g., Intel x86 require automatic synchronization between data and instruction caches. Efficient implementation of such architecture requires some hardware support. To solve this, we add a new read-only bit to each "unit" of base architecture physical memory, which is not accessible to the base architecture. (The unit size is > 2 bytes for S/390 and > 1 byte for x86, but it could also be chosen at a coarser granularity, e.g., a cache line.) Whenever the VMM translates any code in a memory unit, it sets its read only bit. Whenever a store occurs to a memory unit that is marked as read-only (by this or another processor, or I/O) an interrupt occurs to the VMM, which invalidates the translation group(s) containing the unit.

E la tabella delle cache utilizzate:

   Cache     | Size / Entries | Line Size | Assoc | Latency
   L1-I      |       32K      |      1K   |   8   |     1
   L2-I      |        1M      |      2K   |   8   |     3
   L1-D      |       32K      |     256   |   4   |     2
   L2-D      |      512K      |     256   |   8   |     4
    L3       |       32M      |    2048   |   8   |    42
  Memory     |                |           |       |   150
  DTLB1      |   128  entries |           |   2   |     2
  DTLB2      |   1K  entries  |           |   8   |     4
  DTLB3      |   8K  entries  |           |   8   |    10
  Page Table |                |           |       |    90

E' interessante analizzare bene tutte le parti che ho evidenziato.

In definitiva non si tratta di un semplice sistema in-order, ma di un'architettura VLIW appositamente studiata e realizzata (via software per le simulazioni) per emulare un'architettura, quella dei PowerPC, con cui CONDIVIDE PARECCHIE CARATTERISTICHE.
E' un lavoro che riesce a fare molto bene proprio per questo motivo (leggere meglio sopra. Meglio ancora il documento), e inoltre grazie a una dotazione delle varie cache non proprio alla portata di tutti (stiamo parlando del 2000, non di oggi: all'epoca esistevano soltanto i Power4 e Pentium 3 a 0,18u come riferimento) e con una massiccia dotazione di altre caratteristiche.
Da notare i 1024 byte di linea di cache istruzioni L1 e 2048 di cache istruzioni L2: un valore ENORME, necessario per "sfamare" il core. A ciò aggiungiamo anche latenze di accesso eccezionali: UN solo ciclo per la L1 istruzioni e addirittura soltanto TRE cicli per la cache istruzioni L2.
Anche gli altri dati si commentano da soli.

Beh, se devo spostare transistor da una parte all'altra, per lo meno mi aspetterei un CONSISTENTE risparmio nel farlo, non addirittura un IMPROPONIBILE AUMENTO...

Sarà per questo che, a cinque anni da quella pubblicazione, IBM continua a produrre i suoi processori Power come ha sempre fatto, e come ha continuato a fare col core dell'X-Box360 (che è di derivazione Power).

Il core di Cell non fa testo, perché le SPE non sono assimilabili a processori VLIW, e inoltre il PPE è semplicemente una versione castrata dell'architettura Power, messo lì per fare da microcontroller per le SPE. Checché se ne dica, AGLI EFFETTI Cell è uno Stream Processor: le definizioni lasciano il tempo che trovano, contano i fatti (un Cell senza SPE e con la sola PPE non vale assolutamente niente: viene surclassato in tutti i campi dalle architetture esistenti).

P.S. LongRun2 è una tecnologia sviluppata da Transmeta per il controllo (hardware e software) di frequenza, voltaggio e correnti di leakage del processore, e che quindi non aiuta il compito dell'emulazione (per questo è l'architettura stessa che presenta delle interessanti caratteristiche).

[cdimauro]

Originariamente inviato da MadRat

Decisamente ora non ho tutto il tempo necessario a risponderti passo passo.

OK, aspetterò le tue risposte agli altri punti che hai lasciato in sospeso. In mancanza, assumerò che non hai avuto argomenti per smentirli.

Tuttavia voglio precisare che hai travisato molte cose..

Non è un po' presto per tirare delle conclusioni? Vedremo chi dei due ha "travisato"...

In primo luogo, l'idea che i computer basati su 68000 fossero considerato dei 16 bit (e da alcuni 16/32) e' cosi' mia e personale che il nome ST vuol dire proprio 16/32, (come TT significa 32/32) e le riviste del tempo che li trattavano, portavano come sottotitolo riferimenti al mondo informatico a 16bit..

Ti risparmio decine e decine di siti nei quali si parli di 68000, ST, Amiga, Mac e storia dei computer e processori, nei quali si parla di generazione di computer a 16bit. Poi se ci tieni proprio ti do un po' di link, ma puoi anche cercare da solo su google.

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?

L'emulatore dell'ST su amiga, era un simulatore di desktop limitato nelle funzioni ed incapace anche di far scorrere un mouse con fluidita'.

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.

L'hardware dell'amiga era piu' massiccio, non piu' complesso. Molto meno armonioso e bilanciato di quello ST..
Del resto sono nati dalle stesse mani e sono solo due interpretazioni differenti di comuter simili.

Hai un ricordo molto confuso e poco attinente alla realtà. Ecco qua: http://it.wikipedia.org/wiki/Amiga e qua: http://it.wikipedia.org/wiki/Atari_ST

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:

Processore principale:
Motorola MC68000
Bus Interno a 32 Bit
Bus dati a 16 Bit
Frequenza di clock 7.16 MHz

Chip custom
Agnus
Denise
Paula

Memoria
RAM 256 Kilobyte, espandibile internamente a 512 KB ed esternamente fino ad 8 MB
ROM 8 Kilobyte, il Kickstart non risiede nella ROM ma viene caricato al momento dell'accensione nella RAM

Sistema operativo
AmigaOS 1.0

GUI
Interfaccia utente a finestre denominata "Intuition"

Disk drive
1 floppy disk drive capace di leggere dischi da 3,5" a doppia densità (880kb)

Mouse
1 Mouse a due tasti

Input/Output
1 porta video RGB analogico
1 modulatore video RF per connessione alla televisione
1 porta video NTSC composito
2 porte controller (per mouse, joystick, paddle, penna ottica ecc.)
1 porta esterna floppy disk
1 porta RS232
1 porta parallela "Centronics"
1 connettore di espansione laterale di tipo Zorro I dotato di tecnologia AutoConfig
1 connettore di espansione RAM
1 connettore tastiera

Per quanto riguarda i chip custom:

Denise: era il chip responsabile di generare il segnale video (15KHz). I dati gli erano forniti da Agnus via DMA. Conteneva una palette di 32 colori da 4096, eccezionale per l'epoca. Disponeva di una modalità a bassa risoluzione (320x256) ed una ad alta risoluzione (640x256). Gestiva nativamente l'interlacciamento per arrivare fino a 320x512 o 640x512. Le temporizzazioni video erano parzialmente programmabili e si poteva dunque ottenere risoluzioni prive di bordi (overscan). Denise poteva segnalare sul connettore video se stava visualizzando il colore di background o meno. Questo permetteva di realizzare dei genlock in chroma key economici. Interlacciamento, overscan e genlock resero Amiga la macchina di riferimento per le produzioni video a basso costo.

Agnus: era il responsabile dei 25 canali DMA a disposizione della macchina e del refresh della DRAM (detta Chip ram). Agnus conteneva:
Copper: era un processore dotato di 3 istruzioni (MOVE, WAIT, SKIP). Permetteva di cambiare i registri hardware in sincronia con il pennello video, liberando la CPU da questo onere. Questa tecnica permetteva ad esempio di cambiare modalità video nel mezzo dello schermo, visualizzare più colori e più sprites. AmigaOS traeva vantaggio del Copper per implementare il concetto di "Schermo". Il Copper non era una novità, Jay Miner aveva già realizzato qualcosa di molto simile sugli Atari a 8 bit con le display list di ANTIC. Per capire le capacità del Copper e la flessibilità dell'hardware si consideri che in un gioco (Battle Squadron) gli sprite invece di essere 'alimentati' dal DMA, come d'uso, venivano alimentati dal Copper arrivando a creare dei nuovi sprites a 2 colori e più di 8 sprites per linea.
Blitter: anche questa fu una rivoluzione, prima di Amiga solo alcune costose workstation grafiche disponevano di Blitters. Era un coprocessore che implementava alcune primitive grafiche in hardware. Elaborando un bitplane alla volta poteva combinare tre zone rettangolari (A, B e C) copiandole in una quarta zona rettangolare (D). I cosidetti BLOB (BLitter OBject)) erano oggetti grafici mobili realizzati avendo come A e D il frame buffer, come B l'immagine del BLOB e come C la maschera del BLOB. Il Blitter implementava un'altra primitiva grafica: il disegno di una linea, durante il disegno di essa poteva effettuare anche un fill.

Paula: controllava le porte (seriale, parallela, ecc...) ed il floppy drive ma sopratutto l'audio. Forniva 4 DAC PCM 8bit, 2 sul canale destro, 2 sul sinistro. Ogni canale aveva un volume a 6bit ed un controllo di periodo. Un canale poteva modulare l'altro in periodo o volume (da cui 8+6 = 14bit). I campioni audio potevano essere forniti via DMA o via CPU. Con il DMA la frequenza di campionamento, relata alle temporizzazoni video, era programmabile fino a circa 29Khz. Era possibile applicare un filtro passa basso sull'uscita audio. I 4 canali audio vennero col tempo ritenuti insufficienti e si svilupparono mixer software (trackers) capaci di spingere Paula ai suoi limiti. Alcuni mixer software erano abbastanza efficienti da essere utilizzati nei videogames. Dunque una hardware audio di tutto rispetto, tuttavia la mancanza di una economica porta MIDI integrata fece preferire gli Atari ST ai musicisti.

Ed ecco quelle dell'ST:

Le seguenti specifiche si riferiscono all'originario 520 ST:
CPU: Motorola 68000 @ 8Mhz
RAM: 512 KByte
Suono: Yamaha YM2149
Drive: floppy disk drive 3½" a singola faccia
Porte: TV out (nei modelli FM), MIDI In/Out, RS-232, Stampante, Monitor (RGB e monocromatico, porta per Disk drive aggiuntivo, porte Joystick e Mouse
Sistema operativo: TOS (Tramiel Operating System) dotato di interfaccia grafica GEM (Graphical Environment Manager)
Modalità video: 320×200 (16 colori), 640×200 (4 colori), 640×400 (monocromatico), palette di 512 colori

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

A differenza dell'Amiga, l'Atari ST non disponeva di chip custom progettati per l'accelerazione delle funzioni grafiche tipicamente usate nei videogiochi, programmi di grafica e montaggio video, né disponeva di chip audio avanzati (la qualità audio di un Atari ST era grossomodo equivalente a quella di un Commodore 64). Tuttavia, la sua maggiore economicità, la frequenza del processore leggermente più elevata rispetto a quella dell'Amiga e la presenza di porte MIDI incorporate, lo resero un computer di successo nell'ambito musicale professionale e amatoriale.

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

Quanto alle mani che li hanno creati, non sono certo le stesse, come vorresti far credere: basta leggere i link che ho riportato. E qui: http://en.wikipedia.org/wiki/Jay_Miner la storia del progettista dell'Amiga.

Come vedi, l'unica cosa che ha sviluppato per l'Atari è il chip video per la console Atari 2600...

Che l'emulatore mac su st girasse a quella velocita' e' risaputo da chi ha usato quelle macchine,

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

addirittura fecero pure un'interfaccia esterna contenente le rom del mac e vendettero (vendemmo, visto che eravamo centro atari ed l'assistenza ufficiale assieme alla sede di milano e torino) molti atari a tutti coloro i quali fossero indecisi tra uno (mac) e l'altro, inquanto la compatibilita' era totale, la velocita' superiore e la risoluzione video anche. Questo e' indice di spueriorita'. Nel caso dell'amiga io parlerei di diversita'.

Anche per l'Amiga valeva lo stesso, e tra l'altro non era necessario avere un'interfaccia esterna per la rom.
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).

Seguiti a parlarmi di velocita' di trasmissione della midi.. Il 68000 dell'st programmava solamente l'hardware dedicato alla gestione dma dell'interfaccia midi.. Hai le idee un po' confuse al riguardo, e' ovvio che una simile velocita' di trasmissione sia gestibile con poche risorse.

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.

Forse non si tratta solo di quello . E NESSUN programma midi per quelle macchine soffriva di scarsa precisione o rallentamenti, non credo proprio che fossero tutti in assembler!!

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

Non li ho fatti io né ho i sorgenti a disposizione per poter controllare. Comunque, come ti dicevo prima, l'assembly era un linguaggio molto usato per scrivere applicazioni, grazie alla semplicità dell'architettura 68000.
Quasi tutti i programmi che ho scritto io per Amiga, anche dotati di GUI e con programmazione a oggetti, erano in assembly.

Poi mi dici che un falcon senza l'hardware dedicato non saprebbe fare nulla.. IL FALCON SENZA HW DEDICATO NON ESISTE. E' nato superiore/migliore, come se nascesse oggi un computer nuovo, sarebbe superiore/migliore anche (e soprattutto) concettualmente a qualunue architettura gia' inventata.

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

Altri modelli
TT 030 - nuove macchine basate sul processore Motorola 68030 con frequenza di 32 Mhz, in un nuovo case con tastiera separata.
Atari Falcon 030 - un'altra macchina basata sul 68030, come il TT, ma in un case estremamente simile a quello della serie 1040, con degli ulteriori miglioramenti al comparto grafico e sonoro, un processore Motorola 56000 dedicato al DSP (elaborazione digitale dei segnali), un sistema operativo multitasking (su disco) ed una porta LocalTalk per le connessioni di rete.

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

Seguiti a sostenere che io ritenga i pc odierni simili ad un 386.. non e' vero, so che hanno poco e nulla a che spartire con loro. Ritengo solamente che siano partiti dalla piu' sbagliata delle basi informatiche.

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.

Se non capisci perche' abbia parlato di schede video, te lo rispiego in una riga.
Perche' hanno portato i giochi a 256 colori al grande pubblico, diventando cosi' commerciali e soppiantanto amiga ed st. (grazie a taiwan e non certo alla superiorita' del mondo pc-comp).

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

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

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

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

Oggi un 68000 farebbe ridere come architettura quanto un 2/386..

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...

Un evoluzione di questo (68000) sarebbe notevole e porterebbe con se i propri "difetti, nella stessa misura rilevata con gli x86.

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.

Come capisci bene e ci tieni a precisare, che i processori di oggi poco c'entrino con un 386,

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

8 bit e 640KB -> 8086. Io, invece, ti ho messo di fronte un PC CON UN 386. Quindi è logico che lo ritenga (decisamente) superiore a quello che tu hai citato (un 8086).

dovresti intuire che la stessa qualita' evolutiva avrebbe coinvolto qualunque altra cpu al posto delle x86, ma come giustamente dici tu, sono solo dei se.

Idem come sopra: non mettermi in bocca parole che non ho mai detto...

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.

Ti ho fatto anche l'esempio di cosa vorrebbe dire implementare l'ISA di un 68020+ con le stesse tecnologie, e delle notevoli difficoltà per farlo.

Metto un'ultima piccola aggiunta riguardo ad Halo..
Questo non dimostra cio' che sostieni tu, dimostra soltanto che (come sostengo da sempre) un hw dedicato e non soggetto a cambiamenti sia piu' "spremibile" ed a parita' di HW una console rispetto ad un pc e' piu' efficiente. Da qui i problemi a far girare Halo decentemente su pc di faccia bassa.. molto bassa direi.

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.

Per non parlare di doom3!!. Politica per altro anticonsumistica, perche' credo che comuqnue piu' o meno TUTTI i giochi principali per pc, potrebbero girare meglio se affinati nella programmazine.
Poco tempo fa lessi un commento di non ricordo chi, che analizzava il codice di unreal (e o di far cry), mostrando la quantita' di righe inuliti e pesanti presenti.

Ne abbiamo già AMPIAMENTE parlato nella sezione News e anche in questa: non è affatto come dici tu.
Evidentemente le politiche che portano alla realizzazione di un gioco sono a te assolutamente estranee (e da quelle che dici non sembri aver mai programmato in vita tua, tanto meno dei giochi).
Fatti una ricerca, e se hai voglia di continuare a parlarne, riapri i thread oggetto della discussione.

Comunque se non erro prima sostenevi che il 68000 manderebbe al manicomio chiunque ed ora sostieni che sia piu' semplice di un x86. Forse mi e' sfuggito qualcosa.
Non puoi dire prima una cosa 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. (questa frase l'ho gia' sentita..)

Idem come prima: non puoi mettermi in bocca cose che non ho assolutamente detto. Prima di dare giudizi affrettati dovresti quanto meno leggere e cercare di capire meglio quel che scrivono gli altri, altrimenti rischi di prendere delle clamorose cantonate...
Ti risparmio la fatica e ti riporto quel che ho detto, spiegandoti anche il significato.

(relativamente al decoder delle istruzioni) "Ho detto che quello per un 68020+ sarebbe MOLTO più complicato da realizzare, e ti ho spiegato anche il perché."

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

La prima frase è relativa all'IMPLEMENTAZIONE DELL'ARCHITETTURA. In parole molto povere: di come gli ingegneri devono mettere assieme i transistor per realizzare e far funzionare un processore.

La seconda frase riguarda la PROGRAMMAZIONE DELL'ARCHITETTURA. In parole molto povere: di come i programmatori devono mettere assieme le istruzioni che rende disponibili per far funzionare i programmi.

L'unica cosa che lega le due frasi è la parola ARCHITETTURA.

Dici che il dsp 56001 sia in grado di eseguire instruzioni gp.. non piu' di un qualunque altro dsp (cell docet).

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

Per quanto riguarda la corsa alle frequenze di AMD, vorrei farti notare come sia rimasta intorno ai 2ghz per quasi due anni.

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

P.S.
Fallo tu un emulatore del Falcon se pensi sia possibile.

Non è che lo penso: E' possibile.

Per ora non ci riesce nessuno

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

ed in ogni caso avrebbe gli stessi rallentamenti del vst in fase di forti carichi ide.

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.

Comuqnue non sarebbe una soluzione per me, perche' il cubase audio non e' mai stato sprotetto bene, le versioni pirata crashano che e' una bellezza ed il mio ha la chiave di protezione hardware!!

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...

[fantoibed]

Originariamente inviato da cdimauro

[...] soltanto nel momento stesso dell'esecuzione è possibile conoscere le condizioni in cui si trova il processore, e scegliere in che modo è possibile sfruttare al meglio le risorse disponibili. [...]

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...

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.

In un'architettura a pipeline molto corta come quella del Cell, una misprediction crea un danno molto ma molto minore, anche pensando che le unità di esecuzione sono molte e se una stalla le altre mandano comunque avanti i thread.

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:

A mispredicted branch in the Power core has an eight-cycle penalty, and a load has a fourcycle data-cache access time.When one thread is stalled, possibly by a mispredicted branch or a cache miss, the second thread often can execute to fill the execution stall. This leads to greater architectural efficiency and higher utilization of processor resources.

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
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...

Originariamente inviato da cdimauro

I benchmark postati sono molto vecchi, bisogna vedere effettivamente come viene generato il workload, e mi sembra alquanto strano che in tre test i risultati dei due processori siano ESATTAMENTE identici, in due differiscono di pochissimo, e soltanto uno è molto diverso (a favore di Transmeta, ovviamente): numeri così non si vedono neppure fra processori x86 con caratteristiche simili...

Nel testo viene spiegato come vengono generati i workloads 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). 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.

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"

[fek]

Originariamente inviato da fantoibed

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"

Ma adesso non avendo i mezzi e le capacita' di obiettare il discorso generale ti inventi anche cose che non ho scritto.

Mi quoti di preciso dove attorno alla sequente frase "parlano genericamente di un processore Transmeta a 666 Mhz che viaggia piu' piano di un Pentium3 a 500 Mhz, come volevasi dimostrare" ho scritto che e' una traduzione letterale e accurata del testo inglese? Grazie.

Poi mi quoti dove ho "contestato che potesse avere prestazioni simili"?

Visto che fai il precisino invece, ti faccio notare che:
""Transmeta has claimed that the performance of a 667-MHz Crusoe TM5400 is about the same as a 500-MHz Pentium III"

Sono "circa le stesse", non "le stesse" e neppure "poco superiori", quindi anche se di poco inferiori, quindi il mio "piu' piano di" e' un'interpretazione perfettamente accurata e obbiettiva delle informazioni che abbiamo a disposizione.

Infatti ho scritto:
"parlano genericamente di un processore Transmeta a 666 Mhz che viaggia piu' piano di un Pentium3 a 500 Mhz, come volevasi dimostrare"

Il "genericamente" non e' casuale, ma tu lo hai volutamente ignorato. Come volevasi dimostrare.

Riguardo al discorso sullo Stream Processor, cidimauro ha posto gia' la parola fine per me. Il Cell e' uno Stream Processor come affermato anche da IBM. Mentre tu hai confuso una memoria locale con un processore, che sono due concetti un po' diversi.

[fantoibed]

Originariamente inviato da fek

Ma adesso non avendo i mezzi e le capacita' di obiettare il discorso generale ti inventi anche cose che non ho scritto.

Ho fatto copia e incolla, vedi tu.

Originariamente inviato da fek

Mi quoti di preciso dove attorno alla sequente frase "parlano genericamente di un processore Transmeta a 666 Mhz che viaggia piu' piano di un Pentium3 a 500 Mhz, come volevasi dimostrare" ho scritto che e' una traduzione letterale e accurata del testo inglese? Grazie.

Hai detto che era una traduzione libera e che rende l'idea.
E' chiaro che hai preso quella frase (che è del tutto marginale nel discorso) e l'hai modificata a tuo uso e consumo solo per cercare di rendere inattendibile quella fonte.

Originariamente inviato da fek

Poi mi quoti dove ho "contestato che potesse avere prestazioni simili"?

Lo smile indicava quello, è evidente!

Originariamente inviato da fek

Visto che fai il precisino invece, ti faccio notare che:"Transmeta has claimed that the performance of a 667-MHz Crusoe TM5400 is about the same as a 500-MHz Pentium III"

Sono "circa le stesse", non "le stesse" e neppure "poco superiori", quindi anche se di poco inferiori, quindi il mio "piu' piano di" e' un'interpretazione perfettamente accurata e obbiettiva delle informazioni che abbiamo a disposizione.

Quindi era un caso il fatto che tu abbia scelto "piu' piano di" invece che "piu' veloce di" per la tua "interpretazione perfettamente accurata e obbiettiva delle informazioni che abbiamo a disposizione" ?

E poi, che cos'altro intendevi con "come volevasi dimostrare" se non tentare di screditare le fonti?

Originariamente inviato da fek

Infatti ho scritto:
"parlano genericamente di un processore Transmeta a 666 Mhz che viaggia piu' piano di un Pentium3 a 500 Mhz, come volevasi dimostrare"

Il "genericamente" non e' casuale, ma tu lo hai volutamente ignorato. Come volevasi dimostrare.

L'ho ignorato perché lo consideravo corretto. Non è il "genericamente" ad essere errato, è tutto il resto della frase.

Originariamente inviato da fek

Mentre tu hai confuso una memoria locale con un processore, che sono due concetti un po' diversi.

Non è vero e lo sai. E' un'altra chiara ed evidente mistificazione e chi segue il thread se ne può rendere conto facilmente.
Come volevasi dimostrare [cit.]

Riporto quel pezzo:

Originariamente inviato da fantoibed

Questo lo traduci con "Cell è uno stream processor"? ...Oppure si sta parlando della Local Storage degli stream processors contenuti in The Cell?

Dove avrei confuso una memoria locale con un processore lo sai solo tu.

E' evidente che stai solo cercando di screditare chi la pensa diversamente da te attribuendogli frasi mai dette. Ti cito: Ma adesso non avendo i mezzi e le capacita' di obiettare il discorso generale ti inventi anche cose che non ho scritto.. E con tale frase, vinci anche una segnalazione ai moderatori.

Tieni presente che io non ho mai contestato il fatto che Cell sia uno "stream processor", contesto solo il fatto che nella frase che hai riportato si riferiscono ad una singola SPU quando dicono "stream processor" e non all'intero Cell!

[fek]

Originariamente inviato da fantoibed

Ho fatto copia e incolla, vedi tu.

Hai detto che era una traduzione libera e che rende l'idea.
E' chiaro che hai preso quella frase (che è del tutto marginale nel discorso) e l'hai modificata a tuo uso e consumo solo per cercare di rendere inattendibile quella fonte.

Questa e' una tua illazione e come tale non ha valore, ed e' oltretutto offensiva.

Ho detto che e' una traduzione libera, dopo che tu mi hai domandato se fosse una traduzione esatta. Con me non cambi le carte in tavola.

Lo smile indicava quello, è evidente!

E' evidente solo per te. Mi quoti dove avrei scritto quello che mi hai attribuito?

Mi metti in bocca cose che non ho scritto solo per screditarmi e dopo che ho detto che non avrei piu' affrontato l'argomento. Comportamento infantile.

Quindi era un caso il fatto che tu abbia scelto "piu' piano di" invece che "piu' veloce di" per la tua "interpretazione perfettamente accurata e obbiettiva delle informazioni che abbiamo a disposizione" ?

In inglese "it's about the same", significa "e' quasi lo stesso".
Come "it's about to come", significa "sta quasi arrivando".

http://dictionary.reference.com/search?q=about
a·bout Audio pronunciation of "about" ( P ) Pronunciation Key (-bout)
adv.

1. Approximately; nearly: The interview lasted about an hour.
2. Almost: The job is about done.
\
La mia traduzione "piu' piano" e' fedele al testo originale tradotto letteralmente "e' quasi (inferiore) lo stesso", grammatica inglese alla mano. Ripassa l'inglese.
E noto con piacere che anche attaccandoti alle singole parole non stai ricavando molto se non una brutta figura.

Lo ripeto per tua utilita':
Il documento conferma che una CPU in-order di clock superiore va piu' piano ("about the same", quasi come) una CPU a clock inferore.

Avresti dovuto leggere con piu' attenzione prima di imbarcarti nel fare illazioni, dare epiteti e nello screditarmi. Sara' per la prossima volta.

E poi, che cos'altro intendevi con "come volevasi dimostrare" se non tentare di screditare le fonti?

Intendevo dire che la fonte conferma quello che andavo dicendo e che tu non volevi accettare. Il fato volle che per l'ennesima volta tu mi abbia portato fonti che confermano quello che stavo dicendo.

L'ho ignorato perché lo consideravo corretto. Non è il "genericamente" ad essere errato, è tutto il resto della frase.

Il resto della frase e' corretta, grammatica inglese alla mano.

Non è vero e lo sai. E' un'altra chiara ed evidente mistificazione e chi segue il thread se ne può rendere conto facilmente.

E' vero e lo so. Con questa tua politica di screditare quello che dico attaccandoti (e sbagliando anche) alle piccolezze non sta sortendo grandi risultati.

Dove avrei confuso una memoria locale con un processore lo sai solo tu.

Lo sanno anche tutti quelli che hanno letto. Qui:

Questo lo traduci con "Cell è uno stream processor"? ...Oppure si sta parlando della Local Storage degli stream processors contenuti in The Cell?

Oppure, in italiano, vuole dire uno "oppure" l'altro. Visto che tu credi abbastanza ingenuamente che il Cell non sia uno stream processor, nella tua frase rimane solo la seconda opzione.

E' evidente che stai solo cercando di screditare chi la pensa diversamente da te attribuendogli frasi mai dette. Ti cito: Ma adesso non avendo i mezzi e le capacita' di obiettare il discorso generale ti inventi anche cose che non ho scritto.. E con tale frase, vinci anche una segnalazione ai moderatori.

Segnalami pure, visto che non ti resta altro che buttarla sul personale per "vincere" questa discussione che ti vede dalla parte di chi non sa di che cosa si parla e cerca affannosamente su google, quotando testi che ti danno torto

Io non ho screditato nessuno, e posso quotare con dovizia i tuoi "rileggi meglio", e le tue errate traduzioni.

Sono stanco del tuo atteggiamento nei confronti di diversi utenti e non solo il solo al quale stai dando addosso. Il caso di cdimauro nelle News e' ancora plateale.

Il tuo mettermi in bocca frasi che non ho scritto dopo che avevo abbandonato la discussione e' stata una vigliaccata che non mi aspettavo.

E gia' che ci sei quota dove ti ho messo in bocca quello che non hai detto. Grammatica alla mano tu hai scritto che se IBM non si riferiva al Cell allora si riferiva alla memoria locale. Se poi non sei in grado di scrivere quello che realmente pensi, diventa un problema di comunicazione tuo e non mio.

Tieni presente che io non ho mai contestato il fatto che Cell sia uno "stream processor", contesto solo il fatto che nella frase che hai riportato si riferiscono ad una singola SPU quando dicono "stream processor" e non all'intero Cell!

Si riferiscono all'intero Cell infatti, come in quattro ti abbiamo fatto notare.

Ora, vuoi rinormalizzare il discorso oppure vuoi continuare sullo scontro dove hai buttato la discussione? Nel primo caso sarei felicissimo, e pretenderei delle scuse, nel secondo caso rischi una figuraccia peggiore di quella che hai gia' fatto. Non sono l'ultimo arrivato.

[fantoibed]

Originariamente inviato da fek

Questa e' una tua illazione e come tale non ha valore, ed e' oltretutto offensiva.

Ho detto che e' una traduzione libera, dopo che tu mi hai domandato se fosse una traduzione esatta. Con me non cambi le carte in tavola.



E' evidente solo per te. Mi quoti dove avrei scritto quello che mi hai attribuito?

Mi metti in bocca cose che non ho scritto solo per screditarmi e dopo che ho detto che non avrei piu' affrontato l'argomento. Comportamento infantile.



In inglese "it's about the same", significa "e' quasi lo stesso".
Come "it's about to come", significa "sta quasi arrivando".

http://dictionary.reference.com/search?q=about
a·bout Audio pronunciation of "about" ( P ) Pronunciation Key (-bout)
adv.

1. Approximately; nearly: The interview lasted about an hour.
2. Almost: The job is about done.
\
La mia traduzione "piu' piano" e' fedele al testo originale tradotto letteralmente "e' quasi (inferiore) lo stesso", grammatica inglese alla mano. Ripassa l'inglese.
E noto con piacere che anche attaccandoti alle singole parole non stai ricavando molto se non una brutta figura.

Lo ripeto per tua utilita':
Il documento conferma che una CPU in-order di clock superiore va piu' piano ("about the same", quasi come) una CPU a clock inferore.

Avresti dovuto leggere con piu' attenzione prima di imbarcarti nel fare illazioni, dare epiteti e nello screditarmi. Sara' per la prossima volta.



Intendevo dire che la fonte conferma quello che andavo dicendo e che tu non volevi accettare. Il fato volle che per l'ennesima volta tu mi abbia portato fonti che confermano quello che stavo dicendo.



Il resto della frase e' corretta, grammatica inglese alla mano.



E' vero e lo so. Con questa tua politica di screditare quello che dico attaccandoti (e sbagliando anche) alle piccolezze non sta sortendo grandi risultati.



Lo sanno anche tutti quelli che hanno letto. Qui:



Oppure, in italiano, vuole dire uno "oppure" l'altro. Visto che tu credi abbastanza ingenuamente che il Cell non sia uno stream processor, nella tua frase rimane solo la seconda opzione.



Segnalami pure, visto che non ti resta altro che buttarla sul personale per "vincere" questa discussione che ti vede dalla parte di chi non sa di che cosa si parla e cerca affannosamente su google, quotando testi che ti danno torto

Io non ho screditato nessuno, e posso quotare con dovizia i tuoi "rileggi meglio", e le tue errate traduzioni.

Sono stanco del tuo atteggiamento nei confronti di diversi utenti e non solo il solo al quale stai dando addosso. Il caso di cdimauro nelle News e' ancora plateale.

Il tuo mettermi in bocca frasi che non ho scritto dopo che avevo abbandonato la discussione e' stata una vigliaccata che non mi aspettavo.

E gia' che ci sei quota dove ti ho messo in bocca quello che non hai detto. Grammatica alla mano tu hai scritto che se IBM non si riferiva al Cell allora si riferiva alla memoria locale. Se poi non sei in grado di scrivere quello che realmente pensi, diventa un problema di comunicazione tuo e non mio.



Si riferiscono all'intero Cell infatti, come in quattro ti abbiamo fatto notare.

Ora, vuoi rinormalizzare il discorso oppure vuoi continuare sullo scontro dove hai buttato la discussione? Nel primo caso sarei felicissimo, e pretenderei delle scuse, nel secondo caso rischi una figuraccia peggiore di quella che hai gia' fatto. Non sono l'ultimo arrivato.

Tieniti pure la ragione, se la vuoi. Non mi abbasso ad un livello tanto infantile.

[fek]

http://www.research.ibm.com/cell/

Exploring realtime multimedia content creation in video games
6th Workshop on Media and Streaming Processors in conjunction with MICRO 36, December 2004. (B. Matthews, J.D. Wellman, M. Gschwind)

The Microarchitecture of the Streaming Processor for a CELL Processor
ISSCC 2005, February 2005. (B. Flachs et al.)

Ovviamente adesso si mettera' magari a sindacare sul cavillo che Stream e Streaming non sono la stessa cosa.

http://www.blachford.info/computer/Cells/Cell2.html

Stream Processing

A big difference in Cells from normal CPUs is the ability of the APUs in a Cell to be chained together to act as a stream processor [Stream]. A stream processor takes data and processes it in a series of steps. Each of these steps can be performed by one or more APUs.

Oppure si mettera' a sindacare sul fatto che "l'essere configurabile per agire da stream processor" non vuol dire essere uno stream processor.

Per altro anche questo articolo ripete esattamente le stesse cose che ho detto fino ad ora e non menziona alcuna traduzione di codice dinamica.

Oppure si mettera' a sindacare che un processore formato da 9 core di cui 8 lavorano preferibilmente su dati in streaming non e' uno stream processor.

[fek]

Originariamente inviato da fantoibed

Tieniti pure la ragione, se la vuoi. Non mi abbasso ad un livello tanto infantile.

A giudicare da questo direi il contrario, ti sei gia' abbassato a livelli molto piu' infantili; ho smesso di fare lo specchio riflesso alle elementari. Io non mi prendo la ragione, su questo argomento ho ragione come ampiamente dimostrato in lungo e in largo con dovizia di particolari.

Fattene una ragione

[fantoibed]

Originariamente inviato da fek

Io non mi prendo la ragione, su questo argomento ho ragione come ampiamente dimostrato in lungo e in largo con dovizia di particolari.

Fattene una ragione

Complimenti, allora!

[fek]

Originariamente inviato da fantoibed

Complimenti, allora!

Niente per cui ricevere complimenti, a me basta che sia stata evitata della cattiva informazione anche se ci sono volute quattro pagine

[fantoibed]

Originariamente inviato da fek

Niente per cui ricevere complimenti, a me basta che sia stata evitata della cattiva informazione anche se ci sono volute quattro pagine

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.

[lowenz]

Io voglio il parere di repne scasb

[fek]

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.

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.

[fantoibed]

Originariamente inviato da fek

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.

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...