Chip RISC, a Intel piacciono emulati

Il chipmaker ha stretto un accordo con una società che sviluppa un noto software di emulazione capace di tradurre il codice RISC nel rispettivo codice per Itanium e Xeon

San Francisco (USA) - Se non lo puoi battere... emulalo. Una massima che sembra adattarsi all'accordo appena stretto da Intel con la società inglese Transitive, sviluppatrice di un noto software di emulazione in grado di far girare sui chip di Intel le applicazioni scritte per le principali CPU RISC (Reduced Instruction Set Computer).

Se nel mercato dei server di fascia bassa le architetture RISC, come PowerPC, SPARC e MIPS, hanno ceduto il passo alle più economiche e flessibili architetture x86, nel segmento dei server di fascia alta rappresentano ancora la piattaforma dominante. Intel sta tentando di penetrare in questo segmento con Itanium, ma fino ad oggi i risultati non sono stati entusiasmanti.

Per incoraggiare le aziende a migrare verso i propri chip, Intel aiuterà Transitive ad accelerare lo sviluppo e la commercializzazione di prodotti basati su QuickTransit, una tecnologia di virtualizzazione dell'hardware che traduce il codice RISC nel corrispettivo codice EPIC di Itanium e x86 di Xeon. QuickTransit si trova anche alla base di Rosetta, lo strato di emulazione software che permette di far girare i programmi scritti per PowerPC sui Mac Intel-based.
A differenza di altri software analoghi, che traducono le istruzioni una alla volta, QuickTransit è in grado di analizzare intere porzioni di codice per ottimizzarne il processo di esecuzione. Questa caratteristica, secondo Transitive, consente di emulare le applicazioni RISC ad una velocità molto vicina a quella del processore nativo.

Intel metterà a disposizione della propria partner fondi e risorse umane, inoltre promuoverà la tecnologia QuickTransit presso clienti e sviluppatori.
TAG: sw
31 Commenti alla Notizia Chip RISC, a Intel piacciono emulati
Ordina
  • Visto che si è imposto non per superiorità tecnica, ma per incapacità commerciale dei concorrenti, Alpha per esempio era di gran lunga superiore ed è stato "ucciso" grazie a un patto scellerato del suo ultimo proprietario, HP, con intel.
    Molti risc promettenti in fascia bassa, poi, non si sono affermati per la scarsa attenzione e investimenti dedicati loro da MS, quando ancora li supportava: Windows NT, in origine, era prodotto anche per Mips e Alpha, per esempio, e non c'era CPU intel che avesse pari prestazioni a quel tempo, tra l'altro era possibile produrre WS a basso prezzo con queste CPU, ne faceva perfino Olivetti (Mips) e Vobis, che faceva una WS Alpha che a parità o superiorità di periferiche e con una CPU enormemente più prestante costava meno di un mac IIfx.
    non+autenticato
  • L'itanium zoppica? ehm... l'itanium è uno dei processori più usati nei super pc e non solo, è bello parlare senza conoscere i fatti vero?
    non+autenticato

  • - Scritto da: Anonimo
    > L'itanium zoppica? ehm... l'itanium è uno dei
    > processori più usati nei super pc e non solo, è
    > bello parlare senza conoscere i fatti vero?
    Dillo a chi ha scritto l'articolo, io ho solo fatto un commento.
    Comunque, se ti riferisci ai supercomputer, la fanno ancora da padroni Power e PowerPC nella zona alta della classifica, gli sforzi di intel su Itanium non sono ripagati da risultati in proporzione, gli va molto meglio con gli Xeon
    http://www.top500.org/
    non+autenticato

  • - Scritto da: Anonimo
    >
    > - Scritto da: Anonimo
    > > L'itanium zoppica? ehm... l'itanium è uno dei
    > > processori più usati nei super pc e non solo, è
    > > bello parlare senza conoscere i fatti vero?
    > Dillo a chi ha scritto l'articolo, io ho solo
    > fatto un commento.
    > Comunque, se ti riferisci ai supercomputer, la
    > fanno ancora da padroni Power e PowerPC nella
    > zona alta della classifica, gli sforzi di intel
    > su Itanium non sono ripagati da risultati in
    > proporzione, gli va molto meglio con gli Xeon
    > http://www.top500.org/
    A quanto pare gli Itanium nella Top500 vengono surclassati come percentuale di sistemi perfino da AMD, non solo da IBM.
    IBM poi li surclassa anche nelle prestazioni.
    non+autenticato
  • ehm... se però vai a vedere le performance per dollaro non c'è proprio storia... 1 Itanium2 costa una bazzecola rispetto ad 1 processore power di IBM...

    FEz
    non+autenticato
  • Posso avere un link approposito di questo?

  • - Scritto da: Anonimo
    > Visto che si è imposto non per superiorità
    > tecnica, ma per incapacità commerciale dei
    > concorrenti, Alpha per esempio era di gran lunga
    > superiore ed è stato "ucciso" grazie a un patto
    > scellerato del suo ultimo proprietario, HP, con
    > intel.
    > Molti risc promettenti in fascia bassa, poi, non
    > si sono affermati per la scarsa attenzione e
    > investimenti dedicati loro da MS, quando ancora
    > li supportava: Windows NT, in origine, era
    > prodotto anche per Mips e Alpha, per esempio, e
    > non c'era CPU intel che avesse pari prestazioni a
    > quel tempo, tra l'altro era possibile produrre WS
    > a basso prezzo con queste CPU, ne faceva perfino
    > Olivetti (Mips) e Vobis, che faceva una WS Alpha
    > che a parità o superiorità di periferiche e con
    > una CPU enormemente più prestante costava meno di
    > un mac IIfx.


    Guarda che l'architettura EPIC ed Itanium è stata inventata dai progettisti di Alpha che sono passati ad Intel quando il progetto Alpha venne chiuso...
    Tanto è che sui vari Itanium è possibile notare grosse somiglianze con CPU Alpha annunciate e mai uscite sul mercato...

    x86-64 è una schifezza al confronto di Itanium. Intel ha dovuto includere la tecnologia solo perchè la gente è andata dietro ad AMD che non ha le risorse per costruire un ISA nuovo di zecca.
    non+autenticato

  • - Scritto da: Anonimo

    > Guarda che l'architettura EPIC ed Itanium è stata
    > inventata dai progettisti di Alpha che sono
    > passati ad Intel quando il progetto Alpha venne
    > chiuso...

    Itanium e' nato come un progetto congiunto
    tra Intel ed HP, inizialmente era nato
    come un progetto interno di HP, mica di DEC.

    In pratica quando Compaq (che aveva assorbito
    quel che restava di DEC) ha ceduto brevetti
    e licenze degli Alpha ad Intel alcuni di quelli
    che restavano sono passati ad Intel
    ma inquel momento il Merced
    (il primo Itanium) era gia pronto.
    Deve ancora uscire un Itanium su cui
    i progettisti ex-Alpha ci abbiano lavorato sopra.

    > Tanto è che sui vari Itanium è possibile notare
    > grosse somiglianze con CPU Alpha annunciate e mai
    > uscite sul mercato...

    ROTFL! Intendi il memory controller integrato
    (come gli Athlon64) oppure
    il simultaneous multithreading (quello
    che Intel ha mal implementato sui P4
    mentre invece Sun ha implementato
    bene sugli UltraSparc T1) ?

    > x86-64 è una schifezza al confronto di Itanium.

    Se parli di come e' stato implementato
    sugli ultimi P4 ti do ragione.

    Invece negli Athlon64 c'e' invece davvero
    la mano di alcuni dei progettisti degli Alpha
    (che avevano mollato DEC quando ormai
    era chiaro che sarebbe finita in spezzatino).

    > Intel ha dovuto includere la tecnologia solo
    > perchè la gente è andata dietro ad AMD che non ha
    > le risorse per costruire un ISA nuovo di zecca.

    Peccato che quell'ISA nuova di zecca si sia
    rivelata un grosso buco nell'acqua perche
    erano state messe nella stessa ISA troppe
    feature architetturali che si intralciavano
    a vicenda, e questo nonostante
    si trattasse della TERZA VOLTA che Intel cercava
    di sotterrare x86 con una nuova ISA
    (prima negli anni '80 con gli iapx432
    poi nei '90 con l'i80860
    ed ora con Itanium).

    L'unico modo con cui riescono a fare stare
    a galla gli Itanium e' tramite l'utilizzo
    di cache enormi (persino per i parametri
    tipici di Intel).
    non+autenticato

  • - Scritto da: Anonimo
    >
    > - Scritto da: Anonimo
    >
    > > Guarda che l'architettura EPIC ed Itanium è
    > stata
    > > inventata dai progettisti di Alpha che sono
    > > passati ad Intel quando il progetto Alpha venne
    > > chiuso...
    >
    > Itanium e' nato come un progetto congiunto
    > tra Intel ed HP, inizialmente era nato
    > come un progetto interno di HP, mica di DEC.
    >
    > In pratica quando Compaq (che aveva assorbito
    > quel che restava di DEC) ha ceduto brevetti
    > e licenze degli Alpha ad Intel alcuni di quelli
    > che restavano sono passati ad Intel
    > ma inquel momento il Merced
    > (il primo Itanium) era gia pronto.
    > Deve ancora uscire un Itanium su cui
    > i progettisti ex-Alpha ci abbiano lavorato sopra.


    http://www.osnews.com/story.php?news_id=636

    There was loads of hype around the super secret Merced project and many expected it to just roll over the server market. Such was the expectation in fact that both HP and SGI scrapped their own CPUs (PA-RISC and MIPS Rx000) in favor of Merced.

    DEC in fact were so worried they tried to foul things up for Intel by taking them to court, this ended up with with a deal with Intel buying a Fab (chip factory) and DECs StrongARM team. Intel also took over making the Alphas for DEC.

    non+autenticato

  • - Scritto da: Anonimo
    >
    > - Scritto da: Anonimo
    >
    > > Guarda che l'architettura EPIC ed Itanium è
    > stata
    > > inventata dai progettisti di Alpha che sono
    > > passati ad Intel quando il progetto Alpha venne
    > > chiuso...
    >
    > Itanium e' nato come un progetto congiunto
    > tra Intel ed HP, inizialmente era nato
    > come un progetto interno di HP, mica di DEC.
    >
    > In pratica quando Compaq (che aveva assorbito
    > quel che restava di DEC) ha ceduto brevetti
    > e licenze degli Alpha ad Intel alcuni di quelli
    > che restavano sono passati ad Intel
    > ma inquel momento il Merced
    > (il primo Itanium) era gia pronto.
    > Deve ancora uscire un Itanium su cui
    > i progettisti ex-Alpha ci abbiano lavorato sopra.


    http://www.faculty.iu-bremen.de/birk/lectures/PC10...

    Digital/Compaq:
    Alpha.

    Alpha was the first 64-bit processor to reach 1 GHz, in 2001. Ironically, this milestone came just a few short weeks after Compaq proclaimed it was discontinuing Alpha development and licensing Alpha technology to Intel.

    The future of this processor is heavily in doubt, as, thanks to a recent settlement, its fabrication is under the control of Intel. It is a wonderful processor, with a forward thinking design, and it has large base of installed software, as it is capable of running Windows NT. Often referred to as ?the processor that time forgot,? Alpha?s been around for years, silently improving upon itself until today, where it is an established 64-bit processor, with something of a following. If Intel doesn?t kill this processor now, it will be a serious contender in the 64-bit Desktop wars. The simple fact that it has been around for so long, and has many of it?s bugs worked out will make it much more than a passive contender to the Merced and the SledgeHammer processors.
    non+autenticato
  • Aggiungerei che Alpha, pur essendo stato fermato all'ormai vetusta EV79 con la cancellazione dei piani e l'accantonamento dei progetti per EV8, EV9 ed EV10
    è riuscito ugualmente a surclassare sempre Itanium 1 fino alla morte ingloriosa di quest'ultimo, e perfino a tener testa per parecchio tempo a Itanium 2.
    non+autenticato
  • L'architettura mista CRISC esiste da anni oramai.
    L'emulazione hardware di altre architetture nonchè l'aumento di velocità di macchine virtuali sarà garantito dalle unità di accellerazione JIT che saranno incluse nelle future CPU entro 1 o 2 anni.
    non+autenticato

  • - Scritto da: Anonimo
    > L'architettura mista CRISC esiste da anni oramai.
    > L'emulazione hardware di altre architetture
    > nonchè l'aumento di velocità di macchine virtuali
    > sarà garantito dalle unità di accellerazione JIT
    > che saranno incluse nelle future CPU entro 1 o 2
    > anni.

    Scusa la domanda... ma questo JIT nella CPU di cui parli, hai una qualche fonte attendibile?

    sarei molto interessatoSorride

  • - Scritto da: TaGoH
    >
    > - Scritto da: Anonimo
    > > L'architettura mista CRISC esiste da anni
    > oramai.
    > > L'emulazione hardware di altre architetture
    > > nonchè l'aumento di velocità di macchine
    > virtuali
    > > sarà garantito dalle unità di accellerazione JIT
    > > che saranno incluse nelle future CPU entro 1 o 2
    > > anni.
    >
    > Scusa la domanda... ma questo JIT nella CPU di
    > cui parli, hai una qualche fonte attendibile?
    >
    > sarei molto interessatoSorride

    Intel includerà presto nelle CPU l'accelleratore JIT come tecnologia Rockton :


    -------

    http://www.theinquirer.net/?article=24781


    [..] RT is basically managed code, Java and .NET, acceleration in mostly hardware, with some software assist too. On the hardware level, it is basically a new instruction set like MMX or SSE, specifically designed to help those things that Java does a lot. Like VT, the goal is to assist software by lessening the cost of common things, and adding a few new capabilities. [..]

    [..] So, this combo of hardware and software collectively called Rockton will be coming out in the not all that near future, and it should be baked into the Merom cores in one form or another from the start. When it will be finalised and activated is anyone's guess, but it should be worth a whopping amount on Java benches. [..]

    ------------
    non+autenticato
  • Le analogie ci sono, speriamo solo che il codice non sia lo stesso o che altrimenti sia GPL.
    non+autenticato
  • da quel poco che mi ricordo di sistemi, non è molto + conveniente emulare cisc su risc ? le istruzioni di risc sono + elementari di quelle cisc, come dire che una istruzione cisc può essere tradotta in + operazioni risc, giusto ? quindi, in quanto a prestazioni, emulare le mini-op risc su cisc, non è come emulare assembly in Java, ovvero uno spreco assurdo di tempo ?
    QW
    81

  • - Scritto da: QW
    > da quel poco che mi ricordo di sistemi, non è
    > molto + conveniente emulare cisc su risc ? le
    > istruzioni di risc sono + elementari di quelle
    > cisc, come dire che una istruzione cisc può
    > essere tradotta in + operazioni risc, giusto ?
    > quindi, in quanto a prestazioni, emulare le
    > mini-op risc su cisc, non è come emulare assembly
    > in Java, ovvero uno spreco assurdo di tempo ?

    Bhè allora sarebbe ancora più semplice per un cisc emulare le istruzioni di un risc. L'insieme delle istruzioni di un cisc è più grosso di quello di un risc quindi per ogni istruzione risc hai un istruzione cisc, invece non è vero il viceversa.


    Ciao
    non+autenticato

  • - Scritto da: Anonimo
    >
    > - Scritto da: QW
    > > da quel poco che mi ricordo di sistemi, non è
    > > molto + conveniente emulare cisc su risc ? le
    > > istruzioni di risc sono + elementari di quelle
    > > cisc, come dire che una istruzione cisc può
    > > essere tradotta in + operazioni risc, giusto ?
    > > quindi, in quanto a prestazioni, emulare le
    > > mini-op risc su cisc, non è come emulare
    > assembly
    > > in Java, ovvero uno spreco assurdo di tempo ?
    >
    > Bhè allora sarebbe ancora più semplice per un
    > cisc emulare le istruzioni di un risc. L'insieme
    > delle istruzioni di un cisc è più grosso di
    > quello di un risc quindi per ogni istruzione risc
    > hai un istruzione cisc, invece non è vero il
    > viceversa.
    >
    >
    > Ciao

    Ma scusa, non è più semplice ricompilare i sorgenti? Occhiolino
    non+autenticato

  • - Scritto da: Anonimo
    >
    > - Scritto da: QW
    > > da quel poco che mi ricordo di sistemi, non è
    > > molto + conveniente emulare cisc su risc ? le
    > > istruzioni di risc sono + elementari di quelle
    > > cisc, come dire che una istruzione cisc può
    > > essere tradotta in + operazioni risc, giusto ?
    > > quindi, in quanto a prestazioni, emulare le
    > > mini-op risc su cisc, non è come emulare
    > assembly
    > > in Java, ovvero uno spreco assurdo di tempo ?
    >
    > Bhè allora sarebbe ancora più semplice per un
    > cisc emulare le istruzioni di un risc. L'insieme
    > delle istruzioni di un cisc è più grosso di
    > quello di un risc quindi per ogni istruzione risc
    > hai un istruzione cisc, invece non è vero il
    > viceversa.
    >
    >
    > Ciao

    Non proprio, è vero che l'insieme delle istruzioni di un processore CISC è più grande ma è anche vero che ci vogliono più cicli di clock per eseguire una istruzione singola. Riassumendo:
    RISC=set di istruzioni ridotto per una esecuzione + veloce delle singole istruzioni
    CICS=set di istruzioni ampliato a scapito di una esecuzione di una singola istruzione com + cicli di clock

    ciao
    non+autenticato
  • per quello che mi ricordo quasi tutte le cpu cisc sono internamente risc e hanno un modulo interno per la conversione delle istruzioni...

    http://www.google.it/search?hl=it&rls=GGGL%2CGGGL%...=
    non+autenticato

  • Si esatto, credo che ormai tutte (o quasi) le CPU di ultima generazione abbiano un'architettura interna che si possa definire più RISC che CISC.

    Poi per retrocompatibilità queste dispongono anche di un set di istruzioni CISC, che però in pase di esecuzione vengono scomposte in istruzioni CISC.

    Quindi considerando l'argomento dell'articolo, mi sembra di capire che più di un'emulazione di un RISC su un CISC, si tratti di un'emulazione di un RISC su un altro RISC.
    non+autenticato
  • l'itanium non è cisc, è risc (anzi, è epic), ciò è chiaramente testimoniato dal fatto che le istruzioni hanno una dimensione fissa (al contrario di ciò che avveniva sugli x86) e dal fatto che non esistono istruzioni per l'accesso diretto alla memoria (caratteristica propria dei risc questa), ma studiarsi i datasheet dell'intel prima, no eh?
    non+autenticato

  • - Scritto da: Anonimo
    > l'itanium non è cisc, è risc (anzi, è epic), ciò
    > è chiaramente testimoniato dal fatto che le
    > istruzioni hanno una dimensione fissa (al
    > contrario di ciò che avveniva sugli x86) e dal
    > fatto che non esistono istruzioni per l'accesso
    > diretto alla memoria (caratteristica propria dei
    > risc questa), ma studiarsi i datasheet dell'intel
    > prima, no eh?

    Su EPIC hai ragione.. ma che diavolo vorresti dire con "non c'è accesso diretto alla memoria" ? Ma hai mai programmato in assembly in vita tua ?
    non+autenticato
  • più di quello che pensi, mi sono solo espresso male, facevo riferimento ad istruzioni del tipo mov eax, dword ptr [qualcosa] su x86, che su ia64 non esistono più, mi sarei dovuto spiegare meglio lo so
    non+autenticato

  • - Scritto da: Anonimo
    > l'itanium non è cisc, è risc (anzi, è epic), ciò
    > è chiaramente testimoniato dal fatto che le
    > istruzioni hanno una dimensione fissa (al
    > contrario di ciò che avveniva sugli x86) e dal
    > fatto che non esistono istruzioni per l'accesso
    > diretto alla memoria (caratteristica propria dei
    > risc questa), ma studiarsi i datasheet dell'intel
    > prima, no eh?


    Fai confusione. Accesso diretto alla memoria inesistente su EPIC ? Vorrai dire che ha sistemi di predizione avanzata per aumentare la velocità del codice magari...


    ---------->

    http://www.cs.clemson.edu/~mark/464/acmse_epic.pdf

    3.6. Data speculation
    To be able to rearrange load and store instructions, the
    compiler must know the memory addresses to which the
    instructions refer. Because of aliasing, compilers are not
    always able to do this at compile time. In the absence of
    exact alias analysis, most compilers must settle for safe but
    slower (i.e., unreordered) code. EPIC architectures provide
    speculative loads that can be used when an alias situation is
    unlikely but yet still possible. A speculative load is moved
    earlier in the schedule to start the load as early as possible;
    and, at the place where the loaded value is needed, a data-
    verifying load is used instead. If no aliasing has occurred,
    then the value retrieved by the speculative load is used by
    the data-verifying load instruction. Otherwise, the data-
    verifying load reexecutes the load to obtain the new value.
    IPF provides advanced load and advanced load check
    instructions that use an Advanced Load Address Table
    (ALAT) to detect stores that invalidate advanced load
    values.
    The IBM Stretch (1961) started loads early, as
    mentioned above. The lookahead unit checked the memory
    address of a store instruction against subsequent loads and
    on a match cancelled the load and forwarded the store value
    to the buffer reserved for the loaded value (only one
    outstanding store was allowed at a time) [3]. The CDC
    6600 (1964) memory stunt box performed similar actions

    <------------
    non+autenticato

  • - Scritto da: QW
    > da quel poco che mi ricordo di sistemi, non è
    > molto + conveniente emulare cisc su risc ? le
    > istruzioni di risc sono + elementari di quelle
    > cisc, come dire che una istruzione cisc può
    > essere tradotta in + operazioni risc, giusto ?
    > quindi, in quanto a prestazioni, emulare le
    > mini-op risc su cisc, non è come emulare assembly
    > in Java, ovvero uno spreco assurdo di tempo ?

    Ormai Non esistono + i CISC e RISC, quello che tu chiami CISC non è altro che un interprete CISC su un processore "RISC"Occhiolino

    cmq si sarà molto + lentoSorride
    Non ci sono dubbiSorride

    Ma avrai la comodità di farlo girare su + hardwareSorride

  • Ora manca solo la modularizzazione spinta.
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 6 discussioni)