Link alla notizia: http://news.hwupgrade.it/10857.html

In coincidenza del lancio di Athlon 64 da parte di AMD, Microsoft rilascia una release beta di Windows XP che supporta tale nuova tecnologia

Click sul link per visualizzare la notizia.

bene si comincia una nuova epoca .... ;)

http://www.gamepc.com/labs/view_content.asp?id=amd64xp&page=1

qui però dicono che i driver a 32bit non fungono e ti evi tenere quelli nativi di winzozz o driver ricompilati a 64bit.

non è carino speriamo vengaqno fuori a breve driver a 64bit da tutti i costruttori di hw.

Io già mi vedo il directx a 64bit, con giochi che oltre alle istruzioni extra tipo MMX, necessiteranno dei 64bit dei processori altrimenti bisognerà accontentarsi della versione slow motion.
Secondo me i 64bit servono solo per i calcoli con precisione in virgola mobile, un sistema operativo come Windows dove i programmi più spinti sono i giochi può farne benissimo a meno. Utilizzassero la nuova tecnologia per generare meno calore invece.
Ma comunque diventerà de facto l'adozione dei 64bit e quindi tutti scriveranno documenti in word a 64bit.

Sono curioso di vedere i vantaggi...

Scusate ma avere un applicativo a 64 Bit che fa 1+1 occupa il doppio dello spazio se non ottimizzato decentemente (byte = 8Bit integer(64) =64Bit) e non è più veloce di uno a 32Bit.
Sinceramente i 64 Bit sono utili a quei programmi che richiedono calcoli complessi da utilizzarne la lunghezza del registro.
Comunque spero che AMD abbia inventato un sistema per usare in parallelo il registro in modo da ridurre le istruzioni per ciclo (stile MMX ma senza ricodificare le operazioni e istruzioni dedicate)
Conoscendo Bill rischiamo di avere WinXP 32 Bit veloce come WinXp 64 Bit. L'unica salvezza e architettura ADM64 che forse potrebbe fare vedere l'aumento delle prestazioni.

I 32 bit vedono max 4 gigabyte i 64 bit non ricordo quanti milioni di gigabite possono vedere

Vi lascio immaginare a cosa succedera'

"un sistema operativo come Windows dove i programmi più spinti sono i giochi"

Ehm, ma sei sicuro di questo? In ufficio non usiamo giochi ma non è che i PC non siano per niente sotto sforzo :)

Ti rispondo. Per me i 64bit stanno generando solo confusione tra gli utenti che inseguono i numeri.
L'esempio lo abbiamo avuto quando AMD sparava i suoi processori con frequenze superiori all'INTEL per un periodo se mi ricordo bene. INTEL rispose cambiando tecnologia e superando l'AMD. Conclusione la stessa AMD dovette crearsi una nuova scala di frequenze per contrastare INTEL. I primi bios delle schede madri però segnalavano quella reale non la sigla del processore. Il resto è storia.

E la colpa è di un sistema operativo riempito d'aria e non ottimizzato. E poi parlavo della potenza di calcolo non delle prestazioni.

Non cominciate a pensare che 64 bit sia sinonimo di maggiore velocita' IN TUTTE LE APPLICAZIONI...perche' allora rimarrete fortemente delusi...

Originariamente inviato da velociraptor68
Secondo me i 64bit servono solo per i calcoli con precisione in virgola mobile, un sistema operativo come Windows dove i programmi più spinti sono i giochi può farne benissimo a meno. Utilizzassero la nuova tecnologia per generare meno calore invece.
Non è vero che i programmi + spinti sono i giochi... I programmi di 3D rendering ad esempio sono molto spinti e girano per la maggior parte su Windows...

Inoltre i 64 bit delle nuove CPU AMD sono sugli interi...i floating point a 64 bit ci sono fin dal 486 (se non sbaglio), anzi possono essere anche ad 80 bit (internamente i calcoli vengono comunque fatti ad 80 bit)...

Originariamente inviato da Cimmo
Non cominciate a pensare che 64 bit sia sinonimo di maggiore velocita' IN TUTTE LE APPLICAZIONI...perche' allora rimarrete fortemente delusi...
I 64 bit non possono di certo velocizzare tutte le applicazioni...ma dove sono necessari gli interi a 64 bit (e dove attualmente sono utilizzati due interi a 32 bit per simularne uno a 64) allora le prestazioni possono anche raddoppiare...

In ogni caso il boost offerto dagli 8 registri general purpose aggiunti alla ALU è ottenibile con una semplice ricompilazione (anche continuando a sfruttare solamente 32 bit dei registri a 64 bit)...

A parole tutto ok...poi mi ricordo come è finita con Win 2000......

La storia si ripete, tutte cose già sentite dal passaggio dai 16 ai 32 bit che poi si è completato pienamente con windows 2000 (anzi NT ma non era per gli usi home) ed i vantaggi di sono visti, certo in un primo momento sembrava che le migliorie fossero poche, ma oggi chi si lamenta di WinXP?????

X Iasa

Perchè cosa è successo con windows 2000?

(Non è vero che i programmi + spinti sono i giochi... I programmi di 3D rendering ad esempio sono molto spinti e girano per la maggior parte su Windows... )

Perche' tu usi assiduamente i programmi 3D di rendering?
Io ho avuto il piacere a suo tempo di usare IMAGINE su Amigados tanto per il miracolo che non per necessità, ma poi sul PC ho fatto ben altro, quando me lo lasciava fare.
Ciao.

velociraptor68: chi ci lavora in quel campo li usa assiduamente...e quindi ne trarranno vantaggi...
Poi era solo un esempio...
Ci sono tante altre applicazioni che trarranno vantaggi notevoli dai 64 bit... Ad esempio tutti i programmi di crittografia...poi anche i DBMS...

Ripeto che comunque tutti i programmi trarranno anche un minimo di vantaggio dalla semplice ricompilazione visto che verranno sfrutttati gli 8 registri aggiuntivi della ALU...

Quella dei DBMS a 64bit non l'avevo ancora sentita.
Grazie.

cmq non vorrei deludere velociraptor68 e nemmeno sorprenderlo con effetti speciali.. ma i giochi sono applicazioni che usano in modo molto ma molto pesante i calcoli fatti in floting-point.. e ricorda che se vuoi stressare un hw nel suo complesso.. fagli girare sopra un gioco ;)

E pensa che i DB sono proprio la tipologia di software che si avvantaggerà di + di questi processori.
Al contrario di quello che dici se la virgola mobile fosse a 64 bit, sto processore sarebbe da prendere e buttare. No no, la virgola mobile non c'entra nulla coi 64 bit.
Ora rifletti: quali sono le applicazioni che devono gestire grosse quantità di dati di tipo intero ? non certo i giochi, che, sebbene se ne avvantageranno, lo faranno in minima parte, dato che quello che sfruttano è la fpu. Neppure i motori di rendering cambieranno di molto le loro prestazioni.
Però sono curioso di vedere in quanto tempo mi riesco a bruteforceare una password con quella creatura :)

...e i compilatori dove li mettiamo??

Nella presentazione cera scritto "1°Q 20004" forze ero preso troppo dall'evento.:boh:

Originariamente inviato da savoweb
Scusate ma avere un applicativo a 64 Bit che fa 1+1 occupa il doppio dello spazio se non ottimizzato decentemente (byte = 8Bit integer(64) =64Bit) e non è più veloce di uno a 32Bit.


scusa non ho capito bene il senso della tua frase, però provo a risponderti lo stesso:
in memoria viene allocato sempre e solo 1 byte alla volta quindi (se ho capito bene quello che volevi dire) non c'è nessuno spreco!

mentre uno dei benefici apportati dai 64bit è la memoria massima gestibile che infatti schizza a
:eek:2^64 = 18.446.744.073.709.551.616:eek: byte (circa 18 Milioni di Tb) ...numeri che fanno girare la testa...
contro i
2^32 = 4.294.967.296 byte (circa 4Gb)

spero di non aver fatto disinformazione!
zao

Originariamente inviato da savoweb
Scusate ma avere un applicativo a 64 Bit che fa 1+1 occupa il doppio dello spazio se non ottimizzato decentemente (byte = 8Bit integer(64) =64Bit) e non è più veloce di uno a 32Bit.
Appunto per evitare questo problema, l'amd64 opera "di default" sulla parte dei registri a 32 bit per i calcoli, anche in modalità a 64 bit. Se conosci un pò di assembler (il famoso "prefisso" per passare ad es. da ax->eax e viceversa), mi puoi capire al volo ;) altrimenti fidati :D

Originariamente inviato da savoweb
Conoscendo Bill rischiamo di avere WinXP 32 Bit veloce come WinXp 64 Bit.
L'amd64 ha anche un discreto numero di registri in più; già questo fa comodo a qualsiasi programma (o sistema operativo) compilato appositamente per questa architettura.

Ricordate, e' un numero magico.... legato ad anni magici.....

Ho letto che verra' fuori un divx a 64 bit.


ciao

Chissa se intel dopo questa nuova news non integrera nei suoi procci , la tanto parlata YamHill Technology, ho trovato molti articoli di questi giorni dove ci sarebbe la possibilita che intel stia prendendo seriamente in considerazione di integrarla con l'uscita dei nuovi processori Prescott.
Infatti le caratteristiche dovevano essere le seguenti:

- processo produttivo a 0.09 micron
- dimensione del Die di 109mm2
- 800Mhz FSB
- 1MB L2 Cache / 16KB L1 Cache
- 13 Prescott New Instructions (PNI)
- Pipeline più lunghe
- Extended Physical Address Extension (PAE) 40bit
- YamHill Technology (64bit/32bit)
- La Grande Technology
- Socket 478 - H2 '03, Socket T LGA 775 - 2004
- 3.4Ghz al debutto; sino a 5Ghz in versioni successive
- Disponibilità: ultimo trimestre 2003

Ecco il alcuni link : theinquirer (http://www.theinquirer.net/?article=11668) softnews (http://news.softnews.ro/news/2/2003/September/4868.shtml) neowin (http://www.neowin.net/comments.php?id=13889) neoseeker (http://www.neoseeker.com/news/articles/headlines/Hardware/2526/)

Se cosi fosse , speriamo che sia una rivoluzione a livello globale, a me non dispiacerebbe passare ai 64-bit!!!!! Non vedo l'ora di provare l'athlon64 FX

Speriamo invece che non passino ai 64 bit con YamHill visto che sicuramente non sarebbe compatibile con AMD64...

Comunque sicuramente non ci passeranno con il socket 478...non credo che prev eda un indirizzamento a 64 bit ;)

Il PAE di Opteron indirizza a 40 bit reali, NON a 64 bit; mentre fino al Northwood il PAE è a 36 bit.

Ciao

Federico

Bellissimo, non vedo l'ora di potermi acquistare il windows64. Si sa in già quanto costerà? Spero non meno di 400€, non vorrei trovarmi dei risparmi in banca a fine mese.
Una volta installato win64, mi comprerò subito l'athlonFX e installerò immediatamente 1Terabyte di ram, perchè i 4Gbyte mi stanno già stretti. Già immagino le favolose applicazioni e i boost prestazionali che potremo ottenere. Che dite potrò giocare meglio a doomIII? E potrò guadagnare almeno 5 secondi nella codifica in divx? spero proprio di si.

Originariamente inviato da }DrSlump{
Bellissimo, non vedo l'ora di potermi acquistare il windows64. Si sa in già quanto costerà? Spero non meno di 400€, non vorrei trovarmi dei risparmi in banca a fine mese.
Una volta installato win64, mi comprerò subito l'athlonFX e installerò immediatamente 1Terabyte di ram, perchè i 4Gbyte mi stanno già stretti. Già immagino le favolose applicazioni e i boost prestazionali che potremo ottenere. Che dite potrò giocare meglio a doomIII? E potrò guadagnare almeno 5 secondi nella codifica in divx? spero proprio di si.
Ma che roba utilizzi???.....Secondo me è tagliata male:D :D :D
scherzavo ovviamente.......
vorrei proprio parlarci faccia a faccia con un betatester di microsoft
chissà quanti aneddoti divertenti...e neuroni bruciati...

pirolisi... non c'è bisogno di arrivare fino ai betatester microsoft per aneddoti divertenti e soprattutto, neuroni bruciati.

I fp a 64 bit (doppia precisione) esistevano già ai tempi degli 8086, tramite il coprocessore 8087... ;)

L'importante ora è ottimizzare i drivers...

E' sceso e'sceso.
http://web.essedi.it/
5 giorni e' gia' e' sceso , :ave: :sbavvv: :winner:
:yeah:

scusate gli errori ma l'emozione fa' brutti scherzi
:D VERY :D

la nuova era...
Cmq non è un po vecchiotta come notizia??

X tutti gli sciettici.
La 32 bit è una tecnologia ormai arrivata ai limiti fisici.Indirizzare + memoria apre un orizzonte nuovo.
Ma quando è uscito il pentium e abbiamo abbandonato i 16 bit eravate così.
Adesso nonn avremmo subito benefici ma aspettate un pò.
Poi pensate che tutta l'evoluzine dell informatica è stata programmata a grandi lineee fino al 2030.

Originariamente inviato da dragunov
La 32 bit è una tecnologia ormai arrivata ai limiti fisici.Indirizzare + memoria apre un orizzonte nuovo.

Il problema non è solo la memoria indirizzabile ma anche gli indirizzi virtuali disponibili. Ad esempio su processori a 32 bit, già per gestire 2GB di RAM i sistemi operativi devono fare contorsioni mentali. Oltre i 4GB diventano vere e proprie alchimie, con impatto negativo sulla velocità del sistema.

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.

Sicuramente Intel supporterà adeguatamente le sue SSE3 come è solita fare, speriamo che AMD si dia una mossa.

In ogni caso otto registri general-purpose in più fanno una bella differenza: se vi ricordate (... ne è passato del tempo ora che mi ci fate pensare... ) dello sviluppo di Linux e del GCC, saprete che un tempo il formato degli eseguibili era il cosiddetto a.out, mentre ora è ELF.

Al momento del passaggio, si notò subito che sui processori x86 il passaggio all'ELF in sè aveva comportato un rallentamento generale dei programmi che si attestava mediamente fra il 5 e l'8%: questo perchè il frame pointer 'occupava' generalmente un registro che altrimenti si sarebbe potuto impiegare diversamente.

Tant'e' che ancora adesso quando compilate qualcosa sotto Linux che non sia necessario debuggare, l'opzione -fomit-frame-pointer è caldamente consigliata in quanto aumenta la velocità senza nessun incoveniente.

Otto registri in piu' serviranno eccome, vedrete... compilatori come GCC che girano già su un sacco di architetture diverse non dovrebbero avere problemi ad essere modificati per sfruttarli

AGGIUNTA: mi accorgo ora che esiste già il GCC per x86-64, anche se non so come sia messo a livello di performance.

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

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...

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.

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 :D

Infatti...

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 ;)

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.......

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

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...

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"...

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++)...

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"...

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...

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.

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

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...

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).

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... ;)

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... :)

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 :D
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 ;)

Originariamente inviato da
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

Allora, premesso che di standard non si tratta, come ho già detto, perché le specifiche del linguaggio non entrano (giustamente) nel dettaglio implementativo, le due scelte, come hai riportato, hanno pregi e difetti. E' una cosa normale. La differenza fra int e long la dovremmo vedere adesso che si deve pensare alle soluzioni a 64 bit: per me è naturale "assegnarli" questa capacità. Mi spiego meglio.
Attualmente abbiamo:

char -> 8 bit
short -> 16 bit
int -> 32 bit

più o meno per tutti i sistemi (i più usati, comunque), mentre per l'implementazione dei long vale quanto hai già scritto. A questo punto una cosa saggia sarebbe porre:

long -> 64 bit

e utilizzare questo tipo di dati per manipolare sia dati che indirizzi (insomma: non mi piace la facilità con cui si scambiano interi e puntatori. :rolleyes:).

D'altra parte, se leggiamo le specifiche del linguaggio C, abbiamo soltanto che:

sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

per cui qualunque scelta implementativa ricade sempre e comunque nella piena capacità di ogni casa di poter decidere liberamente quali valori attribuire ad ogni tipo di dati, ma almeno a questo punto la presenza di un long avrebbe un senso, visto che con char/short/int andiamo a coprire già tutti i tipi di dati utilizzati nelle architetture fino a 32 bit...

Andando decisamente oltre, non capisco perché nei linguaggi non siano stati introdotti degli strumenti sintattici o dei tipi per specificare delle quantità "standard".

Ad esempio int[8] (nuova sintassi) o int8 (nuovo tipo, nessun cambiamento di sintassi) per specificare interi che possono contenere ALMENO 8 bit, e così via con int[16]/int16, int[32]/int32, int[64]/int64. A ciò aggiungerei un int /intptr per specificare un intero che è in grado di contenere un puntatore in grado di indirizzare tutta la memoria, e delle funzioni standard per il "casting" fra interi e puntatori.

A mio avviso si guadagnerebbe molto più in portabilità e in leggibilità, invece di farcire gli include con una miriade di #ifdef/#define che ti fanno comunque rimanere con l'idea di non poter abbracciare qualunque architettura esistente (non puoi mica conoscere TUTTI i processori e i s.o.).

Mi sa che ho divagato un po' troppo, come al solito... :p

Originariamente inviato da cdimauro
Allora, premesso che di standard non si tratta, come ho già detto, perché le specifiche del linguaggio non entrano (giustamente) nel dettaglio implementativo
Sono convenzioni implementative; non ufficialmente standard ma ormai standard "de facto".


(insomma: non mi piace la facilità con cui si scambiano interi e puntatori. :rolleyes:).
A volte è necessaria, per evitare una atroce aritmentica dei puntatori. Probabilmente le memory management dll ne fanno largo uso.


Andando decisamente oltre, non capisco perché nei linguaggi non siano stati introdotti degli strumenti sintattici o dei tipi per specificare delle quantità "standard".

Ad esempio int[8] (nuova sintassi) o int8 (nuovo tipo, nessun cambiamento di sintassi)...
Perché se ne sono "accorti dopo". In effetti si sta parlando solo da un pò di estensioni allo standard per ovviare a questi problemi; avrai notato che ormai tutti i compilatori mettono a disposizione cose tipo uint_8_t, int16_t o nomi più o meno esotici. Ora tutto sta a mettersi d'accordo su "come chiamarli" :D

Sì...anche VC++ ha:

__int8, __int16, __int32, __int64....

Sì infatti, ognuno ha i suoi nomi

Questo vuol dire che se vuoi scrivere un programma portabile, devi inventarti la tua ennesima definizione e typedeffare su quella in base al compilatore...

Tra parentesi, ho avuto tempo fa un problema originato da un compilatore che considerava di default char come unsigned char...ok ingenuità mia, ma DANNAZIONE CHI CI VA A PENSARE? :incazzed:

:confused:

... miii... mi fate sentire un ignorante totale...:muro:

:p

Originariamente inviato da ilsensine
Tra parentesi, ho avuto tempo fa un problema originato da un compilatore che considerava di default char come unsigned char...ok ingenuità mia, ma DANNAZIONE CHI CI VA A PENSARE? :incazzed:
Quale ? Bellina la faccina ;)

Bella recensione, l'avete vista ?
http://www.aceshardware.com/read.jsp?id=60000256

Originariamente inviato da cionci
Quale ? Bellina la faccina ;)
gcc cross-compiatore per arm.
Hanno fatto quella scelta in quanto gli unsigned char sull'arm sono più veloci dei signed. Non lo sapevo e mi mandava a puttane una mia dwt grrrr

Originariamente inviato da ilsensine
Sono convenzioni implementative; non ufficialmente standard ma ormai standard "de facto".
Beh, diciamo di sì, ma limitandoci ai sistemi più diffusi... :)
A volte è necessaria, per evitare una atroce aritmentica dei puntatori.
Bene o male il C possiede un'ottima gestione dei puntatori (è il suo cavallo di battaglia), per cui l'esigenza di passare da intero a puntatore e viceversa è veramente limitata, almeno per l'esperienza che ho avuto in merito...
Probabilmente le memory management dll ne fanno largo uso.
Un gestore di memoria comunque deve tenere conto del tipo di architettura sul quale sta girando, per cui utilizzare qualche "trucchetto sporco" penso sia normale... ;)

Perché se ne sono "accorti dopo".
Se non erro l'ANSI C è stato standardizzato intorno al 1985, per cui hanno avuto ampii margini di tempo per sistemare questa "rogna"...
In effetti si sta parlando solo da un pò di estensioni allo standard per ovviare a questi problemi;
Per è un problema molto vecchio e conosciuto: magari non interessava più di tanto prima, ma con tutte le architetture che sono fiorite dagli anni '80 in poi, sarebbe stato meglio metterlo fra le priorità...
avrai notato che ormai tutti i compilatori mettono a disposizione cose tipo uint_8_t, int16_t o nomi più o meno esotici.
Sì perché, appunto, un programmatore ha bisogno di certezze per poter lavorare con tranquillità... ;)
Ora tutto sta a mettersi d'accordo su "come chiamarli" :D
Non a caso parlavo di estensioni rientranti nello standard... :p

Originariamente inviato da cionci
Bella recensione, l'avete vista ?
http://www.aceshardware.com/read.jsp?id=60000256
Non ho ancora avuto tempo!!! :cry:

Originariamente inviato da ilsensine
gcc cross-compiatore per arm.
Hanno fatto quella scelta in quanto gli unsigned char sull'arm sono più veloci dei signed. Non lo sapevo e mi mandava a puttane una mia dwt grrrr
Discrete Wavelet Transformation? Ma guarda un po', in questi giorni dovrei iniziare uno stage + tesi di laurea all'SGS Thompson che riguarda l'implementazione del codec JPEG2000... :D

Comunque anche per l'attributo signed/unsigned vale il discorso di cui sopra... ;)

Originariamente inviato da cdimauro
Comunque anche per l'attributo signed/unsigned vale il discorso di cui sopra... ;)
Sì ma ho sempre usato il gcc con la sua beata convensione char==signed char, vai a pensare che un altro gcc ha la convenzione inversa :muro:

Non ti racconto la gioia nel vedere le immagini atomizzate senza apparente motivo :D

Originariamente inviato da cdimauro
Discrete Wavelet Transformation? Ma guarda un po', in questi giorni dovrei iniziare uno stage + tesi di laurea all'SGS Thompson che riguarda l'implementazione del codec JPEG2000... :D

Argh la potevi fare qui da noi, visto che ultimamente non ho tempo per continuare i lavori intrapresi con la dwt :muro:
Vabbè avresti dovuto lavorare solo su linux :sofico:

Originariamente inviato da ilsensine
Sì ma ho sempre usato il gcc con la sua beata convensione char==signed char, vai a pensare che un altro gcc ha la convenzione inversa :muro:

Non ti racconto la gioia nel vedere le immagini atomizzate senza apparente motivo :D
In effetti ti capisco: passando da una versione di GCC a un'altra non mi aspetterei mai un cambiamento così importante... :(
Argh la potevi fare qui da noi, visto che ultimamente non ho tempo per continuare i lavori intrapresi con la dwt :muro:
Vabbè avresti dovuto lavorare solo su linux :sofico:
Non sarebbe stata mica la prima volta... :D

Comunque mi aspetta ben peggio che sviluppare la sola dwt, e in sole 225 ore. Speriamo bene... :p

Originariamente inviato da cdimauro
In effetti ti capisco: passando da una versione di GCC a un'altra non mi aspetterei mai un cambiamento così importante... :(

Non era un problema di versione. Il compilatore incrociato che ho usato era stato compilato per trattare di default i char come unsigned, visto che sull'arm è un pò più veloce. A saperlo prima avrei scritto il codice usando "signed char" al posto di "char" dove mi serviva; me la sono cavata passando a gcc il flag -fsigned-char, anche se così ha considerato "signed char" anche le variabili che potevano benissimo essere "unsigned".

Forse mi sono espresso male quando ho parlato di cambio di versione: intendevo quello che hai riportato, non un variazione numerica. :)
Comunque, quando lavoro col C preferisco utilizzare un file include in cui definisco i miei tipi Byte, Word, Longword, ecc., così da evitare qualunque problema alla radice...