Je n'ai pas dit que l'on ne peut pas utiliser un adressage relatif. Je dis que l'adressage relatif ne peut pas être utilisé lorsqu'un programme appel une fonction ou un variable dans une librairie partagée, ou une librairie partagée vers une librairie partagée (et surement d'autres combinaisons). Je ne dis pas qu'un programme qui utilise une librairie partagée ne peut pas utiliser les adressages relatif ! Je dis aussi que les adresses d'un objet (j'ai pris l'exemple d'une fonction static mais c'est aussi vrai pour une variable) externe qui est stocké dans une variable est forcément l'adresse absolue. C'est principalement dans le contexte d'une fonction (if, while, etc...) que les adresses relatives sont utilisées, que le programme soit statique ou dynamique !
> qu'on utilise des adressages relatifs en 16 ou 32 bits, et qu'on ne puisse pas utiliser de librairie.
Car le compilateur ne sait pas à la compilation où va être chargée la librairie partagée (d'où l'édition de lien à l'exécution pour les librairies partagée). Et donc, il ne peut supposer que la fonction appelée (ou la variable) est à une distance tenant dans un mot inférieur à sizeof(void *) (sous un système 32 bits, sizeof(void *) = 32 et pour un système 64 bits, sizeof(void *) = 64). Donc l'appel de la fonction (ou de la variable) est codé en utilisant une adresse absolue sur 64 bits (si c'est un OS 64 bits). Notes que je n'est pas dit que c'était impossible pour une librairie static (d'édition de lien étant faite à la compilation). Je ne parle que de l'utilisation d'un objet dans une autre librairie partagée !
> Sur Amiga tu pouvais bien avoir des programmes qui n'utilisaient que des sauts relatifs, alors que l'OS était 32 bits.
Sous DOS aussi c'est possible (fichier .com comme je l'ai dit précédament). Car il n'y a pas d'utilisation de librairie partagée.
> Tu te poses de drôles de questions.
C'est pas moi qui ait posé la question (relis le thread).
> Ta question "d'optimiser le cache" n'a même pas de sens à mon avis.
J'ai répondu à une question et dis que l'on ne pouvait optimiser le cache comme c'était proposé. Et je n'ai fait aucune proposition d'optimisation de cache (relis le thread).
> Et dans le cas d'un cache, la granularité du cache est bien supérieure à la taille d'un mot mémoire.
[^] # Re: Position d'Intel sur les processeurs 64 bits grand public
Posté par matiasf . En réponse à la dépêche Position d'Intel sur les processeurs 64 bits grand public. Évalué à 1.
> qu'on utilise des adressages relatifs en 16 ou 32 bits, et qu'on ne puisse pas utiliser de librairie.
Car le compilateur ne sait pas à la compilation où va être chargée la librairie partagée (d'où l'édition de lien à l'exécution pour les librairies partagée). Et donc, il ne peut supposer que la fonction appelée (ou la variable) est à une distance tenant dans un mot inférieur à sizeof(void *) (sous un système 32 bits, sizeof(void *) = 32 et pour un système 64 bits, sizeof(void *) = 64). Donc l'appel de la fonction (ou de la variable) est codé en utilisant une adresse absolue sur 64 bits (si c'est un OS 64 bits). Notes que je n'est pas dit que c'était impossible pour une librairie static (d'édition de lien étant faite à la compilation). Je ne parle que de l'utilisation d'un objet dans une autre librairie partagée !
> Sur Amiga tu pouvais bien avoir des programmes qui n'utilisaient que des sauts relatifs, alors que l'OS était 32 bits.
Sous DOS aussi c'est possible (fichier .com comme je l'ai dit précédament). Car il n'y a pas d'utilisation de librairie partagée.
> Tu te poses de drôles de questions.
C'est pas moi qui ait posé la question (relis le thread).
> Ta question "d'optimiser le cache" n'a même pas de sens à mon avis.
J'ai répondu à une question et dis que l'on ne pouvait optimiser le cache comme c'était proposé. Et je n'ai fait aucune proposition d'optimisation de cache (relis le thread).
> Et dans le cas d'un cache, la granularité du cache est bien supérieure à la taille d'un mot mémoire.
Merci de le confirmer.