Windows XP Beta per AMD 64

[JamesWT]

Originariamente inviato da elessar
quanta perplessita' su questi 64bit! Non sarebbe meglio aspettare e dare un'occhiata cosa si potrà fare sul piano pratico? Potrebbe anche essere l'architettura migliore del mondo, ma senza un adeguato supporto software (leggi: compilatori ottimizzati e altri strumenti di sviluppo che dovrebbe fornire AMD, se vuole che i suoi prodotti vengano utilizzati) non servirà ad un beneamato nulla.

infatti non basta solo il sistema operativo bisogna che tutti i programmi siano convertiti per i 64 bit

[cionci]

Originariamente inviato da JamesWT
infatti non basta solo il sistema operativo bisogna che tutti i programmi siano convertiti per i 64 bit

Tutti non è detto...bastano quelli che ci servono

Su Linux è tutta una pacchia...basta ricompilare e non ci sono problemi...

[elessar]

Su Linux è tutta una pacchia...basta ricompilare e non ci sono problemi...

Anche su Windows potrebbe essere una pacchia. Basterebbe che AMD 'lanciasse' un compilatore compatibile con quello di MS o Intel che si possa integrare adeguatamente in Visual Studio, e ad un qualsiasi sviluppatore potrebbero bastare pochi click per rilasciare una versione 64bit di qualsiasi suo software.

[leoneazzurro]

Molto probabilmente Microsoft farà uscire il suo compilatore, del resto se si è data pena di mandare avanti il Windows XP 64 bit, non lo vorrà lasciare senza applicazioni

[cionci]

Infatti...

[cionci]

Originariamente inviato da elessar
Anche su Windows potrebbe essere una pacchia. Basterebbe che AMD 'lanciasse' un compilatore compatibile con quello di MS o Intel che si possa integrare adeguatamente in Visual Studio, e ad un qualsiasi sviluppatore potrebbero bastare pochi click per rilasciare una versione 64bit di qualsiasi suo software.

Ci sono sempre anche i porting del GCC su Windows...magari verrà sviluppato un MinGW64

[ilmanu]

Originariamente inviato da velociraptor68
. Conclusione la stessa AMD dovette crearsi una nuova scala di frequenze per contrastare INTEL.

ehmm... guarda che amd aveva un clock inferiore al dichiarato e non maggiore, intel ,semmai, per contrastare amd ha dovuto pompare di ghz i suoi proci.......

[ilmanu]

Originariamente inviato da elessar
Anche su Windows potrebbe essere una pacchia. Basterebbe che AMD 'lanciasse' un compilatore compatibile con quello di MS o Intel che si possa integrare adeguatamente in Visual Studio, e ad un qualsiasi sviluppatore potrebbero bastare pochi click per rilasciare una versione 64bit di qualsiasi suo software.

be' la migrazione di un codice non e' cosi' semplice...non e' che gli dici compila a 64bit e lui zack lo fa...lo devi anche scrivere il codice a 64bit altrimenti rischi (se mai fosse possibile tale procedura ma dubito) che un applicativo vada meno dello stesso a 32....IMHO

[cionci]

Originariamente inviato da ilmanu
be' la migrazione di un codice non e' cosi' semplice...non e' che gli dici compila a 64bit e lui zack lo fa...lo devi anche scrivere il codice a 64bit altrimenti rischi (se mai fosse possibile tale procedura ma dubito) che un applicativo vada meno dello stesso a 32....IMHO

Non è vero...se un aplicativo non è scritto con i piedi, basta una semplice ricompilazione !!! Anche senza mettere mano al codice... Sia epr Windows che per Linux...

[ilsensine]

Originariamente inviato da cionci
Non è vero...se un aplicativo non è scritto con i piedi, basta una semplice ricompilazione !!! Anche senza mettere mano al codice... Sia epr Windows che per Linux...

Già confermo. L'unico problema è il passaggio tra macchine big endian/little endian, ma non è questo il caso.

In realtà _alcuni_ applicativi Microsoft potrebbero nascondere un subdolo problema: per "tutto il mondo informatico" vale la regola
sizeof(long) == sizeof(void *) (4 byte su 32 bit / 8 byte su 64 bit)
ma la Microsoft ha scelto
sizeof(long) == sizeof(int) (4 byte)

Almeno è quanto ho saputo dai "bene informati"...

[cionci]

E' vero...a questo non ci avevo pensato... Comunque i problemi si verificherebbero in casi non troppo frequenti...

Comunque caso a parte sono gli applicativi che usano gli interi a 64 bit anche su macchine a 32 bit simulandoli con due interi a 32 bit... In quei casi il codice andrebbe riscritto (anche qui se fosse programmato bene basterebbe fare qualche piccola modifica, soprattutto se fatto in C++)...

[ilsensine]

Originariamente inviato da cionci
Comunque caso a parte sono gli applicativi che usano gli interi a 64 bit anche su macchine a 32 bit simulandoli con due interi a 32 bit... In quei casi il codice andrebbe riscritto (anche qui se fosse programmato bene basterebbe fare qualche piccola modifica, soprattutto se fatto in C++)...

Il compilatore Borland mi sembra avesse questa "feature"...non so se hanno "sistemato"...

[cionci]

Non vorrei dire cavolate, ma ora che ci penso anche i compilatori MS e il GCC hanno questa possibilità...
Per Visual C++ c'è il tipo __int64 e per il GCC non mi ricordo...
Per chi usa questo tipo credo che non si debba fare alcun cambiamento...

[ilsensine]

Originariamente inviato da cionci
Non vorrei dire cavolate, ma ora che ci penso anche i compilatori MS e il GCC hanno questa possibilità...
Per Visual C++ c'è il tipo __int64 e per il GCC non mi ricordo...
Per chi usa questo tipo credo che non si debba fare alcun cambiamento...

Sì ma mi riferifo al fatto che il Borland implementava gli interi a 64 bit con strutture (il Vc e gcc come un tipo primitivo), e le prestazioni erano decisamente inferiori rispetto altri compilatori.
Sono solo voci di corridoio non particolarmente attendibili cmq.

[cionci]

Ah...ok...può essere benissimo...

[cdimauro]

Originariamente inviato da ilmanu
be' la migrazione di un codice non e' cosi' semplice...non e' che gli dici compila a 64bit e lui zack lo fa...lo devi anche scrivere il codice a 64bit altrimenti rischi (se mai fosse possibile tale procedura ma dubito) che un applicativo vada meno dello stesso a 32....IMHO

Dipende da com'è scritta l'applicazione, e se effettivamente ti serve gestire quantità intere a 64 bit...
Per il resto, l'A64 non è soltanto un'estensione a 64 bit, ma un'architettura praticamente nuova e una banale ricompilata permetterebbe di sfruttarla già abbastanza bene...

[cdimauro]

Originariamente inviato da ilsensine
Già confermo. L'unico problema è il passaggio tra macchine big endian/little endian, ma non è questo il caso.

Questo è sempre gestito dal compilatore, quindi non c'è niente di cui preoccuparsi. Al più, se serve, è il programmatore che deve preoccuparsi di gestire l'endianess correttamente...

In realtà _alcuni_ applicativi Microsoft potrebbero nascondere un subdolo problema: per "tutto il mondo informatico" vale la regola
sizeof(long) == sizeof(void *) (4 byte su 32 bit / 8 byte su 64 bit)
ma la Microsoft ha scelto
sizeof(long) == sizeof(int) (4 byte)

Almeno è quanto ho saputo dai "bene informati"...

Se parliamo di standard, il C standard (ANSI, K&R, ma anche altre estensioni) non attribuisce alcuna "lunghezza" ad ogni tipo particolare: non puoi assumere che un long sia a 32 bit o 64 bit, perché tutto dipende da come è stato scritto il compilatore. In teoria un compilatore C per Commodore64 potrebbe anche assegnare 8 bit dal char al long, senza alcuna distinsione.

Quindi per quanto riguarda il discorso di cui parlavi, qualunque fosse la strada intrapresa, rimarrebbe comunque non discutibile (sono scelte che si fanno quando si affronta un progetto complesso come un compilatore).

Non è un caso se la prima cosa che fa un programmatore lungimirante è quella di scrivere un file include in cui definisce i tipi base che andrà ad utilizzare, specificando l'opportuno attributo (char, short, int, long, long long) a seconda della piattaforma (tramite compilazione condizionale).

[cdimauro]

Originariamente inviato da cionci
E' vero...a questo non ci avevo pensato... Comunque i problemi si verificherebbero in casi non troppo frequenti...

Appunto. Vedi sopra: basta cambiare l'include principale e tutto torna alla normalità...

Comunque caso a parte sono gli applicativi che usano gli interi a 64 bit anche su macchine a 32 bit simulandoli con due interi a 32 bit... In quei casi il codice andrebbe riscritto (anche qui se fosse programmato bene basterebbe fare qualche piccola modifica, soprattutto se fatto in C++)...

Bene o male è lo stesso meccanismo che viene utilizzato da ogni compilatore a 32 bit che offre il supporto al tipo intero a 64 bit. Ma non c'è di che preoccuparsi: l'importante è che il backend che genera l'eseguibile sia aggiornato per emettere il codice ottimizzato per l'archiettura a 64 bit. Roba da poco, comunque...

[cdimauro]

Originariamente inviato da ilsensine
Sì ma mi riferifo al fatto che il Borland implementava gli interi a 64 bit con strutture (il Vc e gcc come un tipo primitivo), e le prestazioni erano decisamente inferiori rispetto altri compilatori.
Sono solo voci di corridoio non particolarmente attendibili cmq.

Non c'è differenza fra compilatore Borland, MS e GNU: le versioni a 32 bit di questi compilatori funzionano tutte allo stesso modo, impaccando due interi a 32 bit in una struttura. Quel che preme è che il generatore di codice venga sistemato per sfruttare appieno l'architettura Hammer, e non solo per il supporto nativo ai 64 bit.

Attualmente l'unica che "manca all'appello" è Borland, ma entro la fine dell'anno penso che vedremo arrivare Delphi 8, quindi manca poco, IMHO...

[ilsensine]

Originariamente inviato da cdimauro
Questo è sempre gestito dal compilatore, quindi non c'è niente di cui preoccuparsi. Al più, se serve, è il programmatore che deve preoccuparsi di gestire l'endianess correttamente...

...appunto
Sapessi i programmi scritti con i piedi che ci sono in giro...

Se parliamo di standard, il C standard (ANSI, K&R, ma anche altre estensioni) non attribuisce alcuna "lunghezza" ad ogni tipo particolare: non puoi assumere che un long sia a 32 bit o 64 bit, perché tutto dipende da come è stato scritto il compilatore. In teoria un compilatore C per Commodore64 potrebbe anche assegnare 8 bit dal char al long, senza alcuna distinsione.

Quindi per quanto riguarda il discorso di cui parlavi, qualunque fosse la strada intrapresa, rimarrebbe comunque non discutibile (sono scelte che si fanno quando si affronta un progetto complesso come un compilatore).

La scelta sizeof(long) == sizeof(void *) non è stata presa a caso. Quando è stato discusso questo standard (l'altro è quello poi adottato dalla Microsoft) si pensava ad un "intero grande a sufficienza da poter contenere l'indirizzo di un puntatore". La Microsoft ha invece intrapreso lo standard che puntava a una perfetta corrisponenza del programma tra architetture distinte. Ambedue hanno un punto debole (nella prima, è scorretto usare i long "per fare i calcoli", se questi devono essere indipendenti dall'architettura; nella seconda, è scorretto usare long per manipolare gli indirizzi, in quanto è di dimensione insufficiente).
IMHO il primo standard è il più sensato, altrimenti non vedo che differenza debba esserci tra int e long