2426Fermer
Kevin KoflerLe 12/10/2015 à 19:57
Folco (./24) :
Quand je fais un tigcc -S ..., j'ai des jsr _RAM_CALL_xy, et non des jbsr.
Oui, parce que tigcc -S appelle le patcher.
Un jbsr ne voudrait de toute façon rien dire dans ce cadre-là, sauf dans le cas d'un OS, mais j'imagine qu'il faut le stipuler, ou alors ce n'est pas implémenté ?
jbsr veut dire jsr ou bsr selon la distance, c'est une instruction magique de GNU as. C'est clair qu'ici, ce sera toujours un jsr, c'est bien pour ça que la substitution est effectuée. (Le but était justement de faire marcher -Wa,-l, mais manque de chance, -Wa,-l produit un jsr PC-relatif, dont Sebastian et moi ignorions probablement l'existance à l'époque. Il faut aussi rajouter le suffixe :l pour avoir toujours un jsr absolu.) Et un OS n'utilise pas lui-même la notation _RAM_CALL_nn.
Faut aussi que je regarde comment son générées les "appels de variables", qui retournent un résultat dans a0/d0.
D'ailleurs, comment transcrire ça dans une macro C ? Obligé de faire un asm() ?
Par exemple, RAMT RAM_tios::ROM_base me génère dc.w $F0003, mais j'ai ROM_BASE dans a0 après l'exécution du handler.
Ça revient à une fonction (getter) void *tios__ROM_base(void);. (Je rappelle que la convention C est que la valeur de retour est dans %a0 si c'est un pointeur et %d0 sinon.) Si tu veux quelque chose qui marche avec et sans F-Line RAM_CALLs, tu devras utiliser quelque chose comme:
#ifdef USE_FLINE_RAM_CALLS
#define __get_tios__ROM_base _RAM_CALL_3
void *__get_tios__ROM_base(void);
#define tios__ROM_base (__get_tios__ROM_base())
#else
#define tios__ROM_base _RAM_CALL_3
extern void *tios__ROM_base;
#endif
et passer -DUSE_FLINE_RAM_CALLS quelque part.