Le Fri, 22 Jan 2010 10:13:13 +0000, JKB a écrit :Le 22-01-2010, ? propos de
Re: swap en RAM (anciennement : Lettre à M.D.,
Toxico Nimbus ?crivait dans fr.comp.os.linux.configuration :Le Fri, 22 Jan 2010 01:56:51 +0000, Yves Lambert a écrit :(1) Le chargement d'une page mémoire ou sa recopie à l'identique dans
une autre page) est beaucoup moins coûteux que le chargement ou
l'écriture sur un périphérique lent (disque dur). Sur un processeur à
pipeline, ça ne fait un trou que d'une instruction si je ne m'abuse.
L'erreur de page est détecté au décodage de l'instruction, alors que
les chargement de pages depuis un périphérique lent (plus lent que la
RAM le lg se fait sur des milliers d'instructions (quelques dizaines
de millisecondes de latence - de quoi vider le pipe-line et introduire
un LAG durant lequel le processeur fonctionne sur une seule patte
pendant tout le remplissage.
En même temps, l'exeption défaut de page provoque nécessairement un
passage en mode privilégié, donc un contexte-switch avec vidage de
pipe- line mais aussi sauvegarde/restauration de contexte de vidage de
cache (en partie). Au milieu de tout ça, la vidage du pipe-line est
négligeable.
Vidage de pipe-line ? Je ne vois pas pourquoi. Enfin, si, sur un x86,
je vois, mais dans le cas général de processeur bien fichu, c'est faux.
Quand tu en arrives à exécuter l'instruction qui déclenche un défaut de page,
le code d'interruption doit être exécuté immédiatement, d'où la nécessité de
vider le pipe-line pour éviter que des instruction suivantes ne soient
exécutées entre-temps. Donc il y aura forcément vidage du pipe-line quelle
que soit l'architecture... Ou alors je suis franchement à l'ouest.
Le Fri, 22 Jan 2010 10:13:13 +0000, JKB a écrit :
Le 22-01-2010, ? propos de
Re: swap en RAM (anciennement : Lettre à M.D.,
Toxico Nimbus ?crivait dans fr.comp.os.linux.configuration :
Le Fri, 22 Jan 2010 01:56:51 +0000, Yves Lambert a écrit :
(1) Le chargement d'une page mémoire ou sa recopie à l'identique dans
une autre page) est beaucoup moins coûteux que le chargement ou
l'écriture sur un périphérique lent (disque dur). Sur un processeur à
pipeline, ça ne fait un trou que d'une instruction si je ne m'abuse.
L'erreur de page est détecté au décodage de l'instruction, alors que
les chargement de pages depuis un périphérique lent (plus lent que la
RAM le lg se fait sur des milliers d'instructions (quelques dizaines
de millisecondes de latence - de quoi vider le pipe-line et introduire
un LAG durant lequel le processeur fonctionne sur une seule patte
pendant tout le remplissage.
En même temps, l'exeption défaut de page provoque nécessairement un
passage en mode privilégié, donc un contexte-switch avec vidage de
pipe- line mais aussi sauvegarde/restauration de contexte de vidage de
cache (en partie). Au milieu de tout ça, la vidage du pipe-line est
négligeable.
Vidage de pipe-line ? Je ne vois pas pourquoi. Enfin, si, sur un x86,
je vois, mais dans le cas général de processeur bien fichu, c'est faux.
Quand tu en arrives à exécuter l'instruction qui déclenche un défaut de page,
le code d'interruption doit être exécuté immédiatement, d'où la nécessité de
vider le pipe-line pour éviter que des instruction suivantes ne soient
exécutées entre-temps. Donc il y aura forcément vidage du pipe-line quelle
que soit l'architecture... Ou alors je suis franchement à l'ouest.
Le Fri, 22 Jan 2010 10:13:13 +0000, JKB a écrit :Le 22-01-2010, ? propos de
Re: swap en RAM (anciennement : Lettre à M.D.,
Toxico Nimbus ?crivait dans fr.comp.os.linux.configuration :Le Fri, 22 Jan 2010 01:56:51 +0000, Yves Lambert a écrit :(1) Le chargement d'une page mémoire ou sa recopie à l'identique dans
une autre page) est beaucoup moins coûteux que le chargement ou
l'écriture sur un périphérique lent (disque dur). Sur un processeur à
pipeline, ça ne fait un trou que d'une instruction si je ne m'abuse.
L'erreur de page est détecté au décodage de l'instruction, alors que
les chargement de pages depuis un périphérique lent (plus lent que la
RAM le lg se fait sur des milliers d'instructions (quelques dizaines
de millisecondes de latence - de quoi vider le pipe-line et introduire
un LAG durant lequel le processeur fonctionne sur une seule patte
pendant tout le remplissage.
En même temps, l'exeption défaut de page provoque nécessairement un
passage en mode privilégié, donc un contexte-switch avec vidage de
pipe- line mais aussi sauvegarde/restauration de contexte de vidage de
cache (en partie). Au milieu de tout ça, la vidage du pipe-line est
négligeable.
Vidage de pipe-line ? Je ne vois pas pourquoi. Enfin, si, sur un x86,
je vois, mais dans le cas général de processeur bien fichu, c'est faux.
Quand tu en arrives à exécuter l'instruction qui déclenche un défaut de page,
le code d'interruption doit être exécuté immédiatement, d'où la nécessité de
vider le pipe-line pour éviter que des instruction suivantes ne soient
exécutées entre-temps. Donc il y aura forcément vidage du pipe-line quelle
que soit l'architecture... Ou alors je suis franchement à l'ouest.
Quand tu en arrives à exécuter l'instruction qui déclenche un défaut de
page, le code d'interruption doit être exécuté immédiatement, d'où la
nécessité de vider le pipe-line pour éviter que des instruction
suivantes ne soient exécutées entre-temps. Donc il y aura forcément
vidage du pipe-line quelle que soit l'architecture... Ou alors je suis
franchement à l'ouest.
Il faudrait que j'ouvre mes specs sparc v8 et v9, mais de mémoire, sur
les sparc (et àmha, c'est du même tonneau sur tous les RISC),
l'interruption est exécutée dans le flot d'instruction comme un
branchement, donc après l'instruction en cours de décodage (et non
d'exécution). Les données immédiates sont dans les opcodes et l'autre
mode d'adressage est l'adressage direct (pour faire simple). Les
défauts de page sont donc très faciles à régler durant le décodage et,
au pire (mais alors vraiment au pire), tu as un ou deux cycles de
retard dû à l'accès mémoire hors cache. Jamais le pipe-line n'a été
touché dans cette histoire.
Maintenant, sur un CISC façon x86, la longueur des instructions
(traitement et longueur en bits) fait que tu vas forcément avoir un
cassage de gueule du pipe-line, mais on compare deux choses
incomparables.
Quand tu en arrives à exécuter l'instruction qui déclenche un défaut de
page, le code d'interruption doit être exécuté immédiatement, d'où la
nécessité de vider le pipe-line pour éviter que des instruction
suivantes ne soient exécutées entre-temps. Donc il y aura forcément
vidage du pipe-line quelle que soit l'architecture... Ou alors je suis
franchement à l'ouest.
Il faudrait que j'ouvre mes specs sparc v8 et v9, mais de mémoire, sur
les sparc (et àmha, c'est du même tonneau sur tous les RISC),
l'interruption est exécutée dans le flot d'instruction comme un
branchement, donc après l'instruction en cours de décodage (et non
d'exécution). Les données immédiates sont dans les opcodes et l'autre
mode d'adressage est l'adressage direct (pour faire simple). Les
défauts de page sont donc très faciles à régler durant le décodage et,
au pire (mais alors vraiment au pire), tu as un ou deux cycles de
retard dû à l'accès mémoire hors cache. Jamais le pipe-line n'a été
touché dans cette histoire.
Maintenant, sur un CISC façon x86, la longueur des instructions
(traitement et longueur en bits) fait que tu vas forcément avoir un
cassage de gueule du pipe-line, mais on compare deux choses
incomparables.
Quand tu en arrives à exécuter l'instruction qui déclenche un défaut de
page, le code d'interruption doit être exécuté immédiatement, d'où la
nécessité de vider le pipe-line pour éviter que des instruction
suivantes ne soient exécutées entre-temps. Donc il y aura forcément
vidage du pipe-line quelle que soit l'architecture... Ou alors je suis
franchement à l'ouest.
Il faudrait que j'ouvre mes specs sparc v8 et v9, mais de mémoire, sur
les sparc (et àmha, c'est du même tonneau sur tous les RISC),
l'interruption est exécutée dans le flot d'instruction comme un
branchement, donc après l'instruction en cours de décodage (et non
d'exécution). Les données immédiates sont dans les opcodes et l'autre
mode d'adressage est l'adressage direct (pour faire simple). Les
défauts de page sont donc très faciles à régler durant le décodage et,
au pire (mais alors vraiment au pire), tu as un ou deux cycles de
retard dû à l'accès mémoire hors cache. Jamais le pipe-line n'a été
touché dans cette histoire.
Maintenant, sur un CISC façon x86, la longueur des instructions
(traitement et longueur en bits) fait que tu vas forcément avoir un
cassage de gueule du pipe-line, mais on compare deux choses
incomparables.
Le Wed, 27 Jan 2010 09:53:59 +0000, JKB a écrit :Quand tu en arrives à exécuter l'instruction qui déclenche un défaut de
page, le code d'interruption doit être exécuté immédiatement, d'où la
nécessité de vider le pipe-line pour éviter que des instruction
suivantes ne soient exécutées entre-temps. Donc il y aura forcément
vidage du pipe-line quelle que soit l'architecture... Ou alors je suis
franchement à l'ouest.
Il faudrait que j'ouvre mes specs sparc v8 et v9, mais de mémoire, sur
les sparc (et àmha, c'est du même tonneau sur tous les RISC),
l'interruption est exécutée dans le flot d'instruction comme un
branchement, donc après l'instruction en cours de décodage (et non
d'exécution). Les données immédiates sont dans les opcodes et l'autre
mode d'adressage est l'adressage direct (pour faire simple). Les
défauts de page sont donc très faciles à régler durant le décodage et,
au pire (mais alors vraiment au pire), tu as un ou deux cycles de
retard dû à l'accès mémoire hors cache. Jamais le pipe-line n'a été
touché dans cette histoire.
Pour autant que je sache, tu devras nécessairement exécuter ton code de
traitement de l'interruption, alors il faudra bien vider le pipe-line avant
de commencer à exécuter le code du vecteur.
Maintenant, sur un CISC façon x86, la longueur des instructions
(traitement et longueur en bits) fait que tu vas forcément avoir un
cassage de gueule du pipe-line, mais on compare deux choses
incomparables.
Si tu rajoute la prédication de branchement made in intel, tu obtiens un
bordel abominable.
Le Wed, 27 Jan 2010 09:53:59 +0000, JKB a écrit :
Quand tu en arrives à exécuter l'instruction qui déclenche un défaut de
page, le code d'interruption doit être exécuté immédiatement, d'où la
nécessité de vider le pipe-line pour éviter que des instruction
suivantes ne soient exécutées entre-temps. Donc il y aura forcément
vidage du pipe-line quelle que soit l'architecture... Ou alors je suis
franchement à l'ouest.
Il faudrait que j'ouvre mes specs sparc v8 et v9, mais de mémoire, sur
les sparc (et àmha, c'est du même tonneau sur tous les RISC),
l'interruption est exécutée dans le flot d'instruction comme un
branchement, donc après l'instruction en cours de décodage (et non
d'exécution). Les données immédiates sont dans les opcodes et l'autre
mode d'adressage est l'adressage direct (pour faire simple). Les
défauts de page sont donc très faciles à régler durant le décodage et,
au pire (mais alors vraiment au pire), tu as un ou deux cycles de
retard dû à l'accès mémoire hors cache. Jamais le pipe-line n'a été
touché dans cette histoire.
Pour autant que je sache, tu devras nécessairement exécuter ton code de
traitement de l'interruption, alors il faudra bien vider le pipe-line avant
de commencer à exécuter le code du vecteur.
Maintenant, sur un CISC façon x86, la longueur des instructions
(traitement et longueur en bits) fait que tu vas forcément avoir un
cassage de gueule du pipe-line, mais on compare deux choses
incomparables.
Si tu rajoute la prédication de branchement made in intel, tu obtiens un
bordel abominable.
Le Wed, 27 Jan 2010 09:53:59 +0000, JKB a écrit :Quand tu en arrives à exécuter l'instruction qui déclenche un défaut de
page, le code d'interruption doit être exécuté immédiatement, d'où la
nécessité de vider le pipe-line pour éviter que des instruction
suivantes ne soient exécutées entre-temps. Donc il y aura forcément
vidage du pipe-line quelle que soit l'architecture... Ou alors je suis
franchement à l'ouest.
Il faudrait que j'ouvre mes specs sparc v8 et v9, mais de mémoire, sur
les sparc (et àmha, c'est du même tonneau sur tous les RISC),
l'interruption est exécutée dans le flot d'instruction comme un
branchement, donc après l'instruction en cours de décodage (et non
d'exécution). Les données immédiates sont dans les opcodes et l'autre
mode d'adressage est l'adressage direct (pour faire simple). Les
défauts de page sont donc très faciles à régler durant le décodage et,
au pire (mais alors vraiment au pire), tu as un ou deux cycles de
retard dû à l'accès mémoire hors cache. Jamais le pipe-line n'a été
touché dans cette histoire.
Pour autant que je sache, tu devras nécessairement exécuter ton code de
traitement de l'interruption, alors il faudra bien vider le pipe-line avant
de commencer à exécuter le code du vecteur.
Maintenant, sur un CISC façon x86, la longueur des instructions
(traitement et longueur en bits) fait que tu vas forcément avoir un
cassage de gueule du pipe-line, mais on compare deux choses
incomparables.
Si tu rajoute la prédication de branchement made in intel, tu obtiens un
bordel abominable.
Pour autant que je sache, tu devras nécessairement exécuter ton code de
traitement de l'interruption, alors il faudra bien vider le pipe-line
avant de commencer à exécuter le code du vecteur.
Oui, et alors ? La profondeur du RISC susnommé est de 3 cycles, si ma
mémoire est bonne, ce qui fait que lorsqu'une interruption arrive, tu
finis de traiter l'instruction en cours d'exécution, tu pousses
l'interruption, mais entre-temps, tu exécutes l'instruction qui était
en décodage lors de l'arrivée de l'interruption. Résultat des courses,
ton pipe-line n'est pas tombé.
Corrolaire amusant et casse gueule sur les Sparc :
inst 1
inst 2
call subroutine
inst 3
inst 4
l'instruction inst 3 est effectuée _avant_ le saut. Charge à toi de
calculer l'adresse de retour pour ne pas effectuer deux fois inst 3. Tu
as de la chance, Monsieur sparc a prévu un ret qui est un saut avec une
adresse calculée avec offset. C'est pour ça qu'on voit assez souvent :
inst 1
inst 2
call subroutine
nop
inst 3
inst 4
Lorsqu'on sait que nop est en fait or $0,$0,$0... C'est fou le nombre
d'étudiants et de stagiaires que j'ai pu coincer sur ce truc ;-)
Maintenant, sur un CISC façon x86, la longueur des instructions
(traitement et longueur en bits) fait que tu vas forcément avoir un
cassage de gueule du pipe-line, mais on compare deux choses
incomparables.
Si tu rajoute la prédication de branchement made in intel, tu obtiens
un bordel abominable.
Je parle de processeurs _propres_. Les amd et intel ne sont pas ce que
j'appelle des processeurs propres, ni même efficaces, d'ailleurs.
Pour autant que je sache, tu devras nécessairement exécuter ton code de
traitement de l'interruption, alors il faudra bien vider le pipe-line
avant de commencer à exécuter le code du vecteur.
Oui, et alors ? La profondeur du RISC susnommé est de 3 cycles, si ma
mémoire est bonne, ce qui fait que lorsqu'une interruption arrive, tu
finis de traiter l'instruction en cours d'exécution, tu pousses
l'interruption, mais entre-temps, tu exécutes l'instruction qui était
en décodage lors de l'arrivée de l'interruption. Résultat des courses,
ton pipe-line n'est pas tombé.
Corrolaire amusant et casse gueule sur les Sparc :
inst 1
inst 2
call subroutine
inst 3
inst 4
l'instruction inst 3 est effectuée _avant_ le saut. Charge à toi de
calculer l'adresse de retour pour ne pas effectuer deux fois inst 3. Tu
as de la chance, Monsieur sparc a prévu un ret qui est un saut avec une
adresse calculée avec offset. C'est pour ça qu'on voit assez souvent :
inst 1
inst 2
call subroutine
nop
inst 3
inst 4
Lorsqu'on sait que nop est en fait or $0,$0,$0... C'est fou le nombre
d'étudiants et de stagiaires que j'ai pu coincer sur ce truc ;-)
Maintenant, sur un CISC façon x86, la longueur des instructions
(traitement et longueur en bits) fait que tu vas forcément avoir un
cassage de gueule du pipe-line, mais on compare deux choses
incomparables.
Si tu rajoute la prédication de branchement made in intel, tu obtiens
un bordel abominable.
Je parle de processeurs _propres_. Les amd et intel ne sont pas ce que
j'appelle des processeurs propres, ni même efficaces, d'ailleurs.
Pour autant que je sache, tu devras nécessairement exécuter ton code de
traitement de l'interruption, alors il faudra bien vider le pipe-line
avant de commencer à exécuter le code du vecteur.
Oui, et alors ? La profondeur du RISC susnommé est de 3 cycles, si ma
mémoire est bonne, ce qui fait que lorsqu'une interruption arrive, tu
finis de traiter l'instruction en cours d'exécution, tu pousses
l'interruption, mais entre-temps, tu exécutes l'instruction qui était
en décodage lors de l'arrivée de l'interruption. Résultat des courses,
ton pipe-line n'est pas tombé.
Corrolaire amusant et casse gueule sur les Sparc :
inst 1
inst 2
call subroutine
inst 3
inst 4
l'instruction inst 3 est effectuée _avant_ le saut. Charge à toi de
calculer l'adresse de retour pour ne pas effectuer deux fois inst 3. Tu
as de la chance, Monsieur sparc a prévu un ret qui est un saut avec une
adresse calculée avec offset. C'est pour ça qu'on voit assez souvent :
inst 1
inst 2
call subroutine
nop
inst 3
inst 4
Lorsqu'on sait que nop est en fait or $0,$0,$0... C'est fou le nombre
d'étudiants et de stagiaires que j'ai pu coincer sur ce truc ;-)
Maintenant, sur un CISC façon x86, la longueur des instructions
(traitement et longueur en bits) fait que tu vas forcément avoir un
cassage de gueule du pipe-line, mais on compare deux choses
incomparables.
Si tu rajoute la prédication de branchement made in intel, tu obtiens
un bordel abominable.
Je parle de processeurs _propres_. Les amd et intel ne sont pas ce que
j'appelle des processeurs propres, ni même efficaces, d'ailleurs.
Le Wed, 27 Jan 2010 16:32:48 +0000, JKB a écrit :Pour autant que je sache, tu devras nécessairement exécuter ton code de
traitement de l'interruption, alors il faudra bien vider le pipe-line
avant de commencer à exécuter le code du vecteur.
Oui, et alors ? La profondeur du RISC susnommé est de 3 cycles, si ma
mémoire est bonne, ce qui fait que lorsqu'une interruption arrive, tu
finis de traiter l'instruction en cours d'exécution, tu pousses
l'interruption, mais entre-temps, tu exécutes l'instruction qui était
en décodage lors de l'arrivée de l'interruption. Résultat des courses,
ton pipe-line n'est pas tombé.
Je commence à comprendre, le mécanisme des deux PC permet de retomber sur ses
pattes même si l'instruction suivante était un branchement. Toujours est-il
que un instruction produit un défaut de page à l'étage "accès mémoire", tu
peux toujours avoir un autre défaut de page à l'étage "instruction fetch" avant
d'avoir pu traiter le premier, là c'est plus que casse-gueule.
Corrolaire amusant et casse gueule sur les Sparc :
inst 1
inst 2
call subroutine
inst 3
inst 4
l'instruction inst 3 est effectuée _avant_ le saut. Charge à toi de
calculer l'adresse de retour pour ne pas effectuer deux fois inst 3. Tu
as de la chance, Monsieur sparc a prévu un ret qui est un saut avec une
adresse calculée avec offset. C'est pour ça qu'on voit assez souvent :
inst 1
inst 2
call subroutine
nop
inst 3
inst 4
Lorsqu'on sait que nop est en fait or $0,$0,$0... C'est fou le nombre
d'étudiants et de stagiaires que j'ai pu coincer sur ce truc ;-)
C'est d'ailleurs assez couillon, pourquoi ne pas compiler
inst 1
call subroutine
inst 2
inst 3
...
(Mis à part quand inst 2 calcule l'adresse du saut suivant)Maintenant, sur un CISC façon x86, la longueur des instructions
(traitement et longueur en bits) fait que tu vas forcément avoir un
cassage de gueule du pipe-line, mais on compare deux choses
incomparables.
Si tu rajoute la prédication de branchement made in intel, tu obtiens
un bordel abominable.
Je parle de processeurs _propres_. Les amd et intel ne sont pas ce que
j'appelle des processeurs propres, ni même efficaces, d'ailleurs.
Certes, je ne faisait que de la surenchère. En même temps, même des processeurs
relativiement propre comme le 68000 ont engendré des immondices comme le
68040 et surtout le 68060.
Le Wed, 27 Jan 2010 16:32:48 +0000, JKB a écrit :
Pour autant que je sache, tu devras nécessairement exécuter ton code de
traitement de l'interruption, alors il faudra bien vider le pipe-line
avant de commencer à exécuter le code du vecteur.
Oui, et alors ? La profondeur du RISC susnommé est de 3 cycles, si ma
mémoire est bonne, ce qui fait que lorsqu'une interruption arrive, tu
finis de traiter l'instruction en cours d'exécution, tu pousses
l'interruption, mais entre-temps, tu exécutes l'instruction qui était
en décodage lors de l'arrivée de l'interruption. Résultat des courses,
ton pipe-line n'est pas tombé.
Je commence à comprendre, le mécanisme des deux PC permet de retomber sur ses
pattes même si l'instruction suivante était un branchement. Toujours est-il
que un instruction produit un défaut de page à l'étage "accès mémoire", tu
peux toujours avoir un autre défaut de page à l'étage "instruction fetch" avant
d'avoir pu traiter le premier, là c'est plus que casse-gueule.
Corrolaire amusant et casse gueule sur les Sparc :
inst 1
inst 2
call subroutine
inst 3
inst 4
l'instruction inst 3 est effectuée _avant_ le saut. Charge à toi de
calculer l'adresse de retour pour ne pas effectuer deux fois inst 3. Tu
as de la chance, Monsieur sparc a prévu un ret qui est un saut avec une
adresse calculée avec offset. C'est pour ça qu'on voit assez souvent :
inst 1
inst 2
call subroutine
nop
inst 3
inst 4
Lorsqu'on sait que nop est en fait or $0,$0,$0... C'est fou le nombre
d'étudiants et de stagiaires que j'ai pu coincer sur ce truc ;-)
C'est d'ailleurs assez couillon, pourquoi ne pas compiler
inst 1
call subroutine
inst 2
inst 3
...
(Mis à part quand inst 2 calcule l'adresse du saut suivant)
Maintenant, sur un CISC façon x86, la longueur des instructions
(traitement et longueur en bits) fait que tu vas forcément avoir un
cassage de gueule du pipe-line, mais on compare deux choses
incomparables.
Si tu rajoute la prédication de branchement made in intel, tu obtiens
un bordel abominable.
Je parle de processeurs _propres_. Les amd et intel ne sont pas ce que
j'appelle des processeurs propres, ni même efficaces, d'ailleurs.
Certes, je ne faisait que de la surenchère. En même temps, même des processeurs
relativiement propre comme le 68000 ont engendré des immondices comme le
68040 et surtout le 68060.
Le Wed, 27 Jan 2010 16:32:48 +0000, JKB a écrit :Pour autant que je sache, tu devras nécessairement exécuter ton code de
traitement de l'interruption, alors il faudra bien vider le pipe-line
avant de commencer à exécuter le code du vecteur.
Oui, et alors ? La profondeur du RISC susnommé est de 3 cycles, si ma
mémoire est bonne, ce qui fait que lorsqu'une interruption arrive, tu
finis de traiter l'instruction en cours d'exécution, tu pousses
l'interruption, mais entre-temps, tu exécutes l'instruction qui était
en décodage lors de l'arrivée de l'interruption. Résultat des courses,
ton pipe-line n'est pas tombé.
Je commence à comprendre, le mécanisme des deux PC permet de retomber sur ses
pattes même si l'instruction suivante était un branchement. Toujours est-il
que un instruction produit un défaut de page à l'étage "accès mémoire", tu
peux toujours avoir un autre défaut de page à l'étage "instruction fetch" avant
d'avoir pu traiter le premier, là c'est plus que casse-gueule.
Corrolaire amusant et casse gueule sur les Sparc :
inst 1
inst 2
call subroutine
inst 3
inst 4
l'instruction inst 3 est effectuée _avant_ le saut. Charge à toi de
calculer l'adresse de retour pour ne pas effectuer deux fois inst 3. Tu
as de la chance, Monsieur sparc a prévu un ret qui est un saut avec une
adresse calculée avec offset. C'est pour ça qu'on voit assez souvent :
inst 1
inst 2
call subroutine
nop
inst 3
inst 4
Lorsqu'on sait que nop est en fait or $0,$0,$0... C'est fou le nombre
d'étudiants et de stagiaires que j'ai pu coincer sur ce truc ;-)
C'est d'ailleurs assez couillon, pourquoi ne pas compiler
inst 1
call subroutine
inst 2
inst 3
...
(Mis à part quand inst 2 calcule l'adresse du saut suivant)Maintenant, sur un CISC façon x86, la longueur des instructions
(traitement et longueur en bits) fait que tu vas forcément avoir un
cassage de gueule du pipe-line, mais on compare deux choses
incomparables.
Si tu rajoute la prédication de branchement made in intel, tu obtiens
un bordel abominable.
Je parle de processeurs _propres_. Les amd et intel ne sont pas ce que
j'appelle des processeurs propres, ni même efficaces, d'ailleurs.
Certes, je ne faisait que de la surenchère. En même temps, même des processeurs
relativiement propre comme le 68000 ont engendré des immondices comme le
68040 et surtout le 68060.
C'est d'ailleurs assez couillon, pourquoi ne pas compiler inst 1
call subroutine
inst 2
inst 3
...
On peut, mais c'est comme le RPL, ce n'est pas vraiment lisible aux non
initiés.
Certes, je ne faisait que de la surenchère. En même temps, même des
processeurs relativiement propre comme le 68000 ont engendré des
immondices comme le 68040 et surtout le 68060.
Le 6809 (et le 6309) était propre. Le 68000 est déjà une saleté
inommable en comparaison. Le passage du 6809 au 68000 a été pour moi
une calamité ne serait-ce qu'en raison du masque de pile...
C'est d'ailleurs assez couillon, pourquoi ne pas compiler inst 1
call subroutine
inst 2
inst 3
...
On peut, mais c'est comme le RPL, ce n'est pas vraiment lisible aux non
initiés.
Certes, je ne faisait que de la surenchère. En même temps, même des
processeurs relativiement propre comme le 68000 ont engendré des
immondices comme le 68040 et surtout le 68060.
Le 6809 (et le 6309) était propre. Le 68000 est déjà une saleté
inommable en comparaison. Le passage du 6809 au 68000 a été pour moi
une calamité ne serait-ce qu'en raison du masque de pile...
C'est d'ailleurs assez couillon, pourquoi ne pas compiler inst 1
call subroutine
inst 2
inst 3
...
On peut, mais c'est comme le RPL, ce n'est pas vraiment lisible aux non
initiés.
Certes, je ne faisait que de la surenchère. En même temps, même des
processeurs relativiement propre comme le 68000 ont engendré des
immondices comme le 68040 et surtout le 68060.
Le 6809 (et le 6309) était propre. Le 68000 est déjà une saleté
inommable en comparaison. Le passage du 6809 au 68000 a été pour moi
une calamité ne serait-ce qu'en raison du masque de pile...
Le Thu, 28 Jan 2010 15:01:01 +0000, JKB a écrit :C'est d'ailleurs assez couillon, pourquoi ne pas compiler inst 1
call subroutine
inst 2
inst 3
...
On peut, mais c'est comme le RPL, ce n'est pas vraiment lisible aux non
initiés.
Le RPL n'est pas non plus lisible aux initiés, ce sont juste les commentaires
qui sont lisibles.
Certes, je ne faisait que de la surenchère. En même temps, même des
processeurs relativiement propre comme le 68000 ont engendré des
immondices comme le 68040 et surtout le 68060.
Le 6809 (et le 6309) était propre. Le 68000 est déjà une saleté
inommable en comparaison. Le passage du 6809 au 68000 a été pour moi
une calamité ne serait-ce qu'en raison du masque de pile...
Je ne vois pas ce que tu appelles le masque de pile.
Le Thu, 28 Jan 2010 15:01:01 +0000, JKB a écrit :
C'est d'ailleurs assez couillon, pourquoi ne pas compiler inst 1
call subroutine
inst 2
inst 3
...
On peut, mais c'est comme le RPL, ce n'est pas vraiment lisible aux non
initiés.
Le RPL n'est pas non plus lisible aux initiés, ce sont juste les commentaires
qui sont lisibles.
Certes, je ne faisait que de la surenchère. En même temps, même des
processeurs relativiement propre comme le 68000 ont engendré des
immondices comme le 68040 et surtout le 68060.
Le 6809 (et le 6309) était propre. Le 68000 est déjà une saleté
inommable en comparaison. Le passage du 6809 au 68000 a été pour moi
une calamité ne serait-ce qu'en raison du masque de pile...
Je ne vois pas ce que tu appelles le masque de pile.
Le Thu, 28 Jan 2010 15:01:01 +0000, JKB a écrit :C'est d'ailleurs assez couillon, pourquoi ne pas compiler inst 1
call subroutine
inst 2
inst 3
...
On peut, mais c'est comme le RPL, ce n'est pas vraiment lisible aux non
initiés.
Le RPL n'est pas non plus lisible aux initiés, ce sont juste les commentaires
qui sont lisibles.
Certes, je ne faisait que de la surenchère. En même temps, même des
processeurs relativiement propre comme le 68000 ont engendré des
immondices comme le 68040 et surtout le 68060.
Le 6809 (et le 6309) était propre. Le 68000 est déjà une saleté
inommable en comparaison. Le passage du 6809 au 68000 a été pour moi
une calamité ne serait-ce qu'en raison du masque de pile...
Je ne vois pas ce que tu appelles le masque de pile.
Le 29-01-2010, ? propos de
Re: swap en RAM (anciennement : Lettre à M.D.,
Toxico Nimbus ?crivait dans fr.comp.os.linux.configuration :Le Thu, 28 Jan 2010 15:01:01 +0000, JKB a écrit :C'est d'ailleurs assez couillon, pourquoi ne pas compiler inst 1 call
subroutine
inst 2
inst 3
...
On peut, mais c'est comme le RPL, ce n'est pas vraiment lisible aux
non initiés.
Le RPL n'est pas non plus lisible aux initiés, ce sont juste les
commentaires qui sont lisibles.
C'est parfaitement faux et au final largement plus lisible qu'un truc
comme Java.
Je ne vois pas ce que tu appelles le masque de pile.
Le fait que sur le 68000, tu ne peux utiliser qu'une pile à un instant
donné, la seconde étant masquée. Sur le 6809, tu as U et S. Le
processeur utilise S, tu fais ce que bon te semble avec U, et si tu as
besoin de plusieurs piles indépendantes, tu les gères à la main au
travers de S. Sur le 68000, ça devient très rapidement folklorique
parce que A7 n'est jamais visible, mais le processeur échange A6 et A7
sur certaines instructions.
Le 29-01-2010, ? propos de
Re: swap en RAM (anciennement : Lettre à M.D.,
Toxico Nimbus ?crivait dans fr.comp.os.linux.configuration :
Le Thu, 28 Jan 2010 15:01:01 +0000, JKB a écrit :
C'est d'ailleurs assez couillon, pourquoi ne pas compiler inst 1 call
subroutine
inst 2
inst 3
...
On peut, mais c'est comme le RPL, ce n'est pas vraiment lisible aux
non initiés.
Le RPL n'est pas non plus lisible aux initiés, ce sont juste les
commentaires qui sont lisibles.
C'est parfaitement faux et au final largement plus lisible qu'un truc
comme Java.
Je ne vois pas ce que tu appelles le masque de pile.
Le fait que sur le 68000, tu ne peux utiliser qu'une pile à un instant
donné, la seconde étant masquée. Sur le 6809, tu as U et S. Le
processeur utilise S, tu fais ce que bon te semble avec U, et si tu as
besoin de plusieurs piles indépendantes, tu les gères à la main au
travers de S. Sur le 68000, ça devient très rapidement folklorique
parce que A7 n'est jamais visible, mais le processeur échange A6 et A7
sur certaines instructions.
Le 29-01-2010, ? propos de
Re: swap en RAM (anciennement : Lettre à M.D.,
Toxico Nimbus ?crivait dans fr.comp.os.linux.configuration :Le Thu, 28 Jan 2010 15:01:01 +0000, JKB a écrit :C'est d'ailleurs assez couillon, pourquoi ne pas compiler inst 1 call
subroutine
inst 2
inst 3
...
On peut, mais c'est comme le RPL, ce n'est pas vraiment lisible aux
non initiés.
Le RPL n'est pas non plus lisible aux initiés, ce sont juste les
commentaires qui sont lisibles.
C'est parfaitement faux et au final largement plus lisible qu'un truc
comme Java.
Je ne vois pas ce que tu appelles le masque de pile.
Le fait que sur le 68000, tu ne peux utiliser qu'une pile à un instant
donné, la seconde étant masquée. Sur le 6809, tu as U et S. Le
processeur utilise S, tu fais ce que bon te semble avec U, et si tu as
besoin de plusieurs piles indépendantes, tu les gères à la main au
travers de S. Sur le 68000, ça devient très rapidement folklorique
parce que A7 n'est jamais visible, mais le processeur échange A6 et A7
sur certaines instructions.
Le Fri, 29 Jan 2010 08:55:07 +0000, JKB a écrit :Le 29-01-2010, ? propos de
Re: swap en RAM (anciennement : Lettre à M.D.,
Toxico Nimbus ?crivait dans fr.comp.os.linux.configuration :Le Thu, 28 Jan 2010 15:01:01 +0000, JKB a écrit :C'est d'ailleurs assez couillon, pourquoi ne pas compiler inst 1 call
subroutine
inst 2
inst 3
...
On peut, mais c'est comme le RPL, ce n'est pas vraiment lisible aux
non initiés.
Le RPL n'est pas non plus lisible aux initiés, ce sont juste les
commentaires qui sont lisibles.
C'est parfaitement faux et au final largement plus lisible qu'un truc
comme Java.
Je ne suis pas d'accord. Pour avoir fait beaucoup de RPL, je le place
volontier dans la catégorie des langages write-only, avec Haskell.
Quant à Java, je le trouve plutôt lisible, pour un langage oo, malgré
les try-catch qui pourrissent le code à foison.
Je ne vois pas ce que tu appelles le masque de pile.
Le fait que sur le 68000, tu ne peux utiliser qu'une pile à un instant
donné, la seconde étant masquée. Sur le 6809, tu as U et S. Le
processeur utilise S, tu fais ce que bon te semble avec U, et si tu as
besoin de plusieurs piles indépendantes, tu les gères à la main au
travers de S. Sur le 68000, ça devient très rapidement folklorique
parce que A7 n'est jamais visible, mais le processeur échange A6 et A7
sur certaines instructions.
Je ne vois vraiment pas pourquoi tu dis qu'A7 n'est jamais visible. Quant aux
piles multiples, je pense qu'une primitive stackswap n'est pas la mort à coder.
Le Fri, 29 Jan 2010 08:55:07 +0000, JKB a écrit :
Le 29-01-2010, ? propos de
Re: swap en RAM (anciennement : Lettre à M.D.,
Toxico Nimbus ?crivait dans fr.comp.os.linux.configuration :
Le Thu, 28 Jan 2010 15:01:01 +0000, JKB a écrit :
C'est d'ailleurs assez couillon, pourquoi ne pas compiler inst 1 call
subroutine
inst 2
inst 3
...
On peut, mais c'est comme le RPL, ce n'est pas vraiment lisible aux
non initiés.
Le RPL n'est pas non plus lisible aux initiés, ce sont juste les
commentaires qui sont lisibles.
C'est parfaitement faux et au final largement plus lisible qu'un truc
comme Java.
Je ne suis pas d'accord. Pour avoir fait beaucoup de RPL, je le place
volontier dans la catégorie des langages write-only, avec Haskell.
Quant à Java, je le trouve plutôt lisible, pour un langage oo, malgré
les try-catch qui pourrissent le code à foison.
Je ne vois pas ce que tu appelles le masque de pile.
Le fait que sur le 68000, tu ne peux utiliser qu'une pile à un instant
donné, la seconde étant masquée. Sur le 6809, tu as U et S. Le
processeur utilise S, tu fais ce que bon te semble avec U, et si tu as
besoin de plusieurs piles indépendantes, tu les gères à la main au
travers de S. Sur le 68000, ça devient très rapidement folklorique
parce que A7 n'est jamais visible, mais le processeur échange A6 et A7
sur certaines instructions.
Je ne vois vraiment pas pourquoi tu dis qu'A7 n'est jamais visible. Quant aux
piles multiples, je pense qu'une primitive stackswap n'est pas la mort à coder.
Le Fri, 29 Jan 2010 08:55:07 +0000, JKB a écrit :Le 29-01-2010, ? propos de
Re: swap en RAM (anciennement : Lettre à M.D.,
Toxico Nimbus ?crivait dans fr.comp.os.linux.configuration :Le Thu, 28 Jan 2010 15:01:01 +0000, JKB a écrit :C'est d'ailleurs assez couillon, pourquoi ne pas compiler inst 1 call
subroutine
inst 2
inst 3
...
On peut, mais c'est comme le RPL, ce n'est pas vraiment lisible aux
non initiés.
Le RPL n'est pas non plus lisible aux initiés, ce sont juste les
commentaires qui sont lisibles.
C'est parfaitement faux et au final largement plus lisible qu'un truc
comme Java.
Je ne suis pas d'accord. Pour avoir fait beaucoup de RPL, je le place
volontier dans la catégorie des langages write-only, avec Haskell.
Quant à Java, je le trouve plutôt lisible, pour un langage oo, malgré
les try-catch qui pourrissent le code à foison.
Je ne vois pas ce que tu appelles le masque de pile.
Le fait que sur le 68000, tu ne peux utiliser qu'une pile à un instant
donné, la seconde étant masquée. Sur le 6809, tu as U et S. Le
processeur utilise S, tu fais ce que bon te semble avec U, et si tu as
besoin de plusieurs piles indépendantes, tu les gères à la main au
travers de S. Sur le 68000, ça devient très rapidement folklorique
parce que A7 n'est jamais visible, mais le processeur échange A6 et A7
sur certaines instructions.
Je ne vois vraiment pas pourquoi tu dis qu'A7 n'est jamais visible. Quant aux
piles multiples, je pense qu'une primitive stackswap n'est pas la mort à coder.
Le RPL n'est pas non plus lisible aux initiés, ce sont juste les
commentaires qui sont lisibles.
C'est parfaitement faux et au final largement plus lisible qu'un truc
comme Java.
Je ne suis pas d'accord. Pour avoir fait beaucoup de RPL, je le place
volontier dans la catégorie des langages write-only, avec Haskell.
J'ai des Mo de codes en RPL(/2 en l'occurrence) et ça ne me pose
strictement aucun problème de lecture. Il faut simplement coller les
bons commentaires là où il faut avec le contenu de la pile si tu as
peur de ne plus t'y retrouver.
Quant à Java, je le trouve plutôt lisible, pour un langage oo, malgré
les try-catch qui pourrissent le code à foison.
Ouaips. C'est abscons à souhait et sans un IDE complet, il est
impossible de faire quelque chose d'un peu compliqué. Par ailleurs, on
peut dire ce qu'on veut, mais la programmation objet, c'est tout sauf
propre surtout de la façon dont c'est fait dans Java (ramasse-miette et
autres joyeusetés du même tonneaux, bidouillages infâmes avec des
connecteurs de base de données parce que tu ne sais jamais vraiment
quand tes objets vont être libérés...).
Je ne vois pas ce que tu appelles le masque de pile.
Le fait que sur le 68000, tu ne peux utiliser qu'une pile à un
instant donné, la seconde étant masquée. Sur le 6809, tu as U et S.
Le processeur utilise S, tu fais ce que bon te semble avec U, et si
tu as besoin de plusieurs piles indépendantes, tu les gères à la main
au travers de S. Sur le 68000, ça devient très rapidement folklorique
parce que A7 n'est jamais visible, mais le processeur échange A6 et
A7 sur certaines instructions.
Je ne vois vraiment pas pourquoi tu dis qu'A7 n'est jamais visible.
Quant aux piles multiples, je pense qu'une primitive stackswap n'est
pas la mort à coder.
De mémorie (je n'ai pas ouvert ma doc d'époque), tu accèdes à A7 au
travers de A6. Et comme le processeur fait ce qu'il veut avec sa pile,
il peut modifier le A6 en question. Je ne vois pas pourquoi on ne peut
pas voir A6 et A7 en _même_ temps.
Le RPL n'est pas non plus lisible aux initiés, ce sont juste les
commentaires qui sont lisibles.
C'est parfaitement faux et au final largement plus lisible qu'un truc
comme Java.
Je ne suis pas d'accord. Pour avoir fait beaucoup de RPL, je le place
volontier dans la catégorie des langages write-only, avec Haskell.
J'ai des Mo de codes en RPL(/2 en l'occurrence) et ça ne me pose
strictement aucun problème de lecture. Il faut simplement coller les
bons commentaires là où il faut avec le contenu de la pile si tu as
peur de ne plus t'y retrouver.
Quant à Java, je le trouve plutôt lisible, pour un langage oo, malgré
les try-catch qui pourrissent le code à foison.
Ouaips. C'est abscons à souhait et sans un IDE complet, il est
impossible de faire quelque chose d'un peu compliqué. Par ailleurs, on
peut dire ce qu'on veut, mais la programmation objet, c'est tout sauf
propre surtout de la façon dont c'est fait dans Java (ramasse-miette et
autres joyeusetés du même tonneaux, bidouillages infâmes avec des
connecteurs de base de données parce que tu ne sais jamais vraiment
quand tes objets vont être libérés...).
Je ne vois pas ce que tu appelles le masque de pile.
Le fait que sur le 68000, tu ne peux utiliser qu'une pile à un
instant donné, la seconde étant masquée. Sur le 6809, tu as U et S.
Le processeur utilise S, tu fais ce que bon te semble avec U, et si
tu as besoin de plusieurs piles indépendantes, tu les gères à la main
au travers de S. Sur le 68000, ça devient très rapidement folklorique
parce que A7 n'est jamais visible, mais le processeur échange A6 et
A7 sur certaines instructions.
Je ne vois vraiment pas pourquoi tu dis qu'A7 n'est jamais visible.
Quant aux piles multiples, je pense qu'une primitive stackswap n'est
pas la mort à coder.
De mémorie (je n'ai pas ouvert ma doc d'époque), tu accèdes à A7 au
travers de A6. Et comme le processeur fait ce qu'il veut avec sa pile,
il peut modifier le A6 en question. Je ne vois pas pourquoi on ne peut
pas voir A6 et A7 en _même_ temps.
Le RPL n'est pas non plus lisible aux initiés, ce sont juste les
commentaires qui sont lisibles.
C'est parfaitement faux et au final largement plus lisible qu'un truc
comme Java.
Je ne suis pas d'accord. Pour avoir fait beaucoup de RPL, je le place
volontier dans la catégorie des langages write-only, avec Haskell.
J'ai des Mo de codes en RPL(/2 en l'occurrence) et ça ne me pose
strictement aucun problème de lecture. Il faut simplement coller les
bons commentaires là où il faut avec le contenu de la pile si tu as
peur de ne plus t'y retrouver.
Quant à Java, je le trouve plutôt lisible, pour un langage oo, malgré
les try-catch qui pourrissent le code à foison.
Ouaips. C'est abscons à souhait et sans un IDE complet, il est
impossible de faire quelque chose d'un peu compliqué. Par ailleurs, on
peut dire ce qu'on veut, mais la programmation objet, c'est tout sauf
propre surtout de la façon dont c'est fait dans Java (ramasse-miette et
autres joyeusetés du même tonneaux, bidouillages infâmes avec des
connecteurs de base de données parce que tu ne sais jamais vraiment
quand tes objets vont être libérés...).
Je ne vois pas ce que tu appelles le masque de pile.
Le fait que sur le 68000, tu ne peux utiliser qu'une pile à un
instant donné, la seconde étant masquée. Sur le 6809, tu as U et S.
Le processeur utilise S, tu fais ce que bon te semble avec U, et si
tu as besoin de plusieurs piles indépendantes, tu les gères à la main
au travers de S. Sur le 68000, ça devient très rapidement folklorique
parce que A7 n'est jamais visible, mais le processeur échange A6 et
A7 sur certaines instructions.
Je ne vois vraiment pas pourquoi tu dis qu'A7 n'est jamais visible.
Quant aux piles multiples, je pense qu'une primitive stackswap n'est
pas la mort à coder.
De mémorie (je n'ai pas ouvert ma doc d'époque), tu accèdes à A7 au
travers de A6. Et comme le processeur fait ce qu'il veut avec sa pile,
il peut modifier le A6 en question. Je ne vois pas pourquoi on ne peut
pas voir A6 et A7 en _même_ temps.
