AMD: il futuro dei chip è x86

Confermando le scelte fatte per i suoi giovani processori a 64 bit, AMD vuol estendere l'anziana architettura x86 anche ai dispositivi non-PC, come PDA e telefoni cellulari, e sfidare il dominio di ARM. Compatibilità innanzi tutto

San Jose (USA) - La vecchia architettura x86, introdotta da Intel nel lontano 1978 con il processore 8086, è destinata a dominare non soltanto il mondo dei PC, ma anche quello dei dispositivi di rete, dei computer palmari e dei telefoni cellulari. A dirlo, paradossalmente, non è l'inventrice di questa tecnologia, ma una delle sue più anziane rivali, AMD.

Negli ultimi anni il chipmaker di Sunnyvale ha scommesso moltissimo sull'architettura x86, tanto che non solo ne ha proposto evoluzioni in grado - si pensi ai processori Athlon - di tenere testa alle CPU di Intel, ma l'ha anche traghettata - a differenza della propria rivale, che ha preferito cambiare drasticamente rotta - nell'era dei 64 bit: Opteron e Athlon 64, come noto, si basano infatti su di un'architettura, l'AMD64 (prima nota come x86-64), in grado di eseguire indifferentemente codice x86 a 32 bit e a 64 bit.

In questi 25 anni la tecnologia x86 si è evoluta ed oggi le architetture alla base dell'ultima generazione di chip x86, come i Pentium 4 di Intel e gli Athlon di AMD, contengono molte soluzioni che si trovano, ad esempio, nei processori RISC, gli stessi che da anni dominano il mercato dei server e, oggi, anche quello dei dispositivi mobili.
Nel suo discorso presso il Microprocessor Forum di San Jose, Fred Weber, chief technology officer della divisione CPU di AMD, ha sottolineato l'importanza, per l'industria, di costruire processori "che parlino la stessa lingua", e la lingua franca, secondo Weber, non può che essere x86.

"L'architettura x86 è quella che oggi vanta il più vasto parco di software. Portare o riscrivere questo software per assicurare che esso giri anche su RISC e altre architetture significa buttare via un sacco di soldi", ha detto Weber. "Non si tratta soltanto di portare le applicazioni: il porting va fatto anche del codice di sistemi operativi, strumenti e driver. E' abbastanza chiaro che questo non può funzionare".

Uno dei più grandi scogli all'affermazione dei processori Itanium è costituito proprio dall'incompatibilità con il software a 32 bit (a meno di non ricorrere, sacrificando notevolmente le prestazioni, all'emulazione). Un ostacolo a cui AMD sostiene di aver ovviato progettando CPU, come Opteron e Athlon 64, che consentono alle aziende di continuare ad utilizzare il software a 32 bit e, nell'ugual tempo, migrare verso i 64 bit in modo più progressivo e mirato.

Intel, però, non la pensa così.
67 Commenti alla Notizia AMD: il futuro dei chip è x86
Ordina

  • Per me sarebbe fantastico conosco molto bene l'architettura x86, è vero potrei imparare anche le altre, ma quella x86 già la conosco, potrei subito buttarmi nello sviluppo di videogames per cellulari riciclando mio vecchio software adesso inutile.

    Potrei anche scrivere qualche piccolo S.O. per cellulari o palmari se i processori fosser degli x86 compatibili.

    Sono certo che ci sarebbe un sacco di software vecchio che potrebbe essere riciclato, quindi sarebbe una grande cosa.


    non+autenticato
  • Umh si riciclare ti fa risparmiare un sacco di soldi, non c'è dubbio, ma.... l'architettura x86 non è la "migliore". Qua la vera questione è: va bene risparmiare soldi _adesso_ e tenersi una architettura che funziona, o è meglio spendere molti soldi _adesso_ per sistemare i programmi e cominciare ad usare una architettura che funziona meglio? Ovviamente si fa sempre la cosa che costa meno, anche se è qualitativamente peggiore. Ecco xchè hanno puntato su x86. Tieni conto che poi ti abitueresti alla nuova (ma che nuova? c'è già solo che è di nicchia) architettura e tutti i programmi verrebbero fatti per quella quindi ti ritroveresti nella stessa situazione che hai adesso con x86 ma con una architettura migliore.

    DjMix
    non+autenticato
  • il resto non mi interessa. Se Linux funzionasse sul C64 non avrei motivi per cambiare questo computer. Mica sono un utonto.
    non+autenticato
  • > LUnix e' uguale ?
    >
    > http://hld.c64.org/poldi/lunix/lunix.html
    >
    > Sorride
    >

    nooooooo....
    non ci posso credere Sorride
    4751
  • C'è veramente bisogno di una lingua franca sul set di istruzioni????

    Nel momento storico attuale si sta stratificando l'architettura dei calcolatori all'inverosimile. Dal lato hardware intel annuncia processori che esporranno copie virtuali di se stessi per supportare più macchine virtuali a livello hardware. IBM vende virtual server basati su uno strano simil-exokernel sotto il sistema operativo che virtualizza il processore.

    Java e .NET fanno la gara a chi conquista più programmatori. E tutt'è due girano sopra una macchina virtuale.

    Insomma para para, ci saranno talmente tanti strati tra qualche anno, tra il software e l'hardware tanto da rendere questo concetto di "lingua franca" un puro non senso.

    Infine, affermare che x86 esteso a 64 bit sia una gran cosa è chiaramente una baggianata commerciale. Si veda Hannessey-Patterson per ulteriori chiarimenti.
    Che la scelta di intel su l'architettura VLIW _attualmente_ non sia competitiva non v'è dubbio, ma nel prossimo futuro, IMHO, sarà decisiva.

    Dulcis in fundo, leggere tutto sto po' po' di affermazioni su x86 e poi vedere che acquistano MIPS fa sconcupisciare dalle risate.
    E' come dire... "comprate la Trabant che è la miglior auto del mondo" e poi sotto sotto acquistare il reparto di ricerca e sviluppo della Ferrari.... Tsk
    non+autenticato

  • - Scritto da: Anonimo
    > C'è veramente bisogno di una lingua franca
    > sul set di istruzioni????

    Ovviamente NO.

    > Java e .NET fanno la gara a chi conquista
    > più programmatori. E tutt'è due girano sopra
    > una macchina virtuale.

    E già questo ti dice che stiamo puntando dritti verso il baratro. Usiamo il surplus di potenza per emulare, armonizzare, interfacciare, buttare dentro strati su strati di sovrastrutture INUTILI, ridondanti, macchinose ed inefficienti. Un confronto anche superficiale con i sistemi critici life-dependable fa venire da piangere per quello che riescono a fare in hard realtime, occupando un millesimo di memoria e con potenze elaborative che oggi contraddistinguono a malapena un cellulare o un MP3 player.

    > Infine, affermare che x86 esteso a 64 bit
    > sia una gran cosa è chiaramente una
    > baggianata commerciale. Si veda
    > Hannessey-Patterson per ulteriori
    > chiarimenti.

    Escludo che chi fa simili affermazioni abbia mai visto anche solo la copertina del "Quantitative approach" di Hennessy & Patterson (la vera Bibbia dell'architettura di calcolatori). Dubito anche che abbiamo mai messo le mani su una macchina Alpha o MIPS, magari per scrivere in assembly.

    > E' come dire... "comprate la Trabant che è
    > la miglior auto del mondo" e poi sotto sotto
    > acquistare il reparto di ricerca e sviluppo
    > della Ferrari.... Tsk
    Lascia che comprino la Trabant. Finché ci saranno in giro delle sane WS Alpha, del resto me ne impippo allegramente.
    non+autenticato
  • e` come se per evolvere l`aereoplano continuassero a modificare i biplani
    non+autenticato

  • - Scritto da: Anonimo
    > e` come se per evolvere l`aereoplano
    > continuassero a modificare i biplani

    Peggio... x86 è meno che una bicicletta con le ali posticce.
    non+autenticato

  • - Scritto da: Anonimo
    >
    > - Scritto da: Anonimo
    > > e` come se per evolvere l`aereoplano
    > > continuassero a modificare i biplani
    >
    > Peggio... x86 è meno che una bicicletta con
    > le ali posticce.

    Si si, e in base a cosa lo dici? Parlamo ovviamente del 32bit, non del fatto che x86 ha anche la retrocompatibilità con il "real mode" tramite l'istruzione apposita... cioè voglio dire, sicuramente voi due mi saprete spiegare che problemi dà il protected mode di x86...

    Un consiglio: se dovete tirar fuori parole a casaccio di cui ignorate il vero significato, tacete che fate più bella figura.
    non+autenticato
  • Non si tratta di protected mode o meno. E' assodato e palese che a parita di algoritmo con l'architettura x86 spesso servono piu' istruzioni per programma. Forse questo in un futuro non sara un problema, ma per ora lo e'. Arm, StrongArm e Xscale permettono di scrivere un programma usando molti meno k dell'equivalente x86. Se prendi l'esempio dei PDA ti rendi conto che riuscire a risparmiare anche solo 2 Mb avendo a disposizione una flash rom di 32 e' abbastanza importante.

    Cya
       WarfoX
    non+autenticato

  • - Scritto da: Anonimo
    > Non si tratta di protected mode o meno. E'
    > assodato e palese che a parita di algoritmo
    > con l'architettura x86 spesso servono piu'
    > istruzioni per programma. Forse questo in un
    assodato e palese mica tanto... dipende dalle architetture
    io mi ricordavo che i binari RISC erano più grossi di quelli CISC, dato che spesso una sola istruzione CISC fa l'equivalente di due o più RISC
    ad esempio, in x86 puoi fare confronto e salto in un'istruzione, alcune architetture (tipiche degli embedded) hanno un'istruzione per il confronto ed una per il salto
    non+autenticato
  • > assodato e palese mica tanto... dipende
    > dalle architetture
    > io mi ricordavo che i binari RISC erano più
    > grossi di quelli CISC, dato che spesso una
    > sola istruzione CISC fa l'equivalente di
    > due o più RISC
    > ad esempio, in x86 puoi fare confronto e
    > salto in un'istruzione, alcune architetture
    > (tipiche degli embedded) hanno un'istruzione
    > per il confronto ed una per il salto

    Si e' vero infatti le architetture RISC si preferiscono per certe applicazioni e CISC per altre.
    Ricordate MMX istruzioni aggiunge a favore di applicazioni grafiche?
    Per una macchina server sarebbero piu' che inutili ma per applicazioni grafiche serve.

    Ad ogni applicazione il suo sistema: il suo processore e le sue periferiche
    non+autenticato

  • - Scritto da: Anonimo
    > > assodato e palese mica tanto... dipende
    > > dalle architetture
    > > io mi ricordavo che i binari RISC erano
    > più
    > > grossi di quelli CISC, dato che spesso una
    > > sola istruzione CISC fa l'equivalente di
    > > due o più RISC
    > > ad esempio, in x86 puoi fare confronto e
    > > salto in un'istruzione, alcune
    > architetture
    > > (tipiche degli embedded) hanno
    > un'istruzione
    > > per il confronto ed una per il salto
    >
    > Si e' vero infatti le architetture RISC si
    > preferiscono per certe applicazioni e CISC
    > per altre.
    > Ricordate MMX istruzioni aggiunge a favore
    > di applicazioni grafiche?
    > Per una macchina server sarebbero piu' che
    > inutili ma per applicazioni grafiche serve.
    >
    > Ad ogni applicazione il suo sistema: il suo
    > processore e le sue periferiche

    questo richiede troppo sforzo mentale per un (***)troll, loro già pensano in maniera diversa, non possono anche sforzarsi di pensare come persone normali.

    Loro hanno letto da qualche parte che "quello schifo di CISC fa cacare" e gli basta per riempirsi la bocca di fesserie. Poi se la prendono quando lo fanno gli altri.

    Gente che probabilmente non sa neanche cosa sia un compilatore, cosa voglia dire ottimizzazione (vantaggi del CISC???) ma legge la definizione di RISC, dice "ha meno istruzioni, è più semplice e *intuitivo* perciò è migliore". Peccato che l'intuitività di un linguaggio macchina non sia la sua dote migliore!

    Scusate lo sfogo ma non ne posso più di leggere le stesse fesserie ogni giorno da capo.

    non+autenticato
  • Uff... peccato che poi x86 faccia letteralmente pena (per lo meno sino a P5, ultima architettura su cui ho programmato in assembler) nella gestione degli indirizzamenti in memoria e un fottio di altre cosine... In ogni caso prendi un programma per Xscale e StrongArm e scrivilo per x86. Quello Xscale/StrongArm occupa meno memoria (vista la pignoleria). Oppure scrivi un programma per Coldfire.... e poi ne riparliamo..

    Cya
       WarfoX
    non+autenticato

  • - Scritto da: Anonimo
    > Non si tratta di protected mode o meno. E'
    > assodato e palese che a parita di algoritmo
    > con l'architettura x86 spesso servono piu'
    > istruzioni per programma.

    Ah siii??? Quindi fammi capire, una architettura CISC richiede *PIU'* istruzioni per fare un certo programma? Secondo me è ora di riaprire quel libro di architettura degli elaboratori... ^____-____^


    > Forse questo in un
    > futuro non sara un problema, ma per ora lo
    > e'. Arm, StrongArm e Xscale permettono di
    > scrivere un programma usando molti meno k
    > dell'equivalente x86. Se prendi l'esempio
    > dei PDA ti rendi conto che riuscire a
    > risparmiare anche solo 2 Mb avendo a
    > disposizione una flash rom di 32 e'
    > abbastanza importante.
    >

    Ahhhh, volevi dire "richiede più memoria"... beh questo può essere, però non trasforma l'architettura x86 in uno schifo.


    non+autenticato

  • - Scritto da: Anonimo
    >
    > - Scritto da: Anonimo
    > >
    > > - Scritto da: Anonimo
    > > > e` come se per evolvere l`aereoplano
    > > > continuassero a modificare i biplani
    > >
    > > Peggio... x86 è meno che una bicicletta
    > con
    > > le ali posticce.
    >
    > Si si, e in base a cosa lo dici? Parlamo
    > ovviamente del 32bit, non del fatto che x86
    > ha anche la retrocompatibilità con il "real
    > mode" tramite l'istruzione apposita... cioè
    > voglio dire, sicuramente voi due mi saprete
    > spiegare che problemi dà il protected mode
    > di x86...
    >
    (non sono quello di sopra)
    Da dove vuoi che inizi?
    Dallo schifio dell'architettura CISC, dal fatto che la sua evoluzione in una anomala architettura ibrida dal P5 in su non ha fatto altro che introdurre bachi nel microcodice, oppure dal fatto che sulle macchine x86 i tempi di latenza sono da tartaruga?
    non+autenticato

  • > Da dove vuoi che inizi?
    > Dallo schifio dell'architettura CISC

    certo... come no! Si sa, è scritto in tutti i libri di architettura "il cisc fa schifo"... ma torna a studiare pure tu! Il cisc ha vantaggi e svantaggi proprio come il risc, se non ci credi prendi un libro tipo di vanneschi e leggilo.

    , dal
    > fatto che la sua evoluzione in una anomala
    > architettura ibrida dal P5 in su non ha
    > fatto altro che introdurre bachi nel
    > microcodice

    Interessante... quindi l'architettura x86 "fa schifo" perchè ci sono bug nel microcodice (quale? quello di intel, di cyrix, di amd?) e invece le altre architetture sono "intrinsecamente prive di bug" oppure cosa?

    Credo che la soluzione al problema bug sia la verifica formale, non certo il passaggio ad un'altra architettura. Ammesso che tu sappia di cosa stai parlando, cosa di cui dubito fortemente.

    >, oppure dal fatto che sulle
    > macchine x86 i tempi di latenza sono da
    > tartaruga?

    Ahahahaha. Complimenti adesso ci mostri un bel link con l'analisi della latenza di una "macchina x86" e si badi, i tempi di latenza lunghi devono essere dovuti all'architettura in se, non al singolo processore...
    non+autenticato
  • "...la lingua franca, secondo Weber, non può che essere x86."

    Alla faccia della portabilità....

    Che facciamo... torniamo indietro invece di avanzare?
    non+autenticato
  • - Scritto da: Anonimo

    > "...la lingua franca, secondo Weber, non può
    > che essere x86."
    >
    > Alla faccia della portabilità....
    >
    > Che facciamo... torniamo indietro invece di
    > avanzare?

    Ciascuno tira acqua al proprio mulino...
    Purtropo non ci leveremo AX,BX,CX,DX dalle
    palle ancora per un po'...

    non+autenticato