Apparemment tu t'y connais en assembleur, code machine, etc...
Mais comme j'ai dit auparavant:
Si tu déclare une valeur non-signé (unsigned).
Le compilateur saura que la représentation de cette valeur est non-signé (unsigned) vue que tu l'a déclaré ainsi et du coup qui pourrai simplement lire le registre (en admettant que ce soit aligner correctement) bit après bit pour récupérer la valeur de la variable non-signé (unsigned).
Mon raisonnement ne te plaît pas ou j'ai simplement tord et je m'obstine.
Auparavant tu m'a dit que:
Cela ne valait pas le coup de déclarer des variables uint8_t, int8_t et qu'il vaut mieux utilisé un int (le type de base) afin de garder le truc aligné.
Mais un registre est composé de sous registres, plus petit (cela va jusqu'au octet) AL et AH.
Donc je voit mal des valeurs valeurs stocker dans plusieurs registres se chevauchant...???
Puis tu me dit que dans que c'est pareil un entier non-signé (unsigned int) et un signé (int).
Pourquoi le compilateur s'emmerderait a faire un complément a 2 alors que il peut simplement lire la valeur bit après bit, dans le cas d'un non-signé (unsigned).
Peut être pour faire des additions...???
Mais le processeur peut très bien faire des additions de valeur directe ou déduites, c'est son boulot.
Il faut peut-être chercher un peu plus loin que le petit programme qui fait une addition avec des signés et des non-signés (unsigned). Par exemple analyser le code machine.
D'ailleurs pourquoi ça existe des non-signé alors si le processeur bosse avec des signé, pour l'abstraction.
Et c'est pour l'abstraction que le char et le short existe en 2 versions.
Peut-être que le processeur a un moyen de savoir, si la valeur est a calculer en signé ou non-signé.
Après il faut savoir a mon sujet que j'ai lu qu'un seule livre sur le fonctionnement d'un ordinateur et du coup du sur le fonctionnement du microprocesseur entre autres. Mais des tas d'autres en parle sans être un parfait manuel.
Et que je n'ai pratiquer l'assembleur que pendant 1 mois (32 et 64 bits, syntaxe Intel), faute aux fonctions EXTERN, ce qui m'a ramener au C.
Et puis dès que l'on rentre dans ce genre de domaine vous voulez toujours avoir raison a tout pris, alors je vous donne humblement raison et vous me laissez tranquille avec mes petites idées d'optimisation.
Ne le prends pas mal, tu voulais simplement partagé ton savoir mais moi j'en ai strictement marre qu'on me contredise a chaque fois que j'ai une idée.
Ou suis-je simplement un âne borné pour l'instant, car je ne compte pas en rester là dans les sciences informatiques et peut-être un jour ce sera moi qui aurai raison.
Merci.
PS: Si tu en le courage ont peut reprendre le truc (int8_t vs int) et (unsigned vs signed) en mettant l'accent sur la différence entre le compilateur qui produit du code machine et le processeur qui va exécuter le code machine.
PS2: Je me pose la question suivante depuis longtemps:
Est-ce-que le compilateur passe par du code assembleur pour produire du code machine ?
[^] # Re: C++ type et performances
Posté par Linuxator . En réponse au message pre-realease de battle-rage un jeu de combat a la street fighter.. Évalué à 2.
Merci pour cette réponse fort didactique.
Apparemment tu t'y connais en assembleur, code machine, etc...
Mais comme j'ai dit auparavant:
Si tu déclare une valeur non-signé (unsigned).
Le compilateur saura que la représentation de cette valeur est non-signé (unsigned) vue que tu l'a déclaré ainsi et du coup qui pourrai simplement lire le registre (en admettant que ce soit aligner correctement) bit après bit pour récupérer la valeur de la variable non-signé (unsigned).
Mon raisonnement ne te plaît pas ou j'ai simplement tord et je m'obstine.
Auparavant tu m'a dit que:
Mais un registre est composé de sous registres, plus petit (cela va jusqu'au octet) AL et AH.
Donc je voit mal des valeurs valeurs stocker dans plusieurs registres se chevauchant...???
Pourquoi le compilateur s'emmerderait a faire un complément a 2 alors que il peut simplement lire la valeur bit après bit, dans le cas d'un non-signé (unsigned).
Peut être pour faire des additions...???
Mais le processeur peut très bien faire des additions de valeur directe ou déduites, c'est son boulot.
Il faut peut-être chercher un peu plus loin que le petit programme qui fait une addition avec des signés et des non-signés (unsigned). Par exemple analyser le code machine.
D'ailleurs pourquoi ça existe des non-signé alors si le processeur bosse avec des signé, pour l'abstraction.
Et c'est pour l'abstraction que le char et le short existe en 2 versions.
Peut-être que le processeur a un moyen de savoir, si la valeur est a calculer en signé ou non-signé.
Après il faut savoir a mon sujet que j'ai lu qu'un seule livre sur le fonctionnement d'un ordinateur et du coup du sur le fonctionnement du microprocesseur entre autres. Mais des tas d'autres en parle sans être un parfait manuel.
Et que je n'ai pratiquer l'assembleur que pendant 1 mois (32 et 64 bits, syntaxe Intel), faute aux fonctions EXTERN, ce qui m'a ramener au C.
Et puis dès que l'on rentre dans ce genre de domaine vous voulez toujours avoir raison a tout pris, alors je vous donne humblement raison et vous me laissez tranquille avec mes petites idées d'optimisation.
Ne le prends pas mal, tu voulais simplement partagé ton savoir mais moi j'en ai strictement marre qu'on me contredise a chaque fois que j'ai une idée.
Ou suis-je simplement un âne borné pour l'instant, car je ne compte pas en rester là dans les sciences informatiques et peut-être un jour ce sera moi qui aurai raison.
Merci.
PS: Si tu en le courage ont peut reprendre le truc (int8_t vs int) et (unsigned vs signed) en mettant l'accent sur la différence entre le compilateur qui produit du code machine et le processeur qui va exécuter le code machine.
PS2: Je me pose la question suivante depuis longtemps:
Est-ce-que le compilateur passe par du code assembleur pour produire du code machine ?