Re: Position d'Intel sur les processeurs 64 bits grand public

Il n'y aura pas une appli qui tourne parfois en 32 bits et parfois en 64 bits. C'est soit tout l'un ou tout l'autre pour des raisons évidente d'édition de lien. On ne peut pas faire l'édition de lien d'un .o avec sizeof(void *) = 4 et d'un autre avec sizeof(void *) = 8. Image "titi = toto ;" avec titi (void *) d'un .o 32 bits et toto (void *) d'un .o 64 bits. Notes que ça implique d'avoir une libc 32 bits et une 64 bits pour faire tournée des programmes 32 bits ou 64 bits.> et de ne transfere que les bits significatifs ! Ça ne change rien. imagenons en 0x1000 qu'il y a : 0x 00 00 00 00 00 00 00 01 Le cache pour s'avoir qu'il y a cette valeur doit allé lire les 8 octets. Il ne peut pas préssuposer qu'il y a 7 octets à 0. Si le bus fait 8 octets, c'est aussi rapide de lire 1 octet que 8 (du moins s'ils sont alignés, sinon il faut au plus deux opérations de lecture). Enfin, dans un programme toute les valeurs possibles d'un short int, int, long, etc peuvent être utilisées. Donc ça ne laisse pas la possibilité au cache de faire une convention du type : 0x 07 01 => 7 octets à 0 puis 7 car 0x 07 01 c'est aussi un short int ou 2 caractères. A moins que le cache ajoute un octet pour indiquer le type. Or le cache n'est pas sencé connaitre le type des données qu'il lit. C'est comme les caches des disques dure. Ils ne savent pas le type de données lues/écrites.