Discussion :

[Guesset]

Bonjour Kannagi,

Ben en faite non ^^
Par exemple RISC-V n'a pas de register flag.
(Je crois que le MIPS aussi mais pas sur)...

RISC comme MIPS ont des registres de flags explicites pour les opérations flottantes (FCRS...).

Mais pour les entiers; ils utilisent des opérations de branchement conditionnel intégrant comparaison et décision de branchement. C'est plus simple mais ne permet pas l'anticipation. En effet, avoir des décisions conditionnelles qui font à la fois la comparaison et l'exploitation de celle-ci pour un branchement (ou autre) oblige à ne connaître le branchement effectif qu'au dernier moment.

Ceci étant, comme la plupart des instructions CISC modifient les flags, il est difficile de faire une comparaison quelques opérations avant le branchement conditionnel en résultant. Pour favoriser les optimisations, il faudrait plutôt multiplier (2 ou 4 devraient suffire) les registres de flags ce qui permettrait l'anticipation (et non seulement la prédiction) du branchement effectif quelques opérations plus loin (genre cmp ri, rj, rfk pour registre de flag k suivi, quelques opérations plus loin, d'un jcxx addr, rfk).

Certains pensent qu'il n'y a pas de pipe sur les machines RISC (une instruction = un tick, même pour * ou / ?). C'était vrai au tout début lorsque le jeu d'instructions était vraiment réduit mais les RISC d'aujourd'hui ont bien plus plus d'instructions que les CISC d'hier. Donc le besoin de pipe réapparaît et son optimisation également.

Salut

[Kannagi]

Pour chrtophe :
Sur le net , on propose pour le carry cette solution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
unsigned carry_out_manual(unsigned a, unsigned b)
{
    unsigned sum = a+b;
    return sum < a;
}

Ce qui donne le code assembleur suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
not     a0, a0
sltu    a0, a0, a1
ret

Du coup j'imagine que y'a moyen de recuperer le NZCV par diverse astuce.
Il est vrai que sur x86, il n'ya pas d'équivalent à sltu (alors qu'il existe sur MIPS aussi ).

Mais pour les entiers; ils utilisent des opérations de branchement conditionnel intégrant comparaison et décision de branchement. C'est plus simple mais ne permet pas l'anticipation. En effet, avoir des décisions conditionnelles qui font à la fois la comparaison et l'exploitation de celle-ci pour un branchement (ou autre) oblige à ne connaître le branchement effectif qu'au dernier moment.

Bonjour , exactement celà oblige pour les branchements à les connaître au dernier moment, mais aussi de vérifier que chaque instruction ne sont pas dépendant entre elle niveau flag (comme adc).

Certains pensent qu'il n'y a pas de pipe sur les machines RISC (une instruction = un tick, même pour * ou / ?). C'était vrai au tout début lorsque le jeu d'instructions était vraiment réduit mais les RISC d'aujourd'hui ont bien plus plus d'instructions que les CISC d'hier. Donc le besoin de pipe réapparaît et son optimisation également.

Celà n'a absolument rien n'a voir avec le nombre d'instruction, le ARM quand il est apparu avait un pipe de 3 étages, et le MIPS de 5 étages.
C'est plutôt le contraire, les processeur RISC se pipeline bien comparé aux CISC.

Disons que les besoins d'optimisation actuel (comparé aux années 80/90) ont changé, en in order avoir un register flag est pas gênant, et avant on était seulement en in order.
Mais vu que pour les hautes performances on utilise que du Out of order, les processeurs actuel sont pensée pour celui là.

[Guesset]

Bonjour Kannagi,

...Ce qui donne le code assembleur suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
not     a0, a0
sltu    a0, a0, a1
ret

Ce code asm est partiel, l'addition n'y figue pas. En x86, le code complet ressemblera à un truc du genre : add eax, edx; setc al; ret;

...exactement celà oblige pour les branchements à les connaître au dernier moment, mais aussi de vérifier que chaque instruction ne sont pas dépendant entre elle niveau flag (comme adc)...

Donc pas d'anticipation. L'exemple adc sur les dépendances flag qu'il faudrait vérifier pour chaque instruction montre le contraire. adc est une variante de l'addition qui reprend le carry (d'où le c) pour cascader l'addition (BigInt notamment). Si cette extension n'est pas l'objectif, on utilise add sans dépendance flag. C'est donc une dépendance affichée et choisie.

...Celà n'a absolument rien n'a voir avec le nombre d'instruction, le ARM quand il est apparu avait un pipe de 3 étages, et le MIPS de 5 étages.
C'est plutôt le contraire, les processeur RISC se pipeline bien comparé aux CISC.

Plus le jeu d'instructions grandit, plus il y a des instructions complexes qui ne peuvent s'exécuter en un seul cycle. Le pipe, en découpant les instructions en micro-ops, permet de maintenir un flux de traitement élevé malgré cela. C'est pourquoi le nombre d'étages ne cesse de croître dans toutes les architectures.

Disons que les besoins d'optimisation actuel (comparé aux années 80/90) ont changé, en in order avoir un register flag est pas gênant, et avant on était seulement en in order.
Mais vu que pour les hautes performances on utilise que du Out of order, les processeurs actuel sont pensée pour celui là

Croire qu'un registre de flags crée des dépendances est faux. Les dépendances aux flags sont limitées et explicites comme le c de adc. En revanche add ne dépend en rien des flags positionnées par les opérations précédentes. En résumé, le out of order n'est pas impliqué par l'existence d'un registre de flags. Sinon, pourquoi les RISC les auraient reconduits (fscr...) pour les instructions flottantes ?

En revanche, si nous avions plusieurs registres indexés de flags, le out of order ne serait même plus contraint par ces dépendances choisies. Mais peut être existent-ils déjà des registres de flags fantômes comme il existe des registres classiques fantômes. Même si cela est, je préférerais une gestion explicite accessible par le compilateur plutôt qu'une optimisation locale à la CPU.

Salut

[Kannagi]

Bonjour, ah ben on est pas du tout d'accord

Bonjour Kannagi,
Plus le jeu d'instructions grandit, plus il y a des instructions complexes qui ne peuvent s'exécuter en un seul cycle. Le pipe, en découpant les instructions en micro-ops, permet de maintenir un flux de traitement élevé malgré cela. C'est pourquoi le nombre d'étages ne cesse de croître dans toutes les architectures.

Ah non , c'est quasi impossible de faire toute les instructions en 1 cycle même avec que des instructions simple (sans baisser drastiquement la fréquence), et je parle même d'un simple add là .
On peut avoir des instructions plus complexe (SIMD, des load/store complexe) sans avoir des pipelines grandes.

Si les pipelines grandissent ,ce n'est pas forcément à cause des instructions complexe, mais que le OoO demande un pipeline bien plus grande, en in order un proc RISC une pipe de 5-6 étages suffit que ça soit MIPS/PowerPC/ARM ou autre

Bref il n'y a aucun lien entre instruction complexe et pipeline.
Le pipeline est né avec les premiers ARM et MIPS, il n'ont jamais eu aucun "pipeline".
Mais avec 3 étages par exemple , il n'y a pas de pipeline stall, donc c'est comme si tout se faisait en 1 cycle.

Croire qu'un registre de flags crée des dépendances est faux. Les dépendances aux flags sont limitées et explicites comme le c de adc. En revanche add ne dépend en rien des flags positionnées par les opérations précédentes. En résumé, le out of order n'est pas impliqué par l'existence d'un registre de flags. Sinon, pourquoi les RISC les auraient reconduits (fscr...) pour les instructions flottantes ?

Ce n'est pas une croyance, si tu il y'a des instructions adc, il y'a dépendance (tu ne peux pas exécuter dans le désordre), bien sur que c'est choisis par le compilo ou le programmeur, mais la CPU qu'est qu'elle en sait que tu vas pas l'utiliser ?
Nullement, donc il est obligé de vérifier au cas où.
Et si y'a dépendance, alors il est obligé soit de réorganise en prenant en compte cette dépendance et/ou d'avoir un renaming register pour les flags.

[chrtophe]

Si j'ai bien compris, avec un RISC, on utilise des instructions d'additions avec branchement conditionnels. J'en conclus que la CPU doit avoir des flags en interne mais non accessibles.

De toute façon au niveau C, c'est la même chose, on utilise des fonctions spécifiques au compilateur.

[Guesset]

Bonjour Kannagi,

Il faut que deux pierres se heurtent pour que jaillisse l'étincelle. Ca tombe bien, j'ai la tête dure

...c'est quasi impossible de faire toute les instructions en 1 cycle même avec que des instructions simple (sans baisser drastiquement la fréquence), et je parle même d'un simple add là .

Extrait

Instruction	Operands	Cycles	Latency
ADD, SUB	r, r/i	1	1

Aujourd'hui les opérations le plus simples s'exécutent en un cycle (1 µop dans le pipe). Il y a eu une époque où un décalage (<< ou >>) prenait plusieurs cycles, puis un seul pour un décalage unitaire, et enfin un seul pour tout décalage (registre à registre).
Mais dans un même temps le nombre d'opérations a cru. Et les nouvelles n'étaient pas aussi simples. Egalement dans ce même temps la largeur des opérandes est passé de 8, 16, 32, 64 et plus. Or certaines opérations aussi peu exotiques que la multiplication ou la division présentent une forte dépendance temps à la taille des opérandes. Tout cela augmente le besoin en étages de pipe.

Mais ce n'est effectivement pas le seul moteur, la multiplication des unités (ALU et autres) au sein d'un même core induit une possibilité de // qui démultiplie les besoins en niveaux de pipe (beaucoup plus que le simple réagencement de séquences d'instructions (OoO)). Les instructions vectorielles participent aussi à cette croissance mais leur contribution semble modérée.
Aujourd'hui on se balade entre 7 et plus d'une trentaine d'étages.

...si tu il y'a des instructions adc, il y'a dépendance (tu ne peux pas exécuter dans le désordre), bien sur que c'est choisis par le compilo ou le programmeur, mais la CPU qu'est qu'elle en sait que tu vas pas l'utiliser ?

adc est un code qui utilise par définition le flag carry (il n'y a nulle incertitude). Comment la CPU le devine-t-elle ? Le code adc est différent du code add qui lui ne dépend pas des flags. Il n'a donc rien à vérifier, la CPU sait d'emblée que adc dépend de c et il connait la dernière opération qui modifie ce flag. C'est une dépendance comme celle qui existe entre not a0, a0 et sltu a0, a0, a1 (réutilisation de résultat). La dépendance limite la réorganisation du code mais ne la supprime pas. Si le programmeur ou le compilateur utilise adc, c'est qu'il a besoin de tenir compte d'une retenue provenant d'un calcul préalable. Cette dépendance se manifestera toujours quelque soit l'architecture. Comme il fallait avoir fait l'addition des unités pour pouvoir faire celle de dizaines puis...

Salut

[Kannagi]

Ce n'est pas forcément le bon topic pour débattre , mais oui dans ton screen add/sub , se fait en un cycle , ça n’emperche pas d'avoir un pipe de 5 étages ou plus .

Sinon tu parle "dans un temps ne t’inquiète pas je connais assez bien le temps de cycle du 6502,z80 ,8086 , M68000 et consort.
Comme j'ai pu faire aussi du MIPS/RISC-V / ARMet compagnie ^^

Quand je parle qu'une instruction fasse un cycle , je ne parle pas de son temps d’exécution (qui fait bien un cycle) mais de l'ensemble qui lui ne fais pas un cycle, que ça soit aujourd'hui ou dans le passé.
Le pipeline divise juste les instructions en plusieurs cycle pour les exécuter en parallèle, ce qui donne l'impression que chaque instruction fasse un cycle
(Je ne parle pas du supersclaire au cas où).

Bref pour dire que la complexité d'instruction joue peu sur le pipeline,mais si on monte à 30 étages , c'est pas vraiment pour la complexité des instructions , mais que le OoO c'est minimun 12 étages.

[kick54]

Et comment tu fais pour vérifier une retenue ? un dépassement ?

Bonjour,
Il existe des options de compilation de GCC permettant de récupérer les flags, cf :
https://gcc.gnu.org/onlinedocs/gcc-3...0Gen%20Options

-ftrapv
This option generates traps for signed overflow on addition, subtraction, multiplication operations.

-fwrapv
This option instructs the compiler to assume that signed arithmetic overflow of addition, subtraction and multiplication wraps around using twos-complement representation. This flag enables some optimizations and disables other. This option is enabled by default for the Java front-end, as required by the Java language specification.

Comme souvent tout est dans la doc ;-)
Bonne journée

[kick54]

Bonjour,

Je voulais comment détecter un overflow sur une opération sur des int.

Je ne code pas, c'est juste une interrogation.

Bonjour chrtophe,

Je pense qu'il faudrait toujours détecter ce genre d'erreur la qualité du logiciel ne peut qu'en être améliorée.

Je complète mon commentaire avec un premier exemple qui traite le débordement d'entier en utilisant :
l'option de compilation -ftrapv, et
l'interception du signal SIGABRT

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
 
 
/** err1.c **/
 
#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <signal.h>
#include <stdint.h>
 
 
void h1(int signal)
{
	printf("Interception signal SIGABRT (%d)\n", SIGABRT);
	exit(1);
}
 
int main(){
 
	int a = INT32_MAX ;
 
	signal(SIGABRT,h1);
 
	printf("Taille int = %d\n\t a= %d\n\t a+1 = ...",sizeof(int), a);
	printf("%d\n", a+1);	
 
	return(0);
}
 
 
/********* Compilation et exécution (Cygwin - gcc version 11.4.0)
$ gcc -ftrapv  err1.c -o err1
$ ./err1
Taille int = 4
         a= 2147483647
         a+1 = ...Interception signal SIGABRT (6)
 
Compilation sans l'option -ftrapv
$ gcc  err1.c -o err1
$ ./err1
Taille int = 4
         a= 2147483647
         a+1 = ...-2147483648
 
*/

Pour d'autres cas d'erreur, comme la division par zéro, l'interception par signal() de SIGFPE peut aussi être utile ...
Bien que la division par zéro est de toute façon détectée et provoque l'interruption du programme,
le point où elle se produit, peut être plus difficile (ou pas ;-) à localiser sans l'interception du signal.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
 
/** err2.c **/
 
#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <signal.h>
#include <stdint.h>
 
void h2(int signal)
{
	printf("Interception signal SIGFPE (%d)\n", SIGFPE);
	exit(2);
}
 
int main(){
 
	int a = INT32_MAX ;
	int b = 0 ;
 
	signal(SIGFPE,h2);
 
	printf("a / 0 = ...");			
	printf("%d\n",a/b);
 
	return(0) ;
}
 
/********* Compilation et exécution (Cygwin - gcc version 11.4.0)
$ gcc err2.c -o err2
$ ./err2
a / 0 = ...Interception signal SIGFPE (8)
 
 
$ gcc  err2.c -o err2
$ ./err2
Floating point exception
 
 
*/

[kick54]

Le fait qu'un exemple soit simple est souvent une bonne chose, non ?
C'est vrai, il se voulait plutôt représentatif des erreurs d'adressage non détectées et qui provoquent un UB. Parce que pour l'overflow effectivement, sauf à "voir" que la valeur finale est plus petite que la valeur d'origine (on présume que celle-ci est censée croître dans l'opération) il n'y a pas d'erreur à l'exécution (ni même de UB).


Un de mes profs d'info avait parlé de sinus négatif calculé en unsigned (légende urbaine issue du téléphone arabe probablement) et le lien wiki est plus précis. Ou alors il parlait d'un autre crash...

Bonjour,
Pareil, un prof citait l'exemple de bugs mémorables dont celui où le résultat de calcul d'un sinus devenait brutalement négatif au passage de l'équateur (la latitude changeant de signe), et le prof précisait que l'avion en pilotage automatique se mettait à voler sur le dos...
... De même je n'ai jamais su si c'était avéré ou une légende

[Guesset]

Bonjour Chrtophe,

...J'en conclus que la CPU doit avoir des flags en interne mais non accessibles...

En fait, ce sont certaines instructions qui ne font pas un appel explicite aux flags.

Mais ceux-ci existent bien dans le registre CPSR (Current Program Status Register) : N pour < 0, Z pour == 0, C pour carry, V pous oVerflow, Q pous overflow avec saturation, GE pour >=. Il peut être lu et écrit via l'instruction MSR.

Salut