Link alla notizia: https://www.hwupgrade.it/news/cpu/x86s-intel-pensa-a-un-architettura-totalmente-a-64-bit_116937.html

In casa Intel stanno pensando se non sia finalmente giunta l'ora di passare a un'architettura x86 totalmente a 64 bit, priva di alcune funzionalità per il supporto al codice a 16 e 32 bit. La nuova idea prende il nome di X86S.

Click sul link per visualizzare la notizia.

128 no?

I 16 è bene toglierli, il 32bit dovranno essere ancora presenti per un bel pezzo, putroppo.

Ecco un altro "ecosistema" :D cioè "i nostri clienti hanno bisogno di un motivo per spendere"

Oggi la compatibilità con il passato è il motivo principale per continuare a scegliere x86/x64 come architettura, visto che ARM ha diversi vantaggi prestazionali ed energetici.
Certo questo x86S potrebbe diventare concorrenziale con ARM seppur relegando il mondo dei software legacy all'emulazione...

Forse chiamerei questa architettura in modo diverso: solo aggiungere S a x86 potrebbe creare confuzione....

128 no?

una cpu a 128bit ha solo svantaggi rispetto una a 64bit non la vedremo per decenni o forse di piu

Il discorso di intel lo trovo molto sensato, migliorerebbe efficienza e prestazioni dei processori non doversi trascinare tutta una parte legacy delle vecchie architetture.

I 16 è bene toglierli, il 32bit dovranno essere ancora presenti per un bel pezzo, putroppo.

Domanda.. ma considerando che già da un pezzo tutti i software pesanti sono a 64bit e quelli rimasti a 32 sono per lo più robetta.. non si protebbe semplicemente emulare il loro ambiente di lavoro?

Oggi la compatibilità con il passato è il motivo principale per continuare a scegliere x86/x64 come architettura, visto che ARM ha diversi vantaggi prestazionali ed energetici.
Certo questo x86S potrebbe diventare concorrenziale con ARM seppur relegando il mondo dei software legacy all'emulazione...

Forse chiamerei questa architettura in modo diverso: solo aggiungere S a x86 potrebbe creare confuzione....

quoto tutto.

Ho appena verificato ed il gestionale in azienda ha client a 32bit.
Citrix installato è a 32bit.
Ho win10pro 64bit ma Onedrive è a 32bit....
I 32bit SERVONO... e serviranno ancora per molto tempo.

Ho appena verificato ed il gestionale in azienda ha client a 32bit.
Citrix installato è a 32bit.
Ho win10pro 64bit ma Onedrive è a 32bit....
I 32bit SERVONO... e serviranno ancora per molto tempo.

Che in giro ci siano ancora moltissimi applicativi 32bit è palese.. ma non è che richiedano potenza elevata.
Abbiamo CPU da millemila cores.. non credo sia un problema spendere un po' di potenza extra per emulare le app 32bit. Di certo non noterai differenze a livello di prestazioni.

PS: si tenga poi conto che un sacco di tools ed applicativi lasciati a 32 bit possono pure essere convertiti

Ho appena verificato ed il gestionale in azienda ha client a 32bit.
Citrix installato è a 32bit.
Ho win10pro 64bit ma Onedrive è a 32bit....
I 32bit SERVONO... e serviranno ancora per molto tempo.

io onedrive ce l'ho installato a 64 bit, quindi sarebbe un problema limitato..

gli unici applicativi installati sul mio pc a 32 bit sono la vpn e il proxy (per entrambi c'è la versione a 64 bit, immagino sia solo un questione di scelte IT che abbiamo la 32bit)... tutto il resto mi sta girando a 64 bit (teams, office, chrome, edge, cad/cae)

quindi se facessero una cpu che dimezza i consumi la prenderei domani :D

bio

In cosa consiste il vantaggio di una cpu a 64 bit che fa solo il 64 bit, rispetto a una a 64 che fa tutto come avviene attualmente?

Cioè per ogni cosa serve l'hardware specifico, stiamo tornando agli anni 60

Se l'emulazione software riesce a sopperire e la miglior cosa che possano fare, semplificare per il futuro, ormai x86 è ai suoi limiti e trascinarsi dietro tutto lo schema evolutivo è solo carico in più sulla progettazione del silicio.
Emulare per compatibilità un software a 16 bit o a 32 bit si possono avere delle perdite prestazionali ma alla fine è per usare software obsoleti ormai che risalgono a oltre 15 anni fà, e stimola a riscrivere alcuni software che non si aggiornano solo per puro lucro e pigrizia.

In cosa consiste il vantaggio di una cpu a 64 bit che fa solo il 64 bit, rispetto a una a 64 che fa tutto come avviene attualmente?

Cioè per ogni cosa serve l'hardware specifico, stiamo tornando agli anni 60

La cpu che adesso "fa tutto" lo fa perchè ha parti dedicate a lavorare a 32 bit oltre che a 64. A livello hardware proprio.
Capisci bene che tutto questo hardware extra da trascinarsi per la retrocompatibilità influisce su prestazioni e consumi di ogni singolo core delle moderne CPU.

Quindi se fai una CPU dove i cores sono solo 64bit puri hai un motevole risparmio in termini di complessità e di conseguenza hai minori consumi a fronte di maggiori prestazioni.

Il rovescio della medaglia è che non hai più supporto hardware nativo per i software 32bit.. ma è uno svantaggio minimo perchè si possono emulare.

Il rovescio della medaglia è che non hai più supporto hardware nativo per i software 32bit.. ma è uno svantaggio minimo perchè si possono emulare.

Oltre al fatto che si possono emulare, non sarebbe poi uno Scandalo se quei "pochi" software a 32 bit venissero (ri)fatti a 64bit.
Non stiamo proprio parlando dell ultimo ritrovato di tecnologia...

Se questo serve per semplificare l'architettura interna ci può stare,visto che con l'emulazione si potrebbe fare girare anche software creato per l'8 bit,quindi con un bel risparmio di silicio e prestazioni più elevate direi.
Oppure si potrebbe relegare il tutto a dei co processori,come si faceva una volta con il matematico dei primi 386.
8 e 16 bit sarebbero utili solo per un discorso di IA (a detta della IBM) o come microcontrollori in stile Arduino anche se si è passati ai 32 bit pure nei microcontrollori.
A livello generale,in effetti un x86 a 16/32 bit ha poco senso,per il semplice fatto che con le frequenze e gli IPC attuali,emulare il 16/32 porterebbe via solo poche percentuali di performance,a livello specialistico,forse i mainframe ne risentirebbero,e dico forse.

Forse dico una castronata, ma su Windows 64bit i programmi a 32bit non vengono già emulati? In teoria Windows ha integrato l'emulatore WOW64 x86, che in modo trasparente esegue le applicazioni legacy; al processore arriva sempre e solo codice a 64bit credo.

Qualcuno competente può confermare o smentire?

Forse dico una castronata, ma su Windows 64bit i programmi a 32bit non vengono già emulati? In teoria Windows ha integrato l'emulatore WOW64 x86, che in modo trasparente esegue le applicazioni legacy; al processore arriva sempre e solo codice a 64bit credo.

Qualcuno competente può confermare o smentire?

Beh si, non fosse altro che a 32 bit non puoi indirizzare più di 3,5 gb di ram, solo il fatto di usarla implica che sei nativo 64 bit, ed emuli 32 bit
Infatti a 64 bit non puoi emulare i 16, che a 32 bit si possono emulare

Forse dico una castronata, ma su Windows 64bit i programmi a 32bit non vengono già emulati? In teoria Windows ha integrato l'emulatore WOW64 x86, che in modo trasparente esegue le applicazioni legacy; al processore arriva sempre e solo codice a 64bit credo.

Qualcuno competente può confermare o smentire?

L’esecuzione dei binari non è emulata, è nativa sul processore.
WOW64 non è una cosa tipo Rosetta di Apple, o anche l’esecuzione dei binari x86-64 nelle versioni ARM di Windows, che sono invece la soluzione necessaria nell’ipotesi di questi processori non retrocompatibili IA32.

Beh si, non fosse altro che a 32 bit non puoi indirizzare più di 3,5 gb di ram, solo il fatto di usarla implica che sei nativo 64 bit, ed emuli 32 bit
Infatti a 64 bit non puoi emulare i 16, che a 32 bit si possono emulare

In Windows NT i processi a 32 bit sono limitati a 2^31-1 (2GB -1 byte), per mappare più RAM senza passare ai 64 bit occorrono le PAE o le pagine legge di memoria… roba che effettivamente era tornata di attualità 20 anni fa.

I processori x86 quando avviati in modalità a 64 bit possono eseguire binari a 32 o 64 bit, ma non a 16. Scelta di AMD quando inventarono questa nuova versione dell’ISA, di lasciarsi indietro il passato 16 bit.
Poi ovviamente in Intel qualcuno ha la faccia come il culo e vengono a parlaci di Intel64 :fagiano:

Trovo strano che nessuno abbia ancora ricordato che ancora prima di passare alle Intel64 AMD64 intel aveva già sviluppato una ISA 64bit pura che però non ha avuto molta fortuna sul mercato, parlo ovviamente di Itanium\i-64 (https://it.wikipedia.org/wiki/Itanium)

Per quanto riguarda wow64 invece segnalo questo paragrafo da wikipedia (https://it.wikipedia.org/wiki/WOW64):

Architetture
Malgrado le apparenti somiglianze con tutte le versioni a 64 bit di Windows, l'implementazione di Wow64 varia in base all'architettura del processore. Per esempio, la versione di Windows a 64 bit sviluppata per i processori Intel Itanium 2 usa la DLL "Wow64win.dll" per l'emulazione delle istruzioni x86 dentro il set unico di istruzioni di Itanium 2. Questo processo è più costoso in termini di calcolo delle funzioni di Wow64win.dll rispetto all'architettura AMD64/EMT64, dato che cambia il processore dalla modalità a 64 bit a quella a 32 quando è il momento di eseguire un thread a 32 bit, e poi lo ricambia nella modalità a 64 bit. Per WOW64 non è richiesta alcuna emulazione di istruzioni su processori AMD64 ed EMT64

Ora chi mi conosce sa quanto sia ignorante in materia, quindi non stupitevi se scrivo corbellerie, però mi pare di ricordare che persone più esperte di me parlassero del fatto che in realtà le parti a 32bit non è che poi incidano così tanto in una cpu moderna, e che quindi di per se non è che elimnarle farebbe una differenza enorme, inoltre visto che qui si parla comunque di una ISA totalmente diversa siamo certi che non servirebbe l'emulazione anche per eseguire l'attuale codice a 64 bit per AMD64\EMT64?

1) quanto sarebbe questo vantaggio % eliminando la parte 32bit? se parliamo del 10% direi chissenefrega. Il buono di win è la (retro)compatibilità, altrimenti c'è arm che è ben più efficiente...

2) ora che intel (ma anche amd) sta introducento l'arch big.little, non potrebbero lasciare gli E-core 32bit compatibili e i P-core 64bit puri?

3) i programmi dos erano a 16 o 32 bit? se è vero che i 16bit non sono più eseguibili, perchè ho visto funzionare ancora vecchi programmi scritti per dos? (non solo quelli in firma, anche roba di contabilità o simile). E Dosbox come funziona?

Trovo strano che nessuno abbia ancora ricordato che ancora prima di passare alle Intel64 AMD64 intel aveva già sviluppato una ISA 64bit pura che però non ha avuto molta fortuna sul mercato, parlo ovviamente di Itanium\i-64 (https://it.wikipedia.org/wiki/Itanium)

Verissimo. Ma Itanium era ben altro progetto.. non ha mai mirato al desktop o ai piccoli server, anche perchè ai tempi tutto era ben piantato sui 32bit.
Le mire di Itanium erano quelle dei supercomputer dove c'erano le cpu di SUN.
Un terreno tosto.. non gli è andata benissimo.

La cpu che adesso "fa tutto" lo fa perchè ha parti dedicate a lavorare a 32 bit oltre che a 64. A livello hardware proprio.
Capisci bene che tutto questo hardware extra da trascinarsi per la retrocompatibilità influisce su prestazioni e consumi di ogni singolo core delle moderne CPU.

Quindi se fai una CPU dove i cores sono solo 64bit puri hai un motevole risparmio in termini di complessità e di conseguenza hai minori consumi a fronte di maggiori prestazioni.

Il rovescio della medaglia è che non hai più supporto hardware nativo per i software 32bit.. ma è uno svantaggio minimo perchè si possono emulare.

Attenzione che si parla solo di rimuovere il supporto ai SO a 32 bit, non al sw a 32 bit in user space. In pratica una CPU così non potrebbe avviare in modo nativo un sistema operativo a 32 bit, cosa che adesso tutte le CPU AMD64 compatibili possono fare in Legacy Mode. I sistemi operativi a 32 bit potrebbero essere ancora eseguiti solo in virtualizzazione, ma per gli applicativi a 32 bit non cambierebbe nulla.

In questo senso l'aricolo è sbagliato:
il supporto ad applicazioni a sistemi operativi non a 64 bit potrebbe avvenire tramite virtualizzazione

Attenzione che si parla solo di rimuovere il supporto ai SO a 32 bit, non al sw a 32 bit in user space. In pratica una CPU così non potrebbe avviare in modo nativo un sistema operativo a 32 bit, cosa che adesso tutte le CPU AMD64 compatibili possono fare in Legacy Mode. I sistemi operativi a 32 bit potrebbero essere ancora eseguiti solo in virtualizzazione, ma per gli applicativi a 32 bit non cambierebbe nulla.

Ah si? Sicuro di sta cosa?
no perchè se le cose stessero così sta mossa si poteva fare ANNI FA. :mbe:

Ah si? Sicuro di sta cosa?
Sì.

To further clarify, 32-bit x86 user-space software would continue to work on modern 64-bit operating systems with X86-S

https://www.phoronix.com/news/Intel-X86-S-64-bit-Only

Sì.

To further clarify, 32-bit x86 user-space software would continue to work on modern 64-bit operating systems with X86-S

https://www.phoronix.com/news/Intel-X86-S-64-bit-Only

Direi che a questo punto ci sono solo ragioni per fare questa cosa e praticamente nessuna per non farla... :stordita:

Direi che a questo punto ci sono solo ragioni per fare questa cosa e praticamente nessuna per non farla... :stordita:

Non è proprio così, tutto verebbe mappato a 64Bit compreso BUS PCI-E che è come avesse di "Default" attivato l'Above 4G" senza possibilità di Disabilitarlo, ci sarebbe in pratica un buon 50% di periferiche che senza un aggiornamento del Firmware di queste periferiche, smetterebbero di esser mappate, oltre a sparire tutti quei adattatori tipo PCI su PCI-E ecc...
Il software sarebbe emulabile al 99,9%
le periferiche vecchie, tipo la schedina per usare drive ATAPI o FLOPPY alcune schede video e audio, potrebbero non funzionare, perchè nessuno ci aggiornerebbe il Firmware Interno.
Non è semplice ma la mossa va fatta, eliminare un 30% di superficie del silicio e poter abilitare ottimizzazioni ora impossibili porterebbe x86S a poter competere anche con ARM e POWER-V, lo renderebbe un processore "moderno".

;48205070']Non è proprio così, tutto verebbe mappato a 64Bit compreso BUS PCI-E che è come avesse di "Default" attivato l'Above 4G" senza possibilità di Disabilitarlo, ci sarebbe in pratica un buon 50% di periferiche che senza un aggiornamento del Firmware di queste periferiche, smetterebbero di esser mappate, oltre a sparire tutti quei adattatori tipo PCI su PCI-E ecc...
Il software sarebbe emulabile al 99,9%
le periferiche vecchie, tipo la schedina per usare drive ATAPI o FLOPPY alcune schede video e audio, potrebbero non funzionare, perchè nessuno ci aggiornerebbe il Firmware Interno.
Non è semplice ma la mossa va fatta, eliminare un 30% di superficie del silicio e poter abilitare ottimizzazioni ora impossibili porterebbe x86S a poter competere anche con ARM e POWER-V, lo renderebbe un processore "moderno".

Sull'hardware non ho idea. Non mi ero neanche posto il problema a dire il vero.
C'è pure da dire che se perliamo di hardware super datato è pure un problema relativo.

Tipico esempio:
Ho una scheda PCI-E 4x che uso per un Plextor Premium e un PX-760, quella fa anche il boot e va in modalità Legacy, se attivi nel mio caso attivando Above 4G (Bus PCI-E gestito con indirizzi a 64Bit) smette di funzionare lei e anche la scheda video, ma il PC funziona benissimo infatti accedendo in remoto vedo i due punti esclamativi, questo perchè la "Vecchia Scheda" và in conflitto con l'indirizzamento a 64 bit, ma sono situazioni talmente di nicchia che avrei risolto anche con sue adattatori USB-IDE ma preferivo avere tutto dentro al box.

Comunque dopo il Lancio escono sempre soluzioni "Adattative", quindi avanti così!

;48205070']Non è proprio così, tutto verebbe mappato a 64Bit compreso BUS PCI-E che è come avesse di "Default" attivato l'Above 4G" senza possibilità di Disabilitarlo, ci sarebbe in pratica un buon 50% di periferiche che senza un aggiornamento del Firmware di queste periferiche, smetterebbero di esser mappate, oltre a sparire tutti quei adattatori tipo PCI su PCI-E ecc...
Il software sarebbe emulabile al 99,9%
le periferiche vecchie, tipo la schedina per usare drive ATAPI o FLOPPY alcune schede video e audio, potrebbero non funzionare, perchè nessuno ci aggiornerebbe il Firmware Interno.
Non è semplice ma la mossa va fatta, eliminare un 30% di superficie del silicio e poter abilitare ottimizzazioni ora impossibili porterebbe x86S a poter competere anche con ARM e POWER-V, lo renderebbe un processore "moderno".

I driver fanno parte dello SO, per cui sono già a 64 bit. E se parliamo di software che si interfaccia bus PCI, driver per floppy.. stiamo parlando di driver.

L'annuncio di Intel scende nei dettagli, ma in sostanza se si ha già un SO a 64 bit che parte con l'uefi ... non c'è impatto.



Forse c'è da verificare i firmware di alcune schede (p.e. quelle video), credo che anche quelle eufi compatibili (senza bisogno del CSM) potrebbero essere scritte a 32 bit

I driver fanno parte dello SO, per cui sono già a 64 bit. E se parliamo di software che si interfaccia bus PCI, driver per floppy.. stiamo parlando di driver.

L'annuncio di Intel scende nei dettagli, ma in sostanza se si ha già un SO a 64 bit che parte con l'uefi ... non c'è impatto.



Forse c'è da verificare i firmware di alcune schede (p.e. quelle video), credo che anche quelle eufi compatibili (senza bisogno del CSM) potrebbero essere scritte a 32 bit

Driver è una cosa e Mappatura degli indirizzi del PCI-E a 64 bit è un altra, te lo dico perchè dovevo fare alcune cose in cui mi serviva utilizzare il BUS PCI-E senza la compatibilità Legacy ed il risultato e stato blocco della macchina e non per Assenza di driver ma perchè le schede non sono compatibili con un BUS a 64Bit puri senza le "Opzioni" Legacy, se vuoi se hai una scheda madre "Server" moderna trovi come farla lavorare a 64Bit puri e li scopri quante schede smettono di funzionare perchè NON MAPPABILI non potendo ricevere dati dal BUS su tutto il range 64Bit, e come avere un bicchiere da mezzo litro e ci butti un litro d'acqua.... metà dati vanno persi su quelle schede, e non c'è driver che tenga, se non riscrivere il firmware e non è sempre risolvibile.
Una stringa a 32Bit può starci su un bus a 64bit .... ma non il contrario.
e l'hardware non è emulabile.

Cerca queste voci nel Bios:
above 4G decoding
Re-Size Bar support
CSM support
Disabilita il Legacy e Attiva tutto a 64 bit..... 50% dei PC con hardware premontato non troppo recenti si inchioderà, e non centrano i driver...
Semplicemente invii tutto a 64 bit.... e tutto quello impostato a ricevere a 32 fa KAPUT.

vmware workstation è, almeno in parte, a 32 bit... :D

usiamo un attimo la logica : se intel farà diventare realtà questa cosa ipotizzo che sarà relegata solo da win11 a salire se non direttamente solo da win12, inoltre credo che la logica porti a capire che un passaggio del genere non sarà universale su tutte le fasce perchè appunto in campo industriale ci sono certi campi dove purtroppo serve il 32bit fisico e non emulato via software, detto questo a mio modesto parere sarebbe una cosa auspicabile perchè come arm abbia iniziato a mostrare il fianco al complicarsi dell'architettura tanto che le ultime generazioni per avanzare in performance hanno iniziato anche loro a tagliare compatibilità legacy, è fisiologico in questi casi, senza contare che adesso con le architetture ibride non è da fantascienza pensare ad una parte di core solo x86s e un'altra parte con i core x86/64 che hanno ancora in hw le 32bit, oppure una parte di core x86s e un'altra con core sempre base x86s ma magari ottimizzati per l'emulazione dei 32bit, per poi man mano che anche i software si adeguano con gli update, eliminare anche l'emulazione 32bit

usiamo un attimo la logica : se intel farà diventare realtà questa cosa ipotizzo che sarà relegata solo da win11 a salire se non direttamente solo da win12, inoltre credo che la logica porti a capire che un passaggio del genere non sarà universale su tutte le fasce perchè appunto in campo industriale ci sono certi campi dove purtroppo serve il 32bit fisico e non emulato via software, detto questo a mio modesto parere sarebbe una cosa auspicabile perchè come arm abbia iniziato a mostrare il fianco al complicarsi dell'architettura tanto che le ultime generazioni per avanzare in performance hanno iniziato anche loro a tagliare compatibilità legacy, è fisiologico in questi casi, senza contare che adesso con le architetture ibride non è da fantascienza pensare ad una parte di core solo x86s e un'altra parte con i core x86/64 che hanno ancora in hw le 32bit, oppure una parte di core x86s e un'altra con core sempre base x86s ma magari ottimizzati per l'emulazione dei 32bit, per poi man mano che anche i software si adeguano con gli update, eliminare anche l'emulazione 32bit

Non penso sia fattibile :stordita: (riguardo i core little e big)
Almeno se ieri ho capito bene leggendo il thread su phoronix
Cmq si sarebbe ora da rivedere un attimino la revisione degli x86, anche se le problematiche hw possono essere un grattacapo

Non penso sia fattibile :stordita: (riguardo i core little e big)
Almeno se ieri ho capito bene leggendo il thread su phoronix
Cmq si sarebbe ora da rivedere un attimino la revisione degli x86, anche se le problematiche hw possono essere un grattacapo

Non c'è nessun grattacapo:
Un x86-64s è un'ottima cosa ( sono gia due anni che se ne parlava nei corridoi intel ed AMD ) e non porteranno nessun problema:
Quando uscirono gli I64 intel ha continuato a produrre cpu a 32 bit pure per diverso tempo.
Se qualcuno ha bisogno di retrocompatibilità ( rinunciando a prestazioni e consumi) ci saranno per diverso tempo cpu AMD64/I64.
Per chi non ha questi vincoli si andrà di 64S.
Il periodo di transizione può durare anche 10 anni ( se pensiamo che i 64 bit home si sono usati in modo diffuso solo 5 anni dopo l'uscita delle cpu x86-64) ma maggiore sarà il vantaggio della nuova architettura più breve sarà la transizione.

Finalmente una presa di posizione coraggiosa e necessaria da parte di Intel!!
I 16 bit appartengo ad una era geologica fa ( 8088 - 8086 - 80286 ) ed i 32 bit li stanno seguendo a ruota visto che le estensioni a 64 bit per x86 sono arrivate sul mercato dei pc desktop esattamente 20 anni fa ( Athlon 64 - 18/05/2003 ).
A che pro portarsi ancora dietro questo fardello sulle spalle? Capisco la compatibilità verso il basso ma dopo 20 anni è ora di chiudere con un passato che non avrà sempre più importanza nel futuro prossimo.

;48205326']Driver è una cosa e Mappatura degli indirizzi del PCI-E a 64 bit è un altra
[...]
Cerca queste voci nel Bios:
above 4G decoding
Re-Size Bar support
CSM support
Disabilita il Legacy e Attiva tutto a 64 bit.

Nessuna di queste voci (a parte il CSM) dipende dalla compatibilità del processore con il "vecchio" instruction set a 32 bit.

Per lo più sono opzioni per mappare le periferiche PCI; è vero che alcune periferiche non funzionano se mappate ad indirizzi alti (e non stiamo parlando solo del limite dei 2/4GB, se ben ricordo alcune vecchia schede avevano già problemi superati i 16MB), ma questo succede già ora con gli attuali x86-64 con supporto pieno ai 32 bit.

Inoltre anche avendo un processore solo a 64bit, nulla impedisce di forzare la mappatura nella regione bassa di memoria: si tratta solo di configurare il bus pci opportunatamente.

Discorso a parte CSM: ogni scheda (p.e.) video avente bios che richiede la "modalità reale", non funzionerà (salvo implementare a livello di UEFI un interprete real mode<->long mode), per cui il CSM non sarebbe funzionale.

Finalmente una presa di posizione coraggiosa e necessaria da parte di Intel!!
I 16 bit appartengo ad una era geologica fa ( 8088 - 8086 - 80286 ) ed i 32 bit li stanno seguendo a ruota visto che le estensioni a 64 bit per x86 sono arrivate sul mercato dei pc desktop esattamente 20 anni fa ( Athlon 64 - 18/05/2003 ).
A che pro portarsi ancora dietro questo fardello sulle spalle? Capisco la compatibilità verso il basso ma dopo 20 anni è ora di chiudere con un passato che non avrà sempre più importanza nel futuro prossimo.

Tra l'altro si parlò già ai tempi dei primissimi Athlon64 di come il passaggio da 16 a 32 fosse stato piuttosto semplice ed indolore mentre invece il passaggio da 32 a 64 fosse molto più oneroso e complicato..

Tra l'altro si parlò già ai tempi dei primissimi Athlon64 di come il passaggio da 16 a 32 fosse stato piuttosto semplice ed indolore mentre invece il passaggio da 32 a 64 fosse molto più oneroso e complicato..

Non ricordo così indolore il passaggio dai 16 ai 32 bit. Probabilmente il passaggio fu molto veloce perché il vantaggio era notevole: si passava da un ambiente quasi-monotasking con grafica non eccezionale ad un ambiente full 32bit realmente multitasking e con l'avvento di internet.

Non tutte queste cose sono legate, ma sono coincise sia temporalmente sia con il salto ai processori a 32 bit sia con l'avvento di windows 95.

Di fatto per la maggioranza delle persone, il passaggi da 32 a 64 bit non ha portato molti vantaggi.

Non ricordo così indolore il passaggio dai 16 ai 32 bit. Probabilmente il passaggio fu molto veloce perché il vantaggio era notevole: si passava da un ambiente quasi-monotasking con grafica non eccezionale ad un ambiente full 32bit realmente multitasking e con l'avvento di internet.

Non tutte queste cose sono legate, ma sono coincise sia temporalmente sia con il salto ai processori a 32 bit sia con l'avvento di windows 95.

Di fatto per la maggioranza delle persone, il passaggi da 32 a 64 bit non ha portato molti vantaggi.


mica tanto.
il primo windows a supportare i 32 bit è stata la versione 2.0; si chiamava windows 386.
già la versione 3.x, se trovava un processore 32 bit, si avviava in tal senso e la modalità a 16 bit andava forzata.

windows95 è stato il primo a non supportare la modalità 16 bit (ma eseguiva i programmi a 16 e accettava, con qualche limite, i driver)

Non ricordo così indolore il passaggio dai 16 ai 32 bit. Probabilmente il passaggio fu molto veloce perché il vantaggio era notevole: si passava da un ambiente quasi-monotasking con grafica non eccezionale ad un ambiente full 32bit realmente multitasking e con l'avvento di internet.

Non tutte queste cose sono legate, ma sono coincise sia temporalmente sia con il salto ai processori a 32 bit sia con l'avvento di windows 95.

Di fatto per la maggioranza delle persone, il passaggi da 32 a 64 bit non ha portato molti vantaggi.

In effetti in quegli anni la crescita delle performance delle CPU rendeva un PC top di gamma un ferro vecchio in meno di cinque anni.
Con l'arrivo delle nuove CPU a 32 bit i vecchi 16bit non reggevano il confronto neanche da lontano e l'arrivo di win95 ha cestinato il vecchio DOS in pochissmo tempo

Non ricordo così indolore il passaggio dai 16 ai 32 bit. Probabilmente il passaggio fu molto veloce perché il vantaggio era notevole: si passava da un ambiente quasi-monotasking con grafica non eccezionale ad un ambiente full 32bit realmente multitasking e con l'avvento di internet.

Non tutte queste cose sono legate, ma sono coincise sia temporalmente sia con il salto ai processori a 32 bit sia con l'avvento di windows 95.

Di fatto per la maggioranza delle persone, il passaggi da 32 a 64 bit non ha portato molti vantaggi.

I 32 bit erano supportati giù da Windows 3.1/3.11... Il mio primo 486 ( DX 33 ) lanciava Windows a 32 bit di default. Anche se non erano i 32 bit reali di Windows NT soprattutto per la gestione della memoria.

Il vantaggio più grande del passaggio dai 32 ai 64 bit è stata la possibilità di poter sfruttare quantitativi di memoria sempre più grandi: 16 anni fa circa la dotazione Ram standard era di 1GB, oggi il minimo sindacale sono 8GB.

In effetti in quegli anni la crescita delle performance delle CPU rendeva un PC top di gamma un ferro vecchio in meno di cinque anni.
Con l'arrivo delle nuove CPU a 32 bit i vecchi 16bit non reggevano il confronto neanche da lontano e l'arrivo di win95 ha cestinato il vecchio DOS in pochissmo tempo

Poco più di 5 anni... Il vero " killer " del DOS fu Windows XP basato su NT ed integralmente a 32 bit.

Poco più di 5 anni... Il vero " killer " del DOS fu Windows XP basato su NT ed integralmente a 32 bit.

Allora direi WINDOWS 2000. Xp è arrivato dopo.

Allora direi WINDOWS 2000. Xp è arrivato dopo.

Windows 2000 è stata l'evoluzione di NT ed era riservato agli utenti professionali; infatti non aveva nessun tipo di supporto al multimedia.
Xp è stato il vero debutto dei 32 bit per tutti!!

Windows 2000 è stata l'evoluzione di NT ed era riservato agli utenti professionali; infatti non aveva nessun tipo di supporto al multimedia.
Xp è stato il vero debutto dei 32 bit per tutti!!

No no!
Windows 2000 era evoluzione diretta di NT4 ma aveva pieno supporto a multimedia e directX a differenza appunto di NT4.
Motivo per cui poteva essere utilizzato senza problemi al posto di win98.

Ci giravano giochi e tutto.
Te lo dico per certo perchè ai tempi lo ho usato come sistema principale e devo dire con grande soddisfazione! :)
Uno dei migliori sistemi di MS a mio parere.

No no!
Windows 2000 era evoluzione diretta di NT4 ma aveva pieno supporto a multimedia e directX a differenza appunto di NT4.
Motivo per cui poteva essere utilizzato senza problemi al posto di win98.

Ci giravano giochi e tutto.
Te lo dico per certo perchè ai tempi lo ho usato come sistema principale e devo dire con grande soddisfazione! :)
Uno dei migliori sistemi di MS a mio parere.

VERO !!
Difatti lo usavo al tempo a casa pure sul pc gaming, e per parecchi anni anche.
Lo ricordo mooolto più stabile anche dell'XP, cui sono passato solo dopo vari anni dalla sua uscita causa incompatibilità dei vari programmi col 2000 sempre maggiori :cry:

Mi sembra di ricordare però, che anche win98 era basato sul dos. :rolleyes:
L'ho usato poco perchè all'epoca passai dal 8088 al dual-p2 , percui non installai il 98 e/o usato poco, perchè non gestiva il dual processor

Mi sembra di ricordare però, che anche win98 era basato sul dos. :rolleyes:
L'ho usato poco perchè all'epoca passai dal 8088 al dual-p2 , percui non installai il 98 e/o usato poco, perchè non gestiva il dual processor

VERO.
Win 95 fino al 98 (anzi fino ad ME ma quello non lo conteggio nemmeno) erano basati su una versione avanzata del vecchio DOS.

Si, tanto è che, effettuando una qualche modifica in un file di sistema - credo Msdos.Sys - la GUI non si avvia. Si può poi fare manualmente con comando "Win". Lo facevo vent'anni fa per motivi di retrogaming !

Si, tanto è che, effettuando una qualche modifica in un file di sistema - credo Msdos.Sys - la GUI non si avvia. Si può poi fare manualmente con comando "Win". Lo facevo vent'anni fa per motivi di retrogaming !

se ricordo bene, f8 durante l'avvio e si apriva il menù con cui nn facevi avviare la gui
msdos.sys era un binario, se non ricordo male, però ricordo che c'era un file che si poteva editare, è passato un quarto di secolo ormai. Forse config.sys

Edit: per curiosità son andato a cercare e si , era config.sys, l'estensione ti ha giocato un brutto scherzo :D

Abbiate pazienza ... passarono vent'anni :D

Si, tanto è che, effettuando una qualche modifica in un file di sistema - credo Msdos.Sys - la GUI non si avvia. Si può poi fare manualmente con comando "Win". Lo facevo vent'anni fa per motivi di retrogaming !

bootgui=0


o in caso di pigrizia estrema, bastava rinominare win.exe :)

se ricordo bene, f8 durante l'avvio e si apriva il menù con cui nn facevi avviare la gui
msdos.sys era un binario, se non ricordo male, però ricordo che c'era un file che si poteva editare, è passato un quarto di secolo ormai. Forse config.sys

Edit: per curiosità son andato a cercare e si , era config.sys, l'estensione ti ha giocato un brutto scherzo :D

msdos.sys era binario con il dos. con windows9x era un file di testo e conteneva il già citato bootgui.

https://www.computerhope.com/issues/ch000132.htm


config.sys era il file di configurazione del dos e permetteva di caricare e configurare i driver di sistema (ansi.sys, keyboard.sys, himem.sys e compagnia cantando)

msdos.sys era binario con il dos. con windows9x era un file di testo e conteneva il già citato bootgui.

https://www.computerhope.com/issues/ch000132.htm


config.sys era il file di configurazione del dos e permetteva di caricare e configurare i driver di sistema (ansi.sys, keyboard.sys, himem.sys e compagnia cantando)

Chiedo venia :D
E grazie per l'info non lo sapevo proprio

mica tanto.
il primo windows a supportare i 32 bit è stata la versione 2.0; si chiamava windows 386.
già la versione 3.x, se trovava un processore 32 bit, si avviava in tal senso e la modalità a 16 bit andava forzata.

windows95 è stato il primo a non supportare la modalità 16 bit (ma eseguiva i programmi a 16 e accettava, con qualche limite, i driver)

I 32 bit erano supportati giù da Windows 3.1/3.11... Il mio primo 486 ( DX 33 ) lanciava Windows a 32 bit di default. Anche se non erano i 32 bit reali di Windows NT soprattutto per la gestione della memoria.

Il vantaggio più grande del passaggio dai 32 ai 64 bit è stata la possibilità di poter sfruttare quantitativi di memoria sempre più grandi: 16 anni fa circa la dotazione Ram standard era di 1GB, oggi il minimo sindacale sono 8GB.

Si è vero che 3.1/11 supportava qualcosa a 32 bit, ma era per sfruttare il modo "virtual mode" dei 386, isolando meglio i programmi tra di loro. Le applicazioni erano sempre a 16 bit.

Quà (https://devblogs.microsoft.com/oldnewthing/20100517-00/?p=14013)ci sono ulteriori dettagli

[...]Enhanced mode Windows was called a 16-bit operating system because it ran 16-bit Windows applications (inside a “Windows box”, you might say). The supervisor operating system was a 32-bit operating system, but since applications didn’t run in supervisor mode, that really didn’t mean much. [...]

Sarebbe ora di buttare tutta la zavorra legacy che si porta l'architettura Intel.

Quelli che dicono che i 32 bit servono ancora... falso. I 32 bit servono perché alcune applicazioni non sono state ricompilate a 64 bit, vuoi per la pigrizia di alcuni sviluppatori, vuoi perché non è mai servito realmente (in realtà ha i suoi vantaggi: passaggio di argomenti via registri, indirizzamento relativo al program counter e maggiore possibilità di sfruttare meccanismi di sicurezza come la randomizzazione degli indirizzi).

Alle brutte sarà sufficiente una sandbox che fa girare le app a 32 bit in emulazione, non sarà così drammatico, visto che sempre di ISA x86 parliamo.

Si è vero che 3.1/11 supportava qualcosa a 32 bit, ma era per sfruttare il modo "virtual mode" dei 386, isolando meglio i programmi tra di loro. Le applicazioni erano sempre a 16 bit.

Quà (https://devblogs.microsoft.com/oldnewthing/20100517-00/?p=14013)ci sono ulteriori dettagli

[...]Enhanced mode Windows was called a 16-bit operating system because it ran 16-bit Windows applications (inside a “Windows box”, you might say). The supervisor operating system was a 32-bit operating system, but since applications didn’t run in supervisor mode, that really didn’t mean much. [...]

vero anche questo.
ricordo vagamente che c'era in giro un pacchetto win32s, necessario per far girare i programmi nati su NT.

o beh... chissene, eh :)

ricordo vagamente che c'era in giro un pacchetto win32s,

Magari mi confondo con altro ma credo fosse usati anche da alcuni giochi e distribuito nel cd (si era già l'era dei cd-rom) con il gioco.

https://en.wikipedia.org/wiki/Win32s