En assembleur x86, il y a un mode pour travailler directement sur la mémoire sans passer par les registres, en cherchant sur "le ternet" j'ai trouvé cet exemple
add BYTE PTR [var], 10 — add 10 to the single byte stored at memory address var
Mais bon, si le compilateur C optimise comme un pied, tu te retrouveras avec plusieurs instructions.
Il me semble que le 68k a des instructions équivalentes.
Par contre les premiers risc "pur" doivent charger la valeur dans un registre, faire l'opération, puis renvoyer la nouvelle valeur en mémoire, ce que tu décris.
ça peut marcher, mais comme les compilateurs C n'apportent aucune garantie sur la séquence d'instructions assembleurs générée, seulement que cela fera bien ce qui est décrit.
Par exemple sur HP/UX en ~95, j'avais voulu tester le nombre d'instructions qu'il pouvait executer en // (c'était la mode des architectures superscalaire).
J'ai juste fait une boucle qui incrémentait 5 variables (ça sert à rien, mais a 100mhz, j'avais 500 mips ^^).
Et pourtant en -04, j'avais 7 lignes d'instructions, et sans optimisation une trentaine de ligne. Ce qui m'avait marqué en -O4, c'est que le test de boucle était écrit avant la dernière incrémentation, le compilateur de HP était capable de réordonner les instructions pour maximiser l'utilisation du pipeline et de la latence de décodage et d'execution. Mais les 2 versions me renvoyaient les mêmes résultat à la fin.
[^] # Re: Recouvrement
Posté par darkleon . En réponse à la dépêche IBM lance la mémoire transactionnelle dans le matériel. Évalué à -1.
En assembleur x86, il y a un mode pour travailler directement sur la mémoire sans passer par les registres, en cherchant sur "le ternet" j'ai trouvé cet exemple
add BYTE PTR [var], 10 — add 10 to the single byte stored at memory address var
Mais bon, si le compilateur C optimise comme un pied, tu te retrouveras avec plusieurs instructions.
Il me semble que le 68k a des instructions équivalentes.
Par contre les premiers risc "pur" doivent charger la valeur dans un registre, faire l'opération, puis renvoyer la nouvelle valeur en mémoire, ce que tu décris.
ça peut marcher, mais comme les compilateurs C n'apportent aucune garantie sur la séquence d'instructions assembleurs générée, seulement que cela fera bien ce qui est décrit.
Par exemple sur HP/UX en ~95, j'avais voulu tester le nombre d'instructions qu'il pouvait executer en // (c'était la mode des architectures superscalaire).
J'ai juste fait une boucle qui incrémentait 5 variables (ça sert à rien, mais a 100mhz, j'avais 500 mips ^^).
Et pourtant en -04, j'avais 7 lignes d'instructions, et sans optimisation une trentaine de ligne. Ce qui m'avait marqué en -O4, c'est que le test de boucle était écrit avant la dernière incrémentation, le compilateur de HP était capable de réordonner les instructions pour maximiser l'utilisation du pipeline et de la latence de décodage et d'execution. Mais les 2 versions me renvoyaient les mêmes résultat à la fin.