info sur l'execution de programme dans un programme - Page 1

-

Je pense qu'il faut appeler EX_patch pour modifier les valeurs absolues de ton sous programme.

-

La meilleur méthode, voir le laucher dans la doc de TIGCC, ca marche tres bien

tu veux exécuter un sous programme interne?
je ne comprend pas exactement ce que tu veux faire là...

En clair, fair un appel a un prog ASM en temps que fonction??

rien

Pourquoi inclure le programme en bin?
C'est pour simuler après l'appel à un vrai prog?

il veut executer un bout de code déja compilé non?

-

 include "os.h"
 xdef _ti89
 xdef _nostub

;...
 pea.l end_sousprog-1(PC)
 pea.l sousprog+2(PC)
 move.l $c8,a0
 move.l EX_patch*4(a0),a0
 jsr (a0)
 addq.l #8,a7
 bsr sousprog+2
;...
 rts 

sousprog: incbin "ta.bin"
end_sousprog:

D'ailleurs, tu peux supprimer les 2 octets de taille de ton .bin, ils ne servent strictement à rien.

-

-

Ça consiste en quoi, la relocation du programme ?

[edit]
Lol, les commentaires en anglais
Sinon, il me semble que lea 2(a1),a1 est plus rapide que adda.l #2,a1.

BiHi
a écrit : Je pense qu'il faut appeler EX_patch pour modifier les valeurs absolues de ton sous programme.

Ca sert à ça EX_patch. Quand tu fais:
move.l #32,variable
variable: dc.l 0
l'adressage de variable se fait par valeur absolue, mais comme vous pouvez vous en doutez, la position du programme en RAM ne peut pas être connu au moment de la compilation. Dans le format _nostub, à la fin du programme, il y a la table de relogements, qui contient les positions de chaque valeur absolue (qui pointe vers un endroit du programme) et vers quoi elles pointent (tout ça en relatif par rapport au début du programme). EX_patch se sert de la table de relogements pour mettre des bonnes valeurs absolues avant le lancement d'un programme.

-

jackiechan a écrit :
[edit]
Sinon, il me semble que lea 2(a1),a1 est plus rapide que adda.l #2,a1.

Hmm moi je dirais plutôt addq.l #2,a1. Ca prend que 2 octets, et je pense que c'est plus rapide.

ben oué, c'est plus rapide que ADDA mais moins que ADDQ, donc on utilise LEA pour remonter de plus de 8 octets.

BiHi
a écrit : Hmm moi je dirais plutôt addq.l #2,a1. Ca prend que 2 octets, et je pense que c'est plus rapide.

Ah oui. Je croyais que addq était réservé aux registres de données...

Sinon, c'est puissant, en effet, EX_patch... Ça modifie le code lui-même, ou bien c'est un autre procédé qui est utilisé ?
Mais c'est bizarre qu'AMS possède ce ROM_CALL, non ? Il est utilisé pour quoi dans AMS ?

#18-> Non seulement ADDQ fait tous les registres, mais aussi la mem.
#19-> Pour l'exécution de programmes contenant des JSR ou des JMP mènant dans le programme lui-même, plus généralement tous les appels absolus du programme à lui-même, que ce soit sur saut de code ou de la lecture de données sans label(PC)

jackiechan> Ben par exemple pour restaurer la pile après avoir appelé une ROMCALL, si tu dois restaurer 8 octets ou moins la meilleure manière est addq.l #x,a7 et si c'est plus c'est lea x(a7),a7 . Je sais pas comment tu faisais?...
En ce qui concerne EX_patch, je vois pas pourquoi il est bizarre. Il est par exemple utilisé lorsque tu lance un programme en assembleur sur ta calculatrice, il faut bien le reloger...
C'est obligé que AMS contienne ce genre de routines si il veut lancer des routines en RAM qui se servent de valeur absolue.

BiHi
a écrit : jackiechan> Ben par exemple pour restaurer la pile après avoir appelé une ROMCALL, si tu dois restaurer 8 octets ou moins la meilleure manière est addq.l #x,a7 et si c'est plus c'est lea x(a7),a7 . Je sais pas comment tu faisais?...

Avant, je faisais un lea dans tous les cas.
Je croyais que addq était réservé aux registres de données (d0-d7).

En ce qui concerne EX_patch, je vois pas pourquoi il est bizarre. Il est par exemple utilisé lorsque tu lance un programme en assembleur sur ta calculatrice, il faut bien le reloger... C'est obligé que AMS contienne ce genre de routines si il veut lancer des routines en RAM qui se servent de valeur absolue.

Oui, c vrai...

Orion_> alors pourquoi tu inclues un programme compilé avec TIGCC? :)

-

Hum je crois quand même que les programmes compilés avec TIGCC restaure la pile, même si ils utilisent link et unlk pour des variables globales. Mais sache quand même qu'il y a des cas où il faut quand même restaurer la pile, par exemple dans des boucles où tu utilises la pile, par exemple l'équivalent d'une boucle while en C, parce que le programme empilera et empilera pleins de trucs, et si la boucle est trop longue, tu peux te retrouver avec un Stack Overflow.

De plus, je fais le LINK avant de sauver le contexte; pour avoir les params à partir de 8(PC). Résultat il faut que je restaure la pile pour mes fonctions, sous peine de déliler d'importe quoi quand je restaure le contexte

Depuis que je programme en assembleur je n'ai jamais utilisé link... en fait je n'en ai pas saisi l'intéret ...

-

Je trouve ça plutôt crade.
M'enfin, c'est vrai que c'est pratique...