Intel ha smesso di sviluppare x86S, l'ISA totalmente a 64 bit: c'era da aspettarselo

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/cpu/in...lo_133997.html

Dopo la creazione dell'x86 Ecosystem Advisory Group con AMD, Intel ha deciso di mettere fine allo sviluppo di x86S, l'ISA totalmente a 64 bit che era giunta alla versione 1.2. L'impegno interno, ovviamente, mal si concilia con l'alleanza trasversale al settore.

Click sul link per visualizzare la notizia.

[gnappoman]

la più epica zappata sui piedi.. L'unico motivo per preferire x86 ad arm è sempre stato la retrocompatibilità...

[demon77]

Originariamente inviato da gnappoman

la più epica zappata sui piedi.. L'unico motivo per preferire x86 ad arm è sempre stato la retrocompatibilità...

mah.. non sono esperto in materia quindi magari dico stupidaggini..
ma io la trovavo una cosa molto sensata e non ritengo che questo avrebbe minato il mercato di x86.
Passare da x86 ad ARM vuol dire cambiare completamente parrocchia e cambiare il set di istruzioni, qui il discorso è ben diverso.
X86S altro non è che X86 ma scaricato di tutto il vecchio settore 16 e 32 bit favorendo quindi una riduzione di complessità del chip e dei consumi e dando maggiore spazio di sviluppo al settore 64bit che ormai è standard in tutti gli applicativi. Non si parla certo di dover ricompilare e riconvertire il parco software già in uso.
Si tenga poi conto che gli applicativi vecchi a 32 o addirittura 16bit non sono certo cose pesanti e possono andare in emulazione.

Leggere che il progetto è stato accantonato mi dispiace perchè lo ritengo tecnicamente valido.. e mi par di capire che il suo abbandono si basa su ragioni "politiche" piuttosto che su ragioni tecniche.

[supertigrotto]

Speriamo che il gruppo prenda spunto da X86S e che cominci a pensare al futuro dell' X86 perché così liberano silicio utile magari per altri ambiti,tipo npu

[r1348]

Avrebbe fatto la fine di Itanium, se non peggio.
Intel non ebbe la forza di imporre Itanium al mercato nei primi anni 2000, figuriamoci se ce l'avrebbe ora.
Tutto sommato è meglio così per i consumatori, non rischiamo di vedere imposta un architettura monopolista.

[Piedone1113]

Originariamente inviato da demon77

mah.. non sono esperto in materia quindi magari dico stupidaggini..
ma io la trovavo una cosa molto sensata e non ritengo che questo avrebbe minato il mercato di x86.
Passare da x86 ad ARM vuol dire cambiare completamente parrocchia e cambiare il set di istruzioni, qui il discorso è ben diverso.
X86S altro non è che X86 ma scaricato di tutto il vecchio settore 16 e 32 bit favorendo quindi una riduzione di complessità del chip e dei consumi e dando maggiore spazio di sviluppo al settore 64bit che ormai è standard in tutti gli applicativi. Non si parla certo di dover ricompilare e riconvertire il parco software già in uso.
Si tenga poi conto che gli applicativi vecchi a 32 o addirittura 16bit non sono certo cose pesanti e possono andare in emulazione.

Leggere che il progetto è stato accantonato mi dispiace perchè lo ritengo tecnicamente valido.. e mi par di capire che il suo abbandono si basa su ragioni "politiche" piuttosto che su ragioni tecniche.

Probabilmente x86/32/64 e x86/64 consisteranno per 3/4 anni .
Il fatto poi che nel consorzio ci sono nomi come Oracle, Microsoft, broadcom, redhat, non dovrebbe creare preoccupazioni software.
Per assurdo potrebbero vietare del tutto software a 16/32 bit che il 99% dei sistemi non avrebbe problemi a continuare a funzionare già oggi ( previo aggiornamento dell'os).
Tutte le routine 16/32 bit sono state scritte per girare su CPU almeno 100 volte più lente di adesso, anche in peggior emulatore non avrebbe problemi .
X86s dopo la nascita del consorzio non aveva nessuna ragione d'esistere ( come il corrispettivo ramo AMD).
Bloccarne lo sviluppo è soprattutto una questione pratica.
Intel avrebbe dovuto sviluppare due progetti del quale x86s destinato volente o nolente a non essere adottato:
Gli os server ( e non solo) avranno il supporto per l'architettura del consorzio perché Microsoft, redhat, broadcom, Google ne sono impegnati nello sviluppo, mentre i produttori hardware ne garantiranno l'impiego.
Alla luce di ciò chi fornirebbe il software o l'hardware per x86s?

[demon77]

Originariamente inviato da Piedone1113

Probabilmente x86/32/64 e x86/64 consisteranno per 3/4 anni .
Il fatto poi che nel consorzio ci sono nomi come Oracle, Microsoft, broadcom, redhat, non dovrebbe creare preoccupazioni software.
Per assurdo potrebbero vietare del tutto software a 16/32 bit che il 99% dei sistemi non avrebbe problemi a continuare a funzionare già oggi ( previo aggiornamento dell'os).
Tutte le routine 16/32 bit sono state scritte per girare su CPU almeno 100 volte più lente di adesso, anche in peggior emulatore non avrebbe problemi .
X86s dopo la nascita del consorzio non aveva nessuna ragione d'esistere ( come il corrispettivo ramo AMD).
Bloccarne lo sviluppo è soprattutto una questione pratica.
Intel avrebbe dovuto sviluppare due progetti del quale x86s destinato volente o nolente a non essere adottato:
Gli os server ( e non solo) avranno il supporto per l'architettura del consorzio perché Microsoft, redhat, broadcom, Google ne sono impegnati nello sviluppo, mentre i produttori hardware ne garantiranno l'impiego.
Alla luce di ciò chi fornirebbe il software o l'hardware per x86s?

Scusa non ho capito bene il discorso..
Ma quindi si intende pensionare e rimuovere in ogni caso la vecchia sezione per 16 e 32 bit continuando a chimare il tutto sempre X86?

[Piedone1113]

Originariamente inviato da demon77

Scusa non ho capito bene il discorso..
Ma quindi si intende pensionare e rimuovere in ogni caso la vecchia sezione per 16 e 32 bit continuando a chimare il tutto sempre X86?

Esatto:
Tutta la parte x86-64 sarà mantenuta, verranno tolte tutte le funzione a 16-32 bit in hardware che potrebbero essere emulate via software.
Se partiamo dal presupposto che ormai nessun software moderno ( scritto negli ultimi 10 anni) utilizza chiamate a 32 bit ( il 16 credo che non lo utilizzano da ben prima) possiamo capire che non è una cosa insormontabile.
La nuova versione x86 sarà solo a 64bit in hardware e comunque gia le attuali cpu hanno capacità elaborative tali da non avere nessun tipo di rallentamento se eseguono istruzioni 16 e 32 bit in emulazione software.
La nuova revisione deve sopratutto essere retrocompatibile con x86-64 e standardizzata in modo da offrire le stesse chiamati sia su cpu Intel che AMD ( facilitando la migrazione ).
Chi avrà problemi sono i vecchi sistemi industriali che ancora utilizzano chiamate dirette ( software a 32 bit, porte com, porte parallele ecc) per i quali i produttori devono comunque garantirne supporto futuro.
Senza cercare soluzioni esotiche ( macchine a controllo numerico datate) la maggiorparte degli sportelli bancomat utilizzano windows xp a 32 bit e questo dovrebbe far capire perchè non si può procedere senza una pianificazione e uno standard ben programmato e condiviso tra tutti gli attori ( produttori cpu, produttori software, produttori hardware)

[Gringo [ITF]]

Personalmente penso che Pulire il silicio dal vecchiume, ed emulare 16 e 32 bit non era una cattiva idea e magari così guadagnare un 15% di velocità e un 30% di spazio, ma si sà gli investitori chiedono dividendi per questo si taglia il futuro e si investe nel riciclare RAPTOR LAKE chiamandolo 200H senza ultra su socket nuovo.
COMPLIMENTI

Spero ci pensi AMD a svecchiare x86 visto che Intel ormai e totalmente alla frutta
avremo altri 10 anni senza investimenti ora.

[An.tani]

niente vieta di fare processori dove su un unico core si mantiene la compatibilità 16/32 e li altri vanno solo a 64bit

[the_joe]

Originariamente inviato da Gringo [ITF]

Personalmente penso che Pulire il silicio dal vecchiume, ed emulare 16 e 32 bit non era una cattiva idea e magari così guadagnare un 15% di velocità e un 30% di spazio, ma si sà gli investitori chiedono dividendi per questo si taglia il futuro e si investe nel riciclare RAPTOR LAKE chiamandolo 200H senza ultra su socket nuovo.
COMPLIMENTI

Spero ci pensi AMD a svecchiare x86 visto che Intel ormai e totalmente alla frutta
avremo altri 10 anni senza investimenti ora.

Sparare numeri a caso non porta mai a niente di buono, un processore moderno conta miliardi di transistor, un pentium nemmeno 5 milioni, lo spazio e la velocità guadagnati togliendo la compatibilità a 32bit sarebbe infimo, magari si semplificherebbe un po' il layout, ma per il resto sono inezie.

[An.tani]

Originariamente inviato da the_joe

Sparare numeri a caso non porta mai a niente di buono, un processore moderno conta miliardi di transistor, un pentium nemmeno 5 milioni, lo spazio e la velocità guadagnati togliendo la compatibilità a 32bit sarebbe infimo, magari si semplificherebbe un po' il layout, ma per il resto sono inezie.

beh insomma... il fatto che puoi progettare alcune parti critiche per le prestazioni della CPU (decoder, branch prediction, ooo execution, pipleine) senza tener conto della compatibilità col vecchiume credo possa avere un impatto non tanto sulle prestazioni ma sull' efficienza

IMHO questa non è una buona notizia per Intel: tagliare uno dei progetti più interessanti vuol dire che ormai sono in totale controllo danni con l’azienda in mano ai contabili...

non che tutto ciò sia inaspettato.... saranno stai 4 anni fa quando lessi un articolo di un ex insider intel in cui spiegava che l’eccessiva burocratizzazione, la divisione in caste dei dipendenti (intel vs società esterne) ed il fatto che a dettare la linea aziendale fosse il reparto marketing avrebbero condannato la società... ed in effetti

[the_joe]

Originariamente inviato da demon77

Scusa non ho capito bene il discorso..
Ma quindi si intende pensionare e rimuovere in ogni caso la vecchia sezione per 16 e 32 bit continuando a chimare il tutto sempre X86?

Originariamente inviato da Piedone1113

Esatto:
Tutta la parte x86-64 sarà mantenuta, verranno tolte tutte le funzione a 16-32 bit in hardware che potrebbero essere emulate via software.
Se partiamo dal presupposto che ormai nessun software moderno ( scritto negli ultimi 10 anni) utilizza chiamate a 32 bit ( il 16 credo che non lo utilizzano da ben prima) possiamo capire che non è una cosa insormontabile.
La nuova versione x86 sarà solo a 64bit in hardware e comunque gia le attuali cpu hanno capacità elaborative tali da non avere nessun tipo di rallentamento se eseguono istruzioni 16 e 32 bit in emulazione software.
La nuova revisione deve sopratutto essere retrocompatibile con x86-64 e standardizzata in modo da offrire le stesse chiamati sia su cpu Intel che AMD ( facilitando la migrazione ).
Chi avrà problemi sono i vecchi sistemi industriali che ancora utilizzano chiamate dirette ( software a 32 bit, porte com, porte parallele ecc) per i quali i produttori devono comunque garantirne supporto futuro.
Senza cercare soluzioni esotiche ( macchine a controllo numerico datate) la maggiorparte degli sportelli bancomat utilizzano windows xp a 32 bit e questo dovrebbe far capire perchè non si può procedere senza una pianificazione e uno standard ben programmato e condiviso tra tutti gli attori ( produttori cpu, produttori software, produttori hardware)

Originariamente inviato da An.tani

beh insomma... il fatto che puoi progettare alcune parti critiche per le prestazioni della CPU (decoder, branch prediction, ooo execution, pipleine) senza tener conto della compatibilità col vecchiume credo possa avere un impatto non tanto sulle prestazioni ma sull' efficienza

IMHO questa non è una buona notizia per Intel: tagliare uno dei progetti più interessanti vuol dire che ormai sono in totale controllo danni con l’azienda in mano ai contabili...

non che tutto ciò sia inaspettato.... saranno stai 4 anni fa quando lessi un articolo di un ex insider intel in cui spiegava che l’eccessiva burocratizzazione, la divisione in caste dei dipendenti (intel vs società esterne) ed il fatto che a dettare la linea aziendale fosse il reparto marketing avrebbero condannato la società... ed in effetti

Non è che Intel chiude, semplicemente spostano tutto sulla linea principale abbandonando il progetto laterale e alla fine il risultato sarà lo stesso.

[omerook]

Ma con i chiplet non potrebbero tranquillamente piazzare una cpu a solo 32bit ed una a solo 64bit sullo stesso Package e sviluppare le due cpu in modo indipendente mantenedo il massimo della compatibilità legacy?

[Gringo [ITF]]

Rosetta di Apple emula tranquillamente istruzioni a 32 e a 64 bit dell'architettura x86, non vedo le difficoltà nel snellire ed emulare le istruzioni a 32 e 16 bit sui core x64S ma e come parlare al bar, ormai la strada è scelta.
Reciclare il più possibile per Ottimizzare spacciando la Serie 14 sotto nome Core 200H (senza Ultra) sembrando pure migliori avendo l'HT attivo.
Pat avrà fatto cavolate ma questi vogliono tornare a dove erano rimasti prima del suo ritorno, DIVEDENDI ET IMPERA.... in attesa di venir superati anche da Xiaomi

[Piedone1113]

Originariamente inviato da the_joe

Sparare numeri a caso non porta mai a niente di buono, un processore moderno conta miliardi di transistor, un pentium nemmeno 5 milioni, lo spazio e la velocità guadagnati togliendo la compatibilità a 32bit sarebbe infimo, magari si semplificherebbe un po' il layout, ma per il resto sono inezie.

Su questo sono d'accordo, al massimo ridurrebbero lo spazio dello 0,5%.
Quello che Intel ( ed AMD) vorrebbe era una semplificazione dell'architettura con eliminazione di istruzioni similridondanti.
Praticamente in 50 anni di sviluppoci sono istruzioni che possono essere eseguite in modo più efficiente, ma per conservare la retrocompatibilità ( anche con codice a 64 bit scritto all'inizio del nuovo corso) si sono aggiunte istruzioni più efficienti, ma non sono state eliminate le vecchie causa incompatibilità con molto codice "moderno".
Un consorzio che permetta di utilizzare una strategia comune, con compilatori che tengono conto di un set d'istruzione comune alle cpu di entrambi i produttori, eviterebbe di implementare in Hardware anche set d'istruzioni ridondanti come ai tempi di sse vs 3dNow ( ma anche casi più recenti).
Questo si farebbe risparmiare spazio ed efficienza, non certo eliminare x32.

[djfix13]

già oggi le macchine a 64bit emulano il 32bit e negano il funzionamento nativo a 16bit... poi abbiamo voluto gli emulatori ma erano lenti così abbiamo virtualizzato e avuto accesso diretto alla CPU quindi di fatto siamo sempre lì... volgliamo continuare ad eseguire tutto il software possibile su una CPU che supporti tutto.

[fabius21]

Ma sicuro che l'ambito sia solo nelle istruzioni?
Perchè se non ricordo male una volta lessi, che per passare only 64, poi anche le tutte le periferiche devono avere il loro firmware compatibile only64.
Forse starò mischiando più di qualcosa?

[tuttodigitale]

Originariamente inviato da An.tani

beh insomma... il fatto che puoi progettare alcune parti critiche per le prestazioni della CPU (decoder, branch prediction, ooo execution, pipleine) senza tener conto della compatibilità col vecchiume credo possa avere un impatto non tanto sulle prestazioni ma sull' efficienza

IMHO questa non è una buona notizia per Intel: tagliare uno dei progetti più interessanti vuol dire che ormai sono in totale controllo danni con l’azienda in mano ai contabili...

non che tutto ciò sia inaspettato.... saranno stai 4 anni fa quando lessi un articolo di un ex insider intel in cui spiegava che l’eccessiva burocratizzazione, la divisione in caste dei dipendenti (intel vs società esterne) ed il fatto che a dettare la linea aziendale fosse il reparto marketing avrebbero condannato la società... ed in effetti

Premesso che ad una fase di decodifica complessa viene compensata in parte dalla ridotta occupazione in memoria delle istruzioni x86, e quindi un relativo aumento della banda "efficace" della cache non ci sono solo svantaggi. Dall'altro credo che sono da ormai 20 anni che le CPU x86 trasformino le istruzioni in Risc (microop) e trasformandole in un microop fusion , in una istruzione CISC. e all'occorrenza recuperarle nella cosiddetta L0....

Uno snellimento permetterebbe di ampliare anche i numeri di registri senza ulteriori costi, ma credo che innanzitutto i tecnici di Intel si siano resi conto che i contro apparentemente minimi, non sono compensati da chissà quali aumenti di performance oefficienza