Discussion :

[mathieu_t]

Bonsoir...

Question peut-être idiote, mais la technologie 64 bits change-t-elle qqch à la programmation ?
Par exemple, un float sera toujours codé en 32 bits ?
Et si ça n'est pas le cas, y a-t-il des choses qui changent ? (mis à part la vitesse)


[Sujet placé en post-it - vous êtes invités à l'agrémenter de toute remarque / expérience / conseil pertinent sur le développement 64 bits ]

[Laurent Gomila]

Oui il y a des choses qui changent, notamment la taille des types primitifs. Un int, par exemple, sera certainement codé sur 64 bits sur une telle architecture.

[Invité]

Sur un compilateur c++ 64 bit, int continuera d'etre 32 bit, long sera 64 bit, et long long sera lui ausis 64 bit. char, short, float, double et long double ne changeront pas.

Autre modification importantes: un pointeur sera sur 8 bytes. Ceux qui avaient encore la mauvais habitude de caster un pointeur en int pour en extraire l'adresse auront quelques problemes.

Voici une liste non-exaustive de choses a faire attention:

La conversion de long vers un double n'est pas safe, puisque long (64 bit) depasse la capacite d'un double. Utiliser un long double a la place.

Porter une attention particuliere a l'inline assembly

Utiliser les identificateur pour les limites des types plutot que la valeur numerique correspondante (CHAR_BIT, CHAR_MAX, INT_MIN, ...) (voir include <climits>)

Privilieger l'utilisation de typedef dans votre code plutot que les type predefinit.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
typedef int           s32
typedef unsigned int  u32
typedef char          s8
typedef unsigned char u8
//...

De cette facon, si un type change de grosseur d'un environnement a l'autre, les seuls changements que vous aurez a faire sera de modifier les typedef (a condition de n'utiliser que des s32, u32, etc dans votre code)


Petite remarque, le standard c++ dicte cette regle sur la longueur des types: char <= short <= int <= long. Ce qui implique que cela risque de pouvoir varier d'un compilateur a l'autre. Sur 32 bit, la regle etait suivie (8, 16, 32, 32). Sur 64 bit aussi, mais peut etre certains compilateurs implanteront int = long = 64) Encore une fois, utilisez climits[/code]

Bon, je dis ca de souvenir, il y a surement d'autre details importants

[doccpu]

Petite remarque, le standard c++ dicte cette regle sur la longueur des types: char <= short <= int <= long. Ce qui implique que cela risque de pouvoir varier d'un compilateur a l'autre. Sur 32 bit, la regle etait suivie (8, 16, 32, 32). Sur 64 bit aussi, mais peut etre certains compilateurs implanteront int = long = 64) Encore une fois, utilisez climits[/code]

Bon, je dis ca de souvenir, il y a surement d'autre details importants

Cela m'ettonne que le long soit éttendu alors que depuis le debut de l'informatique c'est l'int qui a servit de pointeur (int = taille du bus d'adresse). Le long a toujours quant a lui été calculé sur 32 bits (sur les machines 16 bits aussi) et le long long sur 64 (sur les machines 32 bits aussi)

Quant a la regle (char <= short <= int <= long) elle n'est pas tout a fait exacte car en fait c'est :
[unsigned] char = 8 bits, [unsigned] short = 2 char, [unsigned] long = 2 short, [unsigned] long long = 2 long, int = taille du bus d'adresses,
pour les entiers et :
[unsigned] single = 32 bits, [unsigned] double = 2 single, float = taille du bus d'adresses.
pour les flottants.

Jusque à present l'apparence conservait : char < short <= int <= long < long long, mais je ne pense pas que cela reste ainsi. Enfin comme vous l'avez dit ce ne sont que des valeurs arbitraires, basées sur les types physiques du processeur, mais ce ne sont que des conventions.

Vous pouvez retrouver les types processeurs sur :
www.sandpile.org

A++ et bon Trolls (de Troy, biensur )

[loufoque]

Quant a la regle (char <= short <= int <= long) elle n'est pas tout a fait exacte car en fait c'est :
[unsigned] char = 8 bits, [unsigned] short = 2 char, [unsigned] long = 2 short, [unsigned] long long = 2 long, int = taille du bus d'adresses,
pour les entiers et :
[unsigned] single = 32 bits, [unsigned] double = 2 single, float = taille du bus d'adresses.
pour les flottants.

C'est totalement faux.
Le standard ne dit rien de tel.

Il dit d'abord que sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long).
Ensuite une lecture plus fine permet de voir qu'un char fait au moins 8 bits, un short au moins 16 bits, un int au moins 16 bits, et un long au moins 32 bits.

Et c'est tout.
On peut très bien avoir sizeof(char) = sizeof(short) = sizeof(int) = sizeof(long) avec des bytes de 32 bits. C'est d'ailleurs le cas sur les DSP.

[Luc Hermitte]

Et sur solaris, j'ai des long de 64bits, tout comme les long long.

[doccpu]

C'est totalement faux.
Le standard ne dit rien de tel......

alors essaie de porter un programme qui a été developpé avec de grande valeur long et int en 32 voir 64 bit et porte les sur un système embarqué 16bit bit et pleure sur l'int car c'est lui qui fera 16bit alor que le long lui restera a 32 bit. tu peux essayer de le passer sur un système 8 bit mais je garanti pas que le long existe sur de tels systèmes mais la encore l'int fait 8bit (CQFD : int = largeur du bus d'adresses)

quant a la taille du char elle fait 8 bit parce que les registres du processeur ne savent pas gerer des donnees < 8bit. C'est ce qui determine aussi les alignements de donnees en memoire centrales.

[Matthieu Brucher]

alors essaie de porter un programme qui a été developpé avec de grande valeur long et int en 32 voir 64 bit et porte les sur un système embarqué 16bit bit et pleure sur l'int car c'est lui qui fera 16bit alor que le long lui restera a 32 bit. tu peux essayer de le passer sur un système 8 bit mais je garanti pas que le long existe sur de tels systèmes mais la encore l'int fait 8bit (CQFD : int = largeur du bus d'adresses)

Si tu relis bien ce que loufoque a écrit, tu ne le contredis pas, en revanche, lui oui.

[Jean-Marc.Bourguet]

tu peux essayer de le passer sur un système 8 bit mais je garanti pas que le long existe sur de tels systèmes mais la encore l'int fait 8bit

Une implémentation conforme a un int qui fait au moins 16 bits.

(CQFD : int = largeur du bus d'adresses)

Je ne vois aucune raison de fixer la taille d'un int en fonction de celle du bus d'adresse. (Au fait, les processeurs 8 bits ont généralement un bus d'adresse sur 16 bits)

quant a la taille du char elle fait 8 bit parce que les registres du processeur ne savent pas gerer des donnees < 8bit.

Un char fait au moins 8 bits. J'ai déjà utilisé une implémentation du C avec un char de 9 bits, des short de 18 bits et des int (et des long) de 36.

C'est ce qui determine aussi les alignements de donnees en memoire centrales.

Les contraintes d'alignement sont généralement le plus petit entre la taille de la donnée à transférer et la taille du bus de donnée.

[Joker-eph]

Autre modification importantes: un pointeur sera sur 8 bytes.

Hum, ça veut dire qu'on ne peut adresser que 256 mots en mémoires ?

[Laurent Gomila]

8 bytes = 64 bits.

[mathieu_t]

Merci pour ces éclaircissements, c'est vrai qu'on était en droit de se poser la question...
Ca veut dire qu'il va vraiment falloir faire gaffe à tous les anciens bouts de codes qui utilisaient par exemple aveuglément la taille des types de façon explicite ou non...

[JolyLoic]

Sur un compilateur c++ 64 bit, int continuera d'etre 32 bit, long sera 64 bit, et long long sera lui ausis 64 bit. char, short, float, double et long double ne changeront pas.

Ca dépend de quel 64 bits. Il en existe pour char/short/int/long je crois des 8/16/32/64 et des 8/16/64/64, et rien n'empêche des 8/32/64/64 ou des 8/32/32/64.

Autre modification importantes: un pointeur sera sur 8 bytes.

En général, ok. Mais rien ne l'oblige.

Ceux qui avaient encore la mauvais habitude de caster un pointeur en int pour en extraire l'adresse auront quelques problemes.

Ceux là avaient probablement des problèmes avant. Je ne vois pas en quoi un tel cast peut être utile dans du code C++ valide.

La conversion de long vers un double n'est pas safe, puisque long (64 bit) depasse la capacite d'un double. Utiliser un long double a la place.

Je ne suis pas certain de ce que tu veux dire par safe, mais il n'a jamais été certain en convertissant un long en double puis en long de retrouver la valeur initiale.

Utiliser les identificateur pour les limites des types plutot que la valeur numerique correspondante (CHAR_BIT, CHAR_MAX, INT_MIN, ...) (voir include <climits>)

En C++ le header <limits> avec la classe numeric_limits remplace avantageusement ces valeurs.

Privilieger l'utilisation de typedef dans votre code plutot que les type predefinit.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
typedef int           s32
typedef unsigned int  u32
typedef char          s8
typedef unsigned char u8
//...

De cette facon, si un type change de grosseur d'un environnement a l'autre, les seuls changements que vous aurez a faire sera de modifier les typedef (a condition de n'utiliser que des s32, u32, etc dans votre code)

J'ai très rarement le besoin de savoir le nombre de bits qu'aura une variable (exception : Code pour écrire dans un format binaire multi-architecture, par exemple pour de la sauvegarde binaire ou de l'échange réseau binaire, mais de toute façon, dans ce genre de situation, je manipule surtout des tableaux de char, pour éviter les problèmes d'endianess). Le fait que int puisse avoir un nombre de bits variant suivant l'architecture est une feature. On est ainsi assuré en prenant int d'avoir la taille que le processeur gère le mieux. Ces typedefs me semblent donc être une mauvaise idée dans le cas général.

[Invité]

Sur un compilateur c++ 64 bit, int continuera d'etre 32 bit, long sera 64 bit, et long long sera lui ausis 64 bit. char, short, float, double et long double ne changeront pas.

Ca dépend de quel 64 bits. Il en existe pour char/short/int/long je crois des 8/16/32/64 et des 8/16/64/64, et rien n'empêche des 8/32/64/64 ou des 8/32/32/64.

Voir la petite remarque que j'avais mit a ce sujet dans le bas de mon premier post

Ceux qui avaient encore la mauvais habitude de caster un pointeur en int pour en extraire l'adresse auront quelques problemes.

Ceux là avaient probablement des problèmes avant. Je ne vois pas en quoi un tel cast peut être utile dans du code C++ valide.

J'ai deja vu a quelques reprises du code du genre: std::cout << "Adresse de p:" << (unsigned int)p;

La conversion de long vers un double n'est pas safe, puisque long (64 bit) depasse la capacite d'un double. Utiliser un long double a la place.

Je ne suis pas certain de ce que tu veux dire par safe, mais il n'a jamais été certain en convertissant un long en double puis en long de retrouver la valeur initiale.

C'est evident que long > double > long ne garantit pas de revenir au resultat initial. Par contre, long depassera la capacite d'un double lors de la conversion long > double. Probleme qui n'est pas present en 32 bit.

Privilieger l'utilisation de typedef dans votre code plutot que les type predefinit.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
typedef int           s32
typedef unsigned int  u32
typedef char          s8
typedef unsigned char u8
//...

De cette facon, si un type change de grosseur d'un environnement a l'autre, les seuls changements que vous aurez a faire sera de modifier les typedef (a condition de n'utiliser que des s32, u32, etc dans votre code)

J'ai très rarement le besoin de savoir le nombre de bits qu'aura une variable (exception : Code pour écrire dans un format binaire multi-architecture, par exemple pour de la sauvegarde binaire ou de l'échange réseau binaire, mais de toute façon, dans ce genre de situation, je manipule surtout des tableaux de char, pour éviter les problèmes d'endianess). Le fait que int puisse avoir un nombre de bits variant suivant l'architecture est une feature. On est ainsi assuré en prenant int d'avoir la taille que le processeur gère le mieux. Ces typedefs me semblent donc être une mauvaise idée dans le cas général.

Je parlais pour les cas ou il etait necessaire d'avoir un type de longueur fixe, peu importe le compilo/architecture (et pour eviter une reecriture/modification partout dans le code le cas echeant)

[tut]

et concrètement, le fait de passer de 32 à 64 bits, ça apporte quoi en plus, en mieux ? en terme de performances, etc...

[HRS]

toutes vos questions n'ont de sens qu'avec un compilateur 64 bits.
pour que ce dernier fonctionne, il faut un OS 64 bits qui lui même
nécessite une machine 64 bits.

Si vous continuer d'utiliser un compilo 32 bits sur un machine 64 bits,
il n'y aura rien de changé. Je ne suis même pas sûr qu'il y aura une
meilleure performance.

à mon avis, si compilo 64 bits alors int = 64 bits

[Aurelien.Regat-Barrel]

D'après ce que j'ai entendu, ça apporte pas grand chose en terme de performances. C'est surtout utile quand tu as besoin de bcp de mémoire.

[JolyLoic]

Au boulot on l'utilise pour une application devant gérer beaucoup de données CAO. Les perfs sont généralement un peu moins bonnes, mais on peut adresser suffisamment de mémoire pour stocker un modèle d'une voiture en mémoire.

[Higestromm]

Il n'existe pas de bibliotheques permettant de gérer ce genre de trucs quelq qu soit le compilo / plate forme ?

genre je déclare un uint32 il vas me créer un unsigned integer sur 32 bits...

Si oui ca m'intéresse

[Laurent Gomila]

Il n'existe pas de bibliotheques permettant de gérer ce genre de trucs quelq qu soit le compilo / plate forme ?

genre je déclare un uint32 il vas me créer un unsigned integer sur 32 bits...

Un jour pour m'amuser, j'avais codé un truc à base de meta-prog qui trouve un type selon la taille que tu veux. Je sais pas si ça a une grande utilité, mais c'était marrant à coder.