arguments passé au prgm - Page 1

comment les recupere - t - on ? ils sont sur la pile ? delimité par end_tag et type_tag ? pour le moment j'ai pas reussi a les choper avec ca ...

tu veux dire les arguments passés par la ligne de commande ?

voui !

Oui, ils sont sur la pile d'expression (qui est une pile interne au TIOS, cela n'a rien à voir avec a7).
Tu trouveras de l'aide là : http://tigcc.ticalc.org/doc/args.html#InitArgPtr

Regarde plus généralement le fichier args.h de la doc de TIGCC

si tu veux voir concrètement à quoi ça ressemble, lance un éditeur hexa en lui passant des arguments (je te conseille de commencer par les chaînes de caractères, c'est plus simple)
par exemple, le code suivant va mettre dans a2 un pointeur vers le début de la chaîne passé en argument. Si c'est pas une chaîne, il va au label _debut_no_arg.

 move.l  200,a0
 move.l  1060(a0),a0;ROM_CALL top_estack
 move.l  (a0),a0
 cmp.b   #45,(a0); STR_TAG
 bne     _debut_no_arg
 tst.b   -(a0)
 bne     _debut_no_arg
 moveq   #0,d0
\loop:
 addq.w  #1,d0
 tst.b   -(a0)
 bne     \loop
 lea     1(a0),a2

en fait j'utilise as sur ti

merci bcoup flanker !!!
... depuis toujours j'etais sur que top_estack correspondait a la pile a7... j'etais ds l'erreur

nan, ça serait trop le bordel. Avoir une pile différente permet de faire en sorte que tous les programmes puissent l'utiliser. Si elle avait été confondu avec a7, ça aurait compliqué, vu que chaque programme aurait modifié le pointeur sans prévénir les autres. accessoirement, ça permet d'avoir une pile d'expression de 16ko, alors que la pile est je crois limitée à 4ko

après réflexion je me demande si c'est pas plutôt 16ko je vais vérifier

16ko ^^

User stack : $400 -> $41FF. ça a l'air de faire 16ko
Supervisor Stack : 0$4204 -> $4BFF

4ko, c pas la pile superviseur ?

elle fait en gros 2,5ko d'après les chiffres du ./12

ah, ok
(cross, le précédent)

La pile en %a7 fait 16 KO, la pile d'expressions peut faire jusqu'à 64 KO.

c'est faux, vu que la pile en a7 est aussi la pile superviseur

!up

j'ai le problème inverse : comment poser les arguments sur la pile de façon propre ? je sais le faire à la main, mais pas avec les rom_call
et comment les dépiler après usage ?

push_.* ?
next_expression_index ? (ou un truc du genre, hein le #dictateur# )

push_zstr mais ça marche pas sur toutes les ams :'(
(bon ok, mon programme actuel demande de toute façon ams 2.07+, mais la fonction sur laquelle je travaille devrait marcher sur toutes les ams)

finalement je fais ça pour dépiler

 move.l  $109*4(a5),a0;top_estack
 move.l  (a0),-(a7)
 move.l  $10a*4(a5),a0;next_expression_index
 jsr     (a0)
 addq.l  #4,a7
 move.l  $109*4(a5),a1;top_estack
 move.l  a0,(a1)

delete_between ?

Je sais que c'est un gros remontage, mais c'est le sujet récent le plus proche de ce que je veux faire...
Une fois n'est pas coutume, je veux programmer en kernel-based (si, vous avez bien lu). C'est la deuxième fois (Flanker peut le confirmer), mais j'ai manifestement effacé le source de la première fois - et évidemment, j'en aurais besoin.
Comme l'autre fois, c'est pour faire des benches entre ExtGraph, graphlib - et cette fois-ci Genlib. Le problème n'est pas de refaire un source complet sur A68k à partir de rien, puisqu'il y a un exemple dans la doc de Genlib.
Je me souviens de m'être _embêté_ à trouver comment faire marcher le retour d'arguments (RETURN_VALUE). En l'occurrence, une liste contenant le nombre de ticks d'AI1 ou AI5 mis pour exécuter la même chose un certain nombre de fois - ou le contraire, combien de fois on exécute la même chose en un temps donné.

Pourriez-vous me fournir le code ?

Pourquoi tu ne l'affiches pas simplement à l'écran ?

Ca n'est pas bête, mais ça empêche de moyenner facilement les résultats sur un certain nombre d'exécutions en utilisant un bout de TI-BASIC, comme Matthieu l'avait je suppose fait.

Juste pour dire que j'ai retrouvé le source et les binaries, à un endroit et sous une forme à laquelle je ne m'attendais pas...

Finalement, ce n'est pas si compliqué que ça, RETURN_VALUE...
Pour ne pas le perdre, après ajout du bench par rapport à Genlib, je vais peut-être le mettre comme "demo26" dans la distro d'ExtGraph. Comme ça, tout le monde pourra voir que moi, grand pourfendeur du kernel, j'ai bien fait un programme kernel

> je dois rajouter des tas de codes de démarrages et des variables pour être compatibles on-calc,
C'est pas bien la compatibilité on-calc, puisque ça pénalise tout le monde pour une minorité... Pour l'incompatibilité on-calc, les meilleurs résultats sont obtenus SANS OPTIMIZE_CALC_CONSTS, mais avec des compilations séparées.
Une partie du code de démarrage est de plus en plus souvent due à des "features" du kernel, dont le coût est relativement élevé, à savoir les BSS et les relocations style kernel. L'utilisation de -mno-bss (ou à la rigueur -DMERGE_BSS), surtout avec -mpcrel xor -freg-relative-an, donne des programmes plus petits et plus rapides, voir Ice Hockey 68k pour un exemple assez flagrant de gain.
> des fonctions de libs statiques pour faire un poil de graphisme toussa...
Pas un problème. Genlib fait 20 KB, en augmentation. Ca laisse un peu de temps avant que la redondance prenne beaucoup de place...
> Du côté du programmeur, c'est vraiment pas la fête
Ben, presque tout le monde fait comme ça sans se plaindre... Ca n'est vraiment pas dur.