Windows XP Beta per AMD 64

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

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

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

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


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

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


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

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

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

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