Tout est question de liberté du code pour certaines distributions
Tout est question de liberté du code pour certaines distributions
Tout est question de liberté du code pour certaines distributions
Ce qui je le répète peut être idiot lorsque le signal s'adresse à un
thread spécifique, ou lorsque le signal doit récupérer une clef au
sens de la pthread.
Il y a des tas d'applications où tu ne peux pas
faire comme ça et qui n'ont pas été codées par des pieds.
Ça a été conçu pour les utilisations historiques des threads, qui n'ont rien
à voir avec les signaux.
Tu remplaces la gestion
des signaux asynchrones par un truc synchrone pour ne pas être
obligé de rendre tes gestionnaires de signaux thread safe (parce que
le fond du problème est là).
Au passage, tu remplaces le système d'interruptions par
un système de polling. Ce n'est plus du tout équivalent. Par
ailleurs, tu es aussi obligé d'utiliser des attentes actives. En
terme d'efficacité, c'est une catastrophe.
En rajoutant un truc qui n'est supporté que par Linux ? Je rigole.
Ce n'est pas le débat. Réponds à la question. Tu prétends qu'il faut
faire des opérations complexes sources de bugs. Je te réponds que
c'est faux. Que vient faire dans le débat l'efficacité des calculs ?
Ce qui je le répète peut être idiot lorsque le signal s'adresse à un
thread spécifique, ou lorsque le signal doit récupérer une clef au
sens de la pthread.
Il y a des tas d'applications où tu ne peux pas
faire comme ça et qui n'ont pas été codées par des pieds.
Ça a été conçu pour les utilisations historiques des threads, qui n'ont rien
à voir avec les signaux.
Tu remplaces la gestion
des signaux asynchrones par un truc synchrone pour ne pas être
obligé de rendre tes gestionnaires de signaux thread safe (parce que
le fond du problème est là).
Au passage, tu remplaces le système d'interruptions par
un système de polling. Ce n'est plus du tout équivalent. Par
ailleurs, tu es aussi obligé d'utiliser des attentes actives. En
terme d'efficacité, c'est une catastrophe.
En rajoutant un truc qui n'est supporté que par Linux ? Je rigole.
Ce n'est pas le débat. Réponds à la question. Tu prétends qu'il faut
faire des opérations complexes sources de bugs. Je te réponds que
c'est faux. Que vient faire dans le débat l'efficacité des calculs ?
Ce qui je le répète peut être idiot lorsque le signal s'adresse à un
thread spécifique, ou lorsque le signal doit récupérer une clef au
sens de la pthread.
Il y a des tas d'applications où tu ne peux pas
faire comme ça et qui n'ont pas été codées par des pieds.
Ça a été conçu pour les utilisations historiques des threads, qui n'ont rien
à voir avec les signaux.
Tu remplaces la gestion
des signaux asynchrones par un truc synchrone pour ne pas être
obligé de rendre tes gestionnaires de signaux thread safe (parce que
le fond du problème est là).
Au passage, tu remplaces le système d'interruptions par
un système de polling. Ce n'est plus du tout équivalent. Par
ailleurs, tu es aussi obligé d'utiliser des attentes actives. En
terme d'efficacité, c'est une catastrophe.
En rajoutant un truc qui n'est supporté que par Linux ? Je rigole.
Ce n'est pas le débat. Réponds à la question. Tu prétends qu'il faut
faire des opérations complexes sources de bugs. Je te réponds que
c'est faux. Que vient faire dans le débat l'efficacité des calculs ?
Sur alpha, j'avais un doute. Le reste, c'est le l'abus de langage
parce que pour moi, une opération de chargement immédiat tient sur
deux fois 32 bits.
Sur alpha, j'avais un doute. Le reste, c'est le l'abus de langage
parce que pour moi, une opération de chargement immédiat tient sur
deux fois 32 bits.
Sur alpha, j'avais un doute. Le reste, c'est le l'abus de langage
parce que pour moi, une opération de chargement immédiat tient sur
deux fois 32 bits.
JKB , dans le message , a
écrit :Ce qui je le répète peut être idiot lorsque le signal s'adresse à un
thread spécifique, ou lorsque le signal doit récupérer une clef au
sens de la pthread.
Ceci n'arrive pas dans un programme qui a été conçu correctement au départ,
et en particulier qui ne prend pas l'initiative d'utiliser des signaux.
Il y a des tas d'applications où tu ne peux pas
faire comme ça et qui n'ont pas été codées par des pieds.
J'attends encore de les voir.
Ça a été conçu pour les utilisations historiques des threads, qui n'ont rien
à voir avec les signaux.
J'ai formulé ma phrase à l'envers, donc je reformule :
Les signaux sont une feature très ancienne dans Unix, et c'est une feature
qui était très mal conçue à la base, en particulier par l'extrême limitation
de ce qui est autorisé dans un signal handler,
mais aussi à cause du manque
de gestion cohérente des ressources (quand tu as un /var/run/foo.pid, tu
n'as aucun moyen de savoir s'il correspond bien au démon foo en train de
tourner ; a contrario, une socket ne te laissera envoyer un message qu'au
processus visé).
Des interfaces bien mieux conçues existaient à l'époque, et elles ont été
étendues. C'est essentiellement l'API des file descriptors, qui peuvent être
agrégés, surveillés, transmis, partagés, etc.
Cependant, il existe encore quelques applications dont le monde de
communication normal est le signal : SIGCHLD, SIGWINCH et peut-être quelques
autres qu'on oublie, plus quelques drivers conçus avec les pieds.
Dans ces conditions, la seule méthode saine quand on doit gérer ces
éléments dans un programme un tant soit peu complexe, c'est de se
débrouiller pour les insérer dans le flot normal du programme.
Regarde
n'importe quelle bibliothèque qui implémente une boucle d'événement, tu
retrouveras toujours la même chose : les signaux sont attrapés par un
handler trivial qui se contente de notifier le coeur ; la vraie gestion est
faite de la même manière que pour tout le reste.
signalfd fournit le support natif pour ce schéma : plus besoin d'attraper le
signal pour réveiller la boucle, le noyau s'en charge. Le vieux code qui
envoyait un signal croit toujours envoyer un signal, mais le code moderne
reçoit un message dans un fd.
Tu remplaces la gestion
des signaux asynchrones par un truc synchrone pour ne pas être
obligé de rendre tes gestionnaires de signaux thread safe (parce que
le fond du problème est là).
Précisément : on remplace un truc ultra casse-gueule, où les neuf dixièmes
des constructions sont interdites, et où il faut se creuser la tête pour
savoir si le dixième restant ne va pas introduire une race condition subtile
et impossible à débugger, par une structure simple et qui s'intègre
parfaitement au reste du système (devices, sockets, pipes, etc.).
Au passage, tu remplaces le système d'interruptions par
un système de polling. Ce n'est plus du tout équivalent. Par
ailleurs, tu es aussi obligé d'utiliser des attentes actives. En
terme d'efficacité, c'est une catastrophe.
Si tu ne sais pas programmer avec les fd, le problème est chez toi, hein. Ce
n'est pas parce qu'on a un fd qu'il faut faire de l'attente active, bien au
contraire, c'est le gros avantage des fd de permettre d'agréger et
multiplexer tout ce qu'on veut.
En rajoutant un truc qui n'est supporté que par Linux ? Je rigole.
C'est une autre histoire, et on s'en fout : l'API est bonne, elle simplifie
le code et rends les choses plus efficaces. Les autres Unix l'adopteront ou
crèveront.
Ce n'est pas le débat. Réponds à la question. Tu prétends qu'il faut
faire des opérations complexes sources de bugs. Je te réponds que
c'est faux. Que vient faire dans le débat l'efficacité des calculs ?
Personne ne voudra d'un compilateur ou d'un OS qui impose un code ralenti à
ce point.
JKB , dans le message <slrniae7fo.glp.jkb@rayleigh.systella.fr>, a
écrit :
Ce qui je le répète peut être idiot lorsque le signal s'adresse à un
thread spécifique, ou lorsque le signal doit récupérer une clef au
sens de la pthread.
Ceci n'arrive pas dans un programme qui a été conçu correctement au départ,
et en particulier qui ne prend pas l'initiative d'utiliser des signaux.
Il y a des tas d'applications où tu ne peux pas
faire comme ça et qui n'ont pas été codées par des pieds.
J'attends encore de les voir.
Ça a été conçu pour les utilisations historiques des threads, qui n'ont rien
à voir avec les signaux.
J'ai formulé ma phrase à l'envers, donc je reformule :
Les signaux sont une feature très ancienne dans Unix, et c'est une feature
qui était très mal conçue à la base, en particulier par l'extrême limitation
de ce qui est autorisé dans un signal handler,
mais aussi à cause du manque
de gestion cohérente des ressources (quand tu as un /var/run/foo.pid, tu
n'as aucun moyen de savoir s'il correspond bien au démon foo en train de
tourner ; a contrario, une socket ne te laissera envoyer un message qu'au
processus visé).
Des interfaces bien mieux conçues existaient à l'époque, et elles ont été
étendues. C'est essentiellement l'API des file descriptors, qui peuvent être
agrégés, surveillés, transmis, partagés, etc.
Cependant, il existe encore quelques applications dont le monde de
communication normal est le signal : SIGCHLD, SIGWINCH et peut-être quelques
autres qu'on oublie, plus quelques drivers conçus avec les pieds.
Dans ces conditions, la seule méthode saine quand on doit gérer ces
éléments dans un programme un tant soit peu complexe, c'est de se
débrouiller pour les insérer dans le flot normal du programme.
Regarde
n'importe quelle bibliothèque qui implémente une boucle d'événement, tu
retrouveras toujours la même chose : les signaux sont attrapés par un
handler trivial qui se contente de notifier le coeur ; la vraie gestion est
faite de la même manière que pour tout le reste.
signalfd fournit le support natif pour ce schéma : plus besoin d'attraper le
signal pour réveiller la boucle, le noyau s'en charge. Le vieux code qui
envoyait un signal croit toujours envoyer un signal, mais le code moderne
reçoit un message dans un fd.
Tu remplaces la gestion
des signaux asynchrones par un truc synchrone pour ne pas être
obligé de rendre tes gestionnaires de signaux thread safe (parce que
le fond du problème est là).
Précisément : on remplace un truc ultra casse-gueule, où les neuf dixièmes
des constructions sont interdites, et où il faut se creuser la tête pour
savoir si le dixième restant ne va pas introduire une race condition subtile
et impossible à débugger, par une structure simple et qui s'intègre
parfaitement au reste du système (devices, sockets, pipes, etc.).
Au passage, tu remplaces le système d'interruptions par
un système de polling. Ce n'est plus du tout équivalent. Par
ailleurs, tu es aussi obligé d'utiliser des attentes actives. En
terme d'efficacité, c'est une catastrophe.
Si tu ne sais pas programmer avec les fd, le problème est chez toi, hein. Ce
n'est pas parce qu'on a un fd qu'il faut faire de l'attente active, bien au
contraire, c'est le gros avantage des fd de permettre d'agréger et
multiplexer tout ce qu'on veut.
En rajoutant un truc qui n'est supporté que par Linux ? Je rigole.
C'est une autre histoire, et on s'en fout : l'API est bonne, elle simplifie
le code et rends les choses plus efficaces. Les autres Unix l'adopteront ou
crèveront.
Ce n'est pas le débat. Réponds à la question. Tu prétends qu'il faut
faire des opérations complexes sources de bugs. Je te réponds que
c'est faux. Que vient faire dans le débat l'efficacité des calculs ?
Personne ne voudra d'un compilateur ou d'un OS qui impose un code ralenti à
ce point.
JKB , dans le message , a
écrit :Ce qui je le répète peut être idiot lorsque le signal s'adresse à un
thread spécifique, ou lorsque le signal doit récupérer une clef au
sens de la pthread.
Ceci n'arrive pas dans un programme qui a été conçu correctement au départ,
et en particulier qui ne prend pas l'initiative d'utiliser des signaux.
Il y a des tas d'applications où tu ne peux pas
faire comme ça et qui n'ont pas été codées par des pieds.
J'attends encore de les voir.
Ça a été conçu pour les utilisations historiques des threads, qui n'ont rien
à voir avec les signaux.
J'ai formulé ma phrase à l'envers, donc je reformule :
Les signaux sont une feature très ancienne dans Unix, et c'est une feature
qui était très mal conçue à la base, en particulier par l'extrême limitation
de ce qui est autorisé dans un signal handler,
mais aussi à cause du manque
de gestion cohérente des ressources (quand tu as un /var/run/foo.pid, tu
n'as aucun moyen de savoir s'il correspond bien au démon foo en train de
tourner ; a contrario, une socket ne te laissera envoyer un message qu'au
processus visé).
Des interfaces bien mieux conçues existaient à l'époque, et elles ont été
étendues. C'est essentiellement l'API des file descriptors, qui peuvent être
agrégés, surveillés, transmis, partagés, etc.
Cependant, il existe encore quelques applications dont le monde de
communication normal est le signal : SIGCHLD, SIGWINCH et peut-être quelques
autres qu'on oublie, plus quelques drivers conçus avec les pieds.
Dans ces conditions, la seule méthode saine quand on doit gérer ces
éléments dans un programme un tant soit peu complexe, c'est de se
débrouiller pour les insérer dans le flot normal du programme.
Regarde
n'importe quelle bibliothèque qui implémente une boucle d'événement, tu
retrouveras toujours la même chose : les signaux sont attrapés par un
handler trivial qui se contente de notifier le coeur ; la vraie gestion est
faite de la même manière que pour tout le reste.
signalfd fournit le support natif pour ce schéma : plus besoin d'attraper le
signal pour réveiller la boucle, le noyau s'en charge. Le vieux code qui
envoyait un signal croit toujours envoyer un signal, mais le code moderne
reçoit un message dans un fd.
Tu remplaces la gestion
des signaux asynchrones par un truc synchrone pour ne pas être
obligé de rendre tes gestionnaires de signaux thread safe (parce que
le fond du problème est là).
Précisément : on remplace un truc ultra casse-gueule, où les neuf dixièmes
des constructions sont interdites, et où il faut se creuser la tête pour
savoir si le dixième restant ne va pas introduire une race condition subtile
et impossible à débugger, par une structure simple et qui s'intègre
parfaitement au reste du système (devices, sockets, pipes, etc.).
Au passage, tu remplaces le système d'interruptions par
un système de polling. Ce n'est plus du tout équivalent. Par
ailleurs, tu es aussi obligé d'utiliser des attentes actives. En
terme d'efficacité, c'est une catastrophe.
Si tu ne sais pas programmer avec les fd, le problème est chez toi, hein. Ce
n'est pas parce qu'on a un fd qu'il faut faire de l'attente active, bien au
contraire, c'est le gros avantage des fd de permettre d'agréger et
multiplexer tout ce qu'on veut.
En rajoutant un truc qui n'est supporté que par Linux ? Je rigole.
C'est une autre histoire, et on s'en fout : l'API est bonne, elle simplifie
le code et rends les choses plus efficaces. Les autres Unix l'adopteront ou
crèveront.
Ce n'est pas le débat. Réponds à la question. Tu prétends qu'il faut
faire des opérations complexes sources de bugs. Je te réponds que
c'est faux. Que vient faire dans le débat l'efficacité des calculs ?
Personne ne voudra d'un compilateur ou d'un OS qui impose un code ralenti à
ce point.
Sur alpha, j'avais un doute. Le reste, c'est le l'abus de langage
parce que pour moi, une opération de chargement immédiat tient sur
deux fois 32 bits.
C'est pourtant trivialement faux.
Sur alpha, j'avais un doute. Le reste, c'est le l'abus de langage
parce que pour moi, une opération de chargement immédiat tient sur
deux fois 32 bits.
C'est pourtant trivialement faux.
Sur alpha, j'avais un doute. Le reste, c'est le l'abus de langage
parce que pour moi, une opération de chargement immédiat tient sur
deux fois 32 bits.
C'est pourtant trivialement faux.
Sur alpha, j'avais un doute. Le reste, c'est le l'abus de langage
parce que pour moi, une opération de chargement immédiat tient sur
deux fois 32 bits.
C'est pourtant trivialement faux.
Euh, là, je ne comprends pas. Je te dis ça de mémoire, mais il me
semblait jusqu'à présent que si je cherche à mettre $FFFFFFFF dans
le registre L2, il me faut écrire :
sethi %hi(0xFFFFFFFF),%L2
or %L2,%lo(0xFFFFFFFF),%L2
qui sont toutes deux des instructions de 32 bits, non ?
Sur alpha, j'avais un doute. Le reste, c'est le l'abus de langage
parce que pour moi, une opération de chargement immédiat tient sur
deux fois 32 bits.
C'est pourtant trivialement faux.
Euh, là, je ne comprends pas. Je te dis ça de mémoire, mais il me
semblait jusqu'à présent que si je cherche à mettre $FFFFFFFF dans
le registre L2, il me faut écrire :
sethi %hi(0xFFFFFFFF),%L2
or %L2,%lo(0xFFFFFFFF),%L2
qui sont toutes deux des instructions de 32 bits, non ?
Sur alpha, j'avais un doute. Le reste, c'est le l'abus de langage
parce que pour moi, une opération de chargement immédiat tient sur
deux fois 32 bits.
C'est pourtant trivialement faux.
Euh, là, je ne comprends pas. Je te dis ça de mémoire, mais il me
semblait jusqu'à présent que si je cherche à mettre $FFFFFFFF dans
le registre L2, il me faut écrire :
sethi %hi(0xFFFFFFFF),%L2
or %L2,%lo(0xFFFFFFFF),%L2
qui sont toutes deux des instructions de 32 bits, non ?
Tu n'as pas cherché bien loin. Je ne vais pas m'abaisser à te
fournir des URL.
Qu'est-ce qu'il ne faut pas lire. C'est au contraire très bien fichu
dès qu'on utilise siginfo_t et sigaction() à la place des
semantiques anciennes.
Et ne me dis pas que c'est un problème de
design
Les signaux peuvent donc tout à fait être utilisés à l'intérieur
d'un même processus entre les différents threads.
Non, parce que ces API sont _synchrones_ alors que les signaux sont
_asynchrones_. Le fait d'utiliser des API _synchrones_ te contraint
à utiliser des attentes actives ou du polling. Dans quelle langue
faut-il que je te le dise ?
Notification qui devient synchrone vis à vis du thread normalement
signalé.
Et on retombe dans le polling.
Tu es bouché à l'émeri parce que tu pars du principe que les deux
approches sont équivalentes, ce qui est faux. Les signaux ne servent
pas qu'à cela et ne peuvent être remplacés par un système synchrone.
Tous les appels systèmes dits lents peuvent échouer sur un EINTR, et
ton approche revient à faire du polling _dans_ ces appels systèmes
si tu veux que les deux approches soient équivalentes.
Sans commentaire. Est-ce que tu crois que les concepteurs d'Unix (je
ne parle même pas des specs POSIX, BSD ou SyV) aient imposé un truc
inutile ?
D'autre part, lorsque tu commences à utiliser les signaux, la
moindre des choses est de savoir ce que tu fais.
sem_wait(&sem);
polling(&mysignalfd);
Si ça, ce n'est pas une attente active, j'aimerais bien que tu me
définisses ce qu'est pour toi une attente active !
Qu'ils crèvent. Ce genre de merde est typique du monde Linux. Sous
prétexte que les programmeurs ne savent pas programmer,
Mais qu'est-ce qu'il ne faut pas lire. L'overhead introduit est
_négligeable_ vis à vis de toutes les autres opérations faites par
l'OS. Si ce n'est pas le cas, c'est juste que ton OS a été écrit pas
un pied.
Tu n'as pas cherché bien loin. Je ne vais pas m'abaisser à te
fournir des URL.
Qu'est-ce qu'il ne faut pas lire. C'est au contraire très bien fichu
dès qu'on utilise siginfo_t et sigaction() à la place des
semantiques anciennes.
Et ne me dis pas que c'est un problème de
design
Les signaux peuvent donc tout à fait être utilisés à l'intérieur
d'un même processus entre les différents threads.
Non, parce que ces API sont _synchrones_ alors que les signaux sont
_asynchrones_. Le fait d'utiliser des API _synchrones_ te contraint
à utiliser des attentes actives ou du polling. Dans quelle langue
faut-il que je te le dise ?
Notification qui devient synchrone vis à vis du thread normalement
signalé.
Et on retombe dans le polling.
Tu es bouché à l'émeri parce que tu pars du principe que les deux
approches sont équivalentes, ce qui est faux. Les signaux ne servent
pas qu'à cela et ne peuvent être remplacés par un système synchrone.
Tous les appels systèmes dits lents peuvent échouer sur un EINTR, et
ton approche revient à faire du polling _dans_ ces appels systèmes
si tu veux que les deux approches soient équivalentes.
Sans commentaire. Est-ce que tu crois que les concepteurs d'Unix (je
ne parle même pas des specs POSIX, BSD ou SyV) aient imposé un truc
inutile ?
D'autre part, lorsque tu commences à utiliser les signaux, la
moindre des choses est de savoir ce que tu fais.
sem_wait(&sem);
polling(&mysignalfd);
Si ça, ce n'est pas une attente active, j'aimerais bien que tu me
définisses ce qu'est pour toi une attente active !
Qu'ils crèvent. Ce genre de merde est typique du monde Linux. Sous
prétexte que les programmeurs ne savent pas programmer,
Mais qu'est-ce qu'il ne faut pas lire. L'overhead introduit est
_négligeable_ vis à vis de toutes les autres opérations faites par
l'OS. Si ce n'est pas le cas, c'est juste que ton OS a été écrit pas
un pied.
Tu n'as pas cherché bien loin. Je ne vais pas m'abaisser à te
fournir des URL.
Qu'est-ce qu'il ne faut pas lire. C'est au contraire très bien fichu
dès qu'on utilise siginfo_t et sigaction() à la place des
semantiques anciennes.
Et ne me dis pas que c'est un problème de
design
Les signaux peuvent donc tout à fait être utilisés à l'intérieur
d'un même processus entre les différents threads.
Non, parce que ces API sont _synchrones_ alors que les signaux sont
_asynchrones_. Le fait d'utiliser des API _synchrones_ te contraint
à utiliser des attentes actives ou du polling. Dans quelle langue
faut-il que je te le dise ?
Notification qui devient synchrone vis à vis du thread normalement
signalé.
Et on retombe dans le polling.
Tu es bouché à l'émeri parce que tu pars du principe que les deux
approches sont équivalentes, ce qui est faux. Les signaux ne servent
pas qu'à cela et ne peuvent être remplacés par un système synchrone.
Tous les appels systèmes dits lents peuvent échouer sur un EINTR, et
ton approche revient à faire du polling _dans_ ces appels systèmes
si tu veux que les deux approches soient équivalentes.
Sans commentaire. Est-ce que tu crois que les concepteurs d'Unix (je
ne parle même pas des specs POSIX, BSD ou SyV) aient imposé un truc
inutile ?
D'autre part, lorsque tu commences à utiliser les signaux, la
moindre des choses est de savoir ce que tu fais.
sem_wait(&sem);
polling(&mysignalfd);
Si ça, ce n'est pas une attente active, j'aimerais bien que tu me
définisses ce qu'est pour toi une attente active !
Qu'ils crèvent. Ce genre de merde est typique du monde Linux. Sous
prétexte que les programmeurs ne savent pas programmer,
Mais qu'est-ce qu'il ne faut pas lire. L'overhead introduit est
_négligeable_ vis à vis de toutes les autres opérations faites par
l'OS. Si ce n'est pas le cas, c'est juste que ton OS a été écrit pas
un pied.
On 10/02/2010 09:08 AM, Richard wrote:
> J'ai même ouï dire que, les instructions CISC étant plus courtes que
> les RISC, leur lecture en mémoire est plus efficace que sur un
> processeur RISC.
Oui, et non. Il me semble que les instructions à longueur
variable complexifient grandement le séquenceur d'accès et la
gestion du cache.
il coupe les poils de cul en quatre,
On 10/02/2010 09:08 AM, Richard wrote:
> J'ai même ouï dire que, les instructions CISC étant plus courtes que
> les RISC, leur lecture en mémoire est plus efficace que sur un
> processeur RISC.
Oui, et non. Il me semble que les instructions à longueur
variable complexifient grandement le séquenceur d'accès et la
gestion du cache.
il coupe les poils de cul en quatre,
On 10/02/2010 09:08 AM, Richard wrote:
> J'ai même ouï dire que, les instructions CISC étant plus courtes que
> les RISC, leur lecture en mémoire est plus efficace que sur un
> processeur RISC.
Oui, et non. Il me semble que les instructions à longueur
variable complexifient grandement le séquenceur d'accès et la
gestion du cache.
il coupe les poils de cul en quatre,
Oui, et non. Il me semble que les instructions à longueur
variable complexifient grandement le séquenceur d'accès et la
gestion du cache.
Oui, mais seulement si tu négliges le vortex spatio-temporel
d'improbabilité autour du vexin qui sur-courbe le scalaire
gravitationnel et donc emprisonne le temps.
Oui, et non. Il me semble que les instructions à longueur
variable complexifient grandement le séquenceur d'accès et la
gestion du cache.
Oui, mais seulement si tu négliges le vortex spatio-temporel
d'improbabilité autour du vexin qui sur-courbe le scalaire
gravitationnel et donc emprisonne le temps.
Oui, et non. Il me semble que les instructions à longueur
variable complexifient grandement le séquenceur d'accès et la
gestion du cache.
Oui, mais seulement si tu négliges le vortex spatio-temporel
d'improbabilité autour du vexin qui sur-courbe le scalaire
gravitationnel et donc emprisonne le temps.
Sur alpha, j'avais un doute. Le reste, c'est le l'abus de langage
parce que pour moi, une opération de chargement immédiat tient sur
deux fois 32 bits.
C'est pourtant trivialement faux.
Euh, là, je ne comprends pas. Je te dis ça de mémoire, mais il me
semblait jusqu'à présent que si je cherche à mettre $FFFFFFFF dans
le registre L2, il me faut écrire :
sethi %hi(0xFFFFFFFF),%L2
or %L2,%lo(0xFFFFFFFF),%L2
qui sont toutes deux des instructions de 32 bits, non ?
Oui, mais là tu ne charges qu'une valeur de 32 bits. Comme la
conversation parlait entre autres d'alpha, il était implicite pour moi
qu'il était question de charger des valeurs immédiates de 64 bits.
Sur alpha, j'avais un doute. Le reste, c'est le l'abus de langage
parce que pour moi, une opération de chargement immédiat tient sur
deux fois 32 bits.
C'est pourtant trivialement faux.
Euh, là, je ne comprends pas. Je te dis ça de mémoire, mais il me
semblait jusqu'à présent que si je cherche à mettre $FFFFFFFF dans
le registre L2, il me faut écrire :
sethi %hi(0xFFFFFFFF),%L2
or %L2,%lo(0xFFFFFFFF),%L2
qui sont toutes deux des instructions de 32 bits, non ?
Oui, mais là tu ne charges qu'une valeur de 32 bits. Comme la
conversation parlait entre autres d'alpha, il était implicite pour moi
qu'il était question de charger des valeurs immédiates de 64 bits.
Sur alpha, j'avais un doute. Le reste, c'est le l'abus de langage
parce que pour moi, une opération de chargement immédiat tient sur
deux fois 32 bits.
C'est pourtant trivialement faux.
Euh, là, je ne comprends pas. Je te dis ça de mémoire, mais il me
semblait jusqu'à présent que si je cherche à mettre $FFFFFFFF dans
le registre L2, il me faut écrire :
sethi %hi(0xFFFFFFFF),%L2
or %L2,%lo(0xFFFFFFFF),%L2
qui sont toutes deux des instructions de 32 bits, non ?
Oui, mais là tu ne charges qu'une valeur de 32 bits. Comme la
conversation parlait entre autres d'alpha, il était implicite pour moi
qu'il était question de charger des valeurs immédiates de 64 bits.