longjmp - Page 1

Bonjour.
Je voudrais utiliser les fonctions setjmp et longjmp pour permettre à tout moment de quitter le programme. Jusque là pas de problème, j'enveloppe le code de if (!setjmp...) puis je mets ensuite le code de fin libérant tout.
Après j'ai eu la monstrueuse idée de rediriger l'interruption utilisée pour la touche ON et faire donc un longjmp dans ce cas, quittant le programme comme un simple break en basic. Utile pour éviter les boucles infinies d'un prog en développement. Bon, j'implémente tout ça, et ça a l'air à première vue de fonctionner, sauf que ça plante de temps en temps tout de même (ce qui ne m'étonne pas beaucoup), alors je me demandais s'il y avait un moyen valide d'implémenter ce genre de choses...

Ben , exit ça pourrait pas suffire ?

Non, car il faudrait libérer la mémoire pour être propre...

Oui, mais je vois pas en quoi longjmp et setjmp t'aident à libérer la mémoire

Il faut passer en mode utilisateur avant de faire ton longjmp! Un asm("move.w #0,%sr"); devrait règler ton problème.

Merci Kevin, je me doutais qu'il y avait une connerie du style, car les interruptions sont executées en mode superviseur je crois... enfin je ne sais pas ce que je barratine; je n'y connais absolument rien!
Merci encore, je vais tester.

Un asm("move.w #0,%sr"); devrait règler ton problème.

Pas vraiment. Le plus propre serait d'écrire "*__builtin_return_address=fonction_longjmp; return;" (je sais plus le nom exact du builtin), et "void fonction_longjmp() { longjmp(blah); }". Ta solution marche en apparence, mais ne libère pas la pile superviseur, qui risque d'être sacrément entamée si ta fonction a pas mal de variables locales.

Pollux
: Le plus propre serait d'écrire "*__builtin_return_address=fonction_longjmp; return;" (je sais plus le nom exact du builtin), et "void fonction_longjmp() { longjmp(blah); }".

Ne marche pas du tout (pour l'instant - si on gère __attribute__((interrupt_handler)) un de ces jours, ça marchera peut-être). L'adresse de retour est celle de la fonction C et pas celle du wrapper assembleur.

Ta solution marche en apparence, mais ne libère pas la pile superviseur, qui risque d'être sacrément entamée si ta fonction a pas mal de variables locales.

Bon, OK, il faut aussi un adda #[euh, voir la source générée pour la valeur exacte],%a7.

Ne marche pas du tout (pour l'instant - si on gère __attribute__((interrupt_handler)) un de ces jours, ça marchera peut-être). L'adresse de retour est celle de la fonction C et pas celle du wrapper assembleur.

Argl. Bon, alors une fonction de la lib qui fait ça, et c'est implementation-defined?

Bon, OK, il faut aussi un adda #[euh, voir la source générée pour la valeur exacte],%a7.

lol Et vive alloca

Moi, je serai pour sauver la valeur du SP au début du prog, et la recharger ensuite... comme ça on est sur que ça libère la pile superviseur...

Non, setjmp/longjmp le fait déjà et ça ne sert à rien, parce qu'ici, on parle de %ssp, pas de %usp.

Bon, OK, il faut aussi un adda #[euh, voir la source générée pour la valeur exacte],%a7.

Je ne comprends pas

Il faut dépiler tout ce qui a été empilé par le compilateur.

Un lea x(a7),a7 n'est pas plus rapide que adda ?

Si.

C'est pas ça les timings exacts ?
(format : cycles calcul (cycles lecture / cycles écriture) )

lea x(a7),a7 => 16 (4/0)
addq #x,a7 => 8 (1/0)
adda #x,a7 => 16 (3/0)

En revanche, lea présente l'avantage de ne pas modifier le CCR.

spectras
: lea x(a7),a7 => 16 (4/0)

Pourquoi 4 lectures ? Le bus de données a une largeur de 16 bits, et l'instruction fait 4 octets (deux octets pour l'opcode et 2 autres pour le déplacement signé), donc en deux lectures on a l'instruction entière.

addq #x,a7 => 8 (1/0)

Là c'est bon pour le nombre de lectures, mais une lecture prend 4 cycles, pas 8.
Donc évidemment le lea au-dessus prend 8 cycles, pas 16.

adda #x,a7 => 16 (3/0)

Là j'ai oublié, en plus ça dépend de si on fait adda.w ou adda.l.

En revanche, lea présente l'avantage de ne pas modifier le CCR.

Il me semble qu'aucune des instructions citées ne modifie le CCR. A vérifier.

ça doit faire 4 cycles en plus avec un adda.l (du genre adda.w -> 12 cycles, adda.l -> 16 cycles, mais j'ai pas de doc sous la main)

lea x(an),an -> 4 octets, 8 cycles
adda.w #x,an -> 4 octets, 12 cycles
Donc en effet, lea est meilleur.

Mais aucune des deux ne touche aux flags du CCR, et addq sur un registre d'adresses non plus.

Désolé, je m'étais planté de table de timings, je lisais la table pour le mode 8bits, alors qu'on est en 16 . Du coup évidemment, y'avait quelques lectures en trop

Voilà, je recommence :

lea x(an),an => 8 (2/0)
addq.l #x,an => 8 (1/0)
addq.w #x,an => 4 (1/0)
adda.w #x,an => 12 (2/0)
adda.l #x,an => 16 (3/0)

Ce que je comprends pas, en revanche, c'est que il y ait une différence entre addq.w et addq.l, alors que la doc dit que si on utilise un registre d'adresse, il est toujours affecté entièrement.

Curieux en effet...

moué ... a voir si pt de vue proc, y'a pas une partie mise a 0 pis le word completé ....

Mes 2 tables de timings disent que c'est 8 cycles pour addq.w ...,%an comme pour addq.l ...,%an.

D'ailleurs, ces instructions reviennent exactement au même.

logiquement oui ...

Oui, ce serait plus logique.
Mais si tu regardes dans le MC68000 User Manual (http://e-www.motorola.com/files/32bit/doc/ref_manual/MC68000UM.pdf), dans la table 8-5 (page 121) ils ont mis ça :

ADDQ
Byte, Word => 4(1/0)
Long => 8(1/0)

Y'a bien une astérisque sur le premier, mais il n'y a pas de texte correspondant à l'astérisque

Hum

Et pendant que t'y es tu peux aussi nous apprendre que c'est la preuve irréfutable que addq.b #x,an existe?

spectras-> les temps que tu nous donnes sont surement ceux des registres de données, qui eux ne sont pas modifiés entièrement par un addq.w...

Sais pas, je vous ai donné le lien et le numéro de la page, jetez-y un oeil vous même.
Sinon, je me serais pas fatigué à retourner sur le site de motorola pour récupérer l'url, vu que je l'ai sur mon dur la doc.

Pff, j'ai même pas envie de cliquer. Ca saute aux yeux que pour les An, c'est : .w/.l -> 8 cycles

Sur le principe, je suis d'accord. Mais la doc Motorola a l'air de dire le contraire. J'aimerais éclaircir ça quand même.