[gull] Linux sur processeur Core Duo?

[Marc SCHAEFER]

On Sat, Aug 12, 2006 at 07:15:29AM +0200, Ludwin wrote:
> Y aura-t-il une "compatibilite descendante"? Si on veut installer une
> application 32 bits sur un systeme base sur cette nouvelle architecture 64
> bits, on pourra le faire sans modifier le code source, ou est-ce que ce
> sera une condition sine qua non?

Je n'aime pas trop ce concept d'application `32' ou `64' bits, parlons
plutôt d'architecture (voire de 64-bit clean, éventuellement).

En pratique, les applications utilisent soit des types standards définis
par l'architecture pour laquelle l'application est compilée, soit sont
remplis de #if (compilation conditionnelle).

Exemple:
   man 2 read
      documente l'appel système de lecture d'un fichier

on voit que les types size_t et void * documentent les prototypes
respectivement de la taille du buffer et de l'adresse du buffer.

Si l'architecture applique le type de base pour stocker une adresse
lorsqu'elle voit (void *), tout se passera bien.

Par contre si l'application utilise `int', cela pourrait bien
fonctionner sans problème en architecture 32 bits (peut-être avec un
warning de conversion entier à pointeur, encore qu'il est tellement
facile de ne pas les voir ou de les supprimer), mais cela peut ne pas
fonctionner en 64 bits (avec ou sans warning suivant les cas).

En pratique sauf erreur sizeof(int) == sizeof(void *) en architecture 32
et 64 bits, mais ce n'est pas obligatoire. Et il y a beaucoup d'autres
problèmes liés, éventuellement même d'alignement de types de données
en mémoire.

D'autres langages de plus haut niveau ont des types mieux définis(*) que
celui du C, qui se borne à être, finalement, un bon assembleur portable.
Plus le langage est de haut niveau, moins les problèmes de
compatibilité 16/32/64 sont importants (sauf dans le cas d'utilisation
de bibliothèques non écrites dans ce langage, runtime du langage
compris!)

(*) ou au moins moins bas-niveau.

PS: désolé pour mes explications très simplifiées.