ASM on-calc - Page 4

(char) (ngetchx()) ?

Makéjésuikon

Euh, attends, je suis pas sûr, par contre, ça:
dc.w $F800+ngetchx
andi.w #$00FF,d0

je suis sûr que ça marche

Ouais, bon, j'vais pas foutre des bouts d'asm en live comme ça xD

./91 Oui, sauf qu’il vaut mieux faire le cast uniquement au moment de l’affectation puisque ngetchx peut aussi renvoyer des valeurs supérieures à 127 et même à 255, quand, par exemple, on appuie sur les touches directionnelles.

Ouaip, mais ça produit des caractères horribles et non désirés sur l'écran. Il faut peut-être préférer un test à un simple transtypage. Si le code renvoyé dépasse 255, on ajoute rien à la chaîne.

Thibaut (./96) :
Ouaip, mais ça produit des caractères horribles et non désirés sur l'écran. Il faut peut-être préférer un test à un simple transtypage. Si le code renvoyé dépasse 255, on ajoute rien à la chaîne.

Une condition suffit

Merci à vous.

Allez, on reprend le topic

#include <tigcclib.h>

#define RETURN_VALUE

void _main(void)
{
   while (GetArgType (top_estack) != END_TAG)
   {
      top_estack = next_expression_index (top_estack);
      top_estack--;
   }

   int i = 0;
   if(speek(0x32)==80 && speek(0x33)==79)
   {
      i++;
   }
  
   push_shortint(i);
}

J'ai cru bien comprendre cette page, mais j'ai dû me gourer vu que ça renvoie rien du tout ^^.
Je commence en C sur Ti, j'suis un peu largué :x

FireHunter (./98) :

J'ai cru bien comprendre cette page, mais j'ai dû me gourer vu que ça renvoie rien du tout ^^. Je commence en C sur Ti, j'suis un peu largué :x

Normal. Ca ne peut pas marcher sans PreOS

Hein ?!? Un programme nostub ne peut pas retourner une valeur ?!?

Now about problems. Everything works fine in AMS 1.xx, but AMS 2.xx forbids the use of ASM programs in expressions. So, in the above example, 'add(2,3)' will work perfectly, but '5+add(2,3)' or even 'add(2,3)->a' will not. This stupidity makes returning values mostly useless. What to do? Unfortunately, I can't do nothing from the TIGCC itself, because an ASM program will not be executed at all if AMS 2.xx detects its presence in an expression. However, there is a solution: it is possible to make a resident program which will intercept such "stupid" behaviour of AMS 2.xx and to allow executing ASM programs in expressions. Such interception is already implemented in the latest versions of DoorsOS, Universal OS, PreOS and KerNO (but not in TeOS). So, if you have installed a fresh release of DoorsOS, Universal OS, PreOS or KerNO, everything will work OK even on AMS 2.xx. There is also a TSR called IPR which intercepts only this error and the "ASAP or Exec string too long" error available at Cyril Pascal's (Paxal's) web page for those who don't want to install a full-featured kernel. But for HW2 calculators, the HW2 AMS 2 TSR support (h220xTSR) needs to be installed before IPR. This does not mean that your program must be compiled in "Doors" mode: it may be a "nostub" program, but DoorsOS, Universal OS, PreOs, KerNO or IPR must be present on the calculator (to intercept stupid behavior of AMS 2.xx). To conclude: if you have AMS 2.xx and if you want to use "returning a value" feature, you must have installed DoorsOS, Universal OS, PreOs, KerNO or IPR. If you are a programmer, please note this fact in the documentation of any program which uses this feature! 

Source: http://tigcc.ticalc.org/doc/htretval.html

Now about problems. Everything works fine in AMS 1.xx, but AMS 2.xx forbids the use of ASM programs in expressions. So, in the above example, 'add(2,3)' will work perfectly, but '5+add(2,3)' or even 'add(2,3)->a' will not. This stupidity makes returning values mostly useless. What to do? Unfortunately, I can't do nothing from the TIGCC itself, because an ASM program will not be executed at all if AMS 2.xx detects its presence in an expression. However, there is a solution: it is possible to make a resident program which will intercept such "stupid" behaviour of AMS 2.xx and to allow executing ASM programs in expressions. Such interception is already implemented in the latest versions of DoorsOS, Universal OS, PreOS and KerNO (but not in TeOS). So, if you have installed a fresh release of DoorsOS, Universal OS, PreOS or KerNO, everything will work OK even on AMS 2.xx. There is also a TSR called IPR which intercepts only this error and the "ASAP or Exec string too long" error available at Cyril Pascal's (Paxal's) web page for those who don't want to install a full-featured kernel. But for HW2 calculators, the HW2 AMS 2 TSR support (h220xTSR) needs to be installed before IPR. This does not mean that your program must be compiled in "Doors" mode: it may be a "nostub" program, but DoorsOS, Universal OS, PreOs, KerNO or IPR must be present on the calculator (to intercept stupid behavior of AMS 2.xx). To conclude: if you have AMS 2.xx and if you want to use "returning a value" feature, you must have installed DoorsOS, Universal OS, PreOs, KerNO or IPR. If you are a programmer, please note this fact in the documentation of any program which uses this feature!

Dans un cite, c'est mieux.

Mais merci pour l'xplication.

J'avais pas remarqué

Bon, alors comment je fais moi :'(.

J'avais pensé à faire un HomeExecute("preos()",7);, mais c'est complètement arbitraire, Dieu seul sait où l'utilisateur a foutu PreOS. Faudrait que je fasse une rechercher du fichier, et que je récupère son dossier, pour le lancer, et calculer la longueur de la chaine "DOSSIER\PREOS()" pour la passer en argument à HomeExecute. En plus, je sais pas manipuler la VAT. Rha la galère

SymFindPtr( SYMSTR (preos))

Enfait, la vat, ça va vraiment pas chercher loin une fois qu'on a fait quelques manipulations.

Tu utilises RETURN_VALUE avec un nom de variable. Tu ne peux pas utiliser le RETURN_VALUE style fonction TI-BASIC dans une chaîne Exec (parce qu'Exec est une instruction, pas une fonction).

Quelle connerie d'avoir répandu le mode nostub.

...

Folco (./105) :
SymFindPtr( SYMSTR (preos))

Enfait, la vat, ça va vraiment pas chercher loin une fois qu'on a fait quelques manipulations.

C'est aussi con que ça ? OK merci, je verrais ça en Anglais

Kevin Kofler (./106) :
Tu utilises RETURN_VALUE avec un nom de variable. Tu ne peux pas utiliser le RETURN_VALUE style fonction TI-BASIC dans une chaîne Exec (parce qu'Exec est une instruction, pas une fonction).

J'ai tenté, mais ça retourne rien quand même, aucune variable n'est créée :'( Je reregarderais en maths aussi

Thibaut (./107) :
Quelle connerie d'avoir répandu le mode nostub.

La limitation du ./106 n'a rien à voir avec le _nostub.

FireHunter (./109) :
J'ai tenté, mais ça retourne rien quand même, aucune variable n'est créée :'(

Peut-être que GTC ne gère pas cette fonctionnalité.

Je reregarderais en maths aussi

Tu ferais mieux d'écouter en cours de Mathématiques, c'est une matière importante!

Comme l'informatique ! Le reste, c'est nul à chier.

Kevin Kofler (./111) :

FireHunter (./109) :
J'ai tenté, mais ça retourne rien quand même, aucune variable n'est créée :'(

Peut-être que GTC ne gère pas cette fonctionnalité.

Je reregarderais en maths aussi

Tu ferais mieux d'écouter en cours de Mathématiques, c'est une matière importante!

J'écoute, mais bon on ne fait que des révisions --".
D'ailleurs, je sors de mon DS de maths, et je sens bien le 15/20 \o/

Concernant GTC c'est ce que j'me demande, j'essayerais sous Tigcc ...

vec GTC.#include <stdio.h> int main() { return 42; }Je viens d'essayer ma petite couche d'abstraction aaffiche bien 42 dans les résultats de l'écran Home. Le retour de valeur marche bien avec GTC. Il doit y avoir une erreur dans ton code FireHunter

42
Bon j'vais regarder, je peux pas vous balancer le code là, mais dès que possible j'l'envoie.
Tu utilises GTC on-calc ?

Oui. Je viens de relire ton code. Le problème c'est qu'il décrémente top_estack dans la boucle. next_expression_index s'en charge déjà. Il faut placer top_estack-- en dehors, juste après l'accolade fermante. Ça permet de zapper le END_TAG sans declencher d'exception. Au pire, si tout ça te saoule (comme moi), je te passerai mon header magique qui permettra de t'affranchir des manipulations chiantes héritées du standard TIGCC.

FireHunter (./113) :
D'ailleurs, je sors de mon DS de maths, et je sens bien le 15/20 \o/

Retourne écouter en cours et reviens quand tu auras eu 20.

Thibaut (./114) :
Il doit y avoir une erreur dans ton code FireHunter

Non. Ton code utilise le RETURN_VALUE style "fonction TI-BASIC", qui ne marche pas pour les chaînes Exec. Ce qu'il lui fait, c'est le RETURN_VALUE avec un nom de variable, et apparemment GTC ne gère pas ça.

Je ne vois pas de retour de variable dans son code, ni de chaîne exec. Je vois pas contre une double decrementation du pointeur de pile, qui pose à coup sur problème

Thibaut (./118) :
Je ne vois pas de retour de variable dans son code,

C'est pour ça que l'exemple du ./98 ne marche pas avec une chaîne Exec. Son nouveau problème, c'est que le retour à travers une variable ne marche pas avec GTC (./109).

ni de chaîne exec.

Il a expliqué dans un autre topic que c'était pour une chaîne Exec.

Je vois pas contre une double decrementation du pointeur de pile, qui pose à coup sur problème

Ce top_estack--; est nécessaire! En revanche, il est au mauvais endroit, donc effectivement son code est incorrect.

Le code correct, c'est:

   while (GetArgType (top_estack) != END_TAG)
   {
      // On saute l'argument courant jusqu'à tomber sur l'END_TAG.
      top_estack = next_expression_index (top_estack);
   }
   // APRÈS la boucle (!), on saute le END_TAG. (Il n'y en a qu'un!)
   top_estack--;

C'est pas en mettant un mot en gras et en répétant ce qui a été dit que tu donneras l'impression de contredire. Tu sais, personne ne t'en voudras de ne pas avoir vu son erreur

Si c'est bien pour une chaine exec, on peut lui préconiser la création manuelle d'une variable. fopen, write et close régleront l'affaire.