[Ramcalls et PedroM] Deux questions sur leur utilisation en C - Page 1

yop,

J'ai deux questions bien distinctes :

1. Comment produire l'appel d'un ramcall en fline en C ? Ce n'est pas supporté par TIGCC/GCC4TI via un switch, alors comment faire ?
J'ai clairement pas le niveau pour patcher ld-tigcc...
Pour rappel, il s'agit de produire le word 0xF000 + numéro du ramcall, avec les arguments sur la pile ou dans les registres.
Je suis prêt à utiliser des macros dégueulasses si c'est le seul moyen.


2. Comment appeler les ramcalls qui utilisent passent des arguments dans des registres aux fonctions appelées ?
Je pense par exemple à LibsExec :

35-kernel::LibsExec(char *lib_name, WORD function, BYTE version, ...)	(Preos only)

	The parameters are pushed on the stack.
	It calls the function without modifying the registers, and it pops its argument 
	during the call (LIB_DESCRIPTOR, function, and version).
	BYTE doesn't follow the C convesion for char (Sorry). Uses macro instead.

	It relocs the library, calls the function and unreallocs the library.
	The parameters pushed on the stack are corrupted.
	If there is an error, the parameter 'lib_name' equals zero after the call.

	Destroy:
		Like the called function

	Example:
		pea	arg2function		; Arg2 of the function
		move.w	#arg1function,-(a7)	; Arg1 of the function
		move.b	#1,-(a7)		; Version 1
		move.w	#3,-(a7)		; Function 3
		pea	LibsName		; Libs Name
		move.w	#145,d0			; D0 = 145 for the function !
		jsr	kernel::LibsExec
		tst.l	(a7)
		lea	(4+2+2+2+4)(a7),a7	; Does not affect the flag
		beq.s	\error
		...

	LibsName	dc.b	"totolib",0

En l'occurence, j'ai une fonction dont le proto prend des arguments par registres, mais comment dire ça au proto de LibsExec, qui va tout vouloir passer sur la pile ?

L'include de Pedrom définit ça :

#define	kernel_LibsExec	_RAM_CALL_1D
__attribute__((__stkparm__)) void kernel_LibsExec(char *name, short function, char version, ...);

Faut-il que j'écrive quelque chose comme ça pour faire l'appel qui me convient :

void modified_LibsExec(char *name, short function, char version, int truc asm("%d0"));
#define	modified_LibsExec	_RAM_CALL_1D

Dans l'idée, c'est ça ?

Folco (./1) :
1. Comment produire l'appel d'un ramcall en fline en C ? Ce n'est pas supporté par TIGCC/GCC4TI via un switch, alors comment faire ?J'ai clairement pas le niveau pour patcher ld-tigcc...

Ce n'est pas ld-tigcc qu'il faudrait patcher pour faire ça proprement, mais carrément GCC! (Cf. __builtin_ER_throw, mais je n'ai jamais eu le temps de faire ça pour les ROM_CALLs F-Line, et les RAM_CALLs F-Line sont tellement exotiques qu'ils n'étaient même pas sur ma liste TODO.) J'explique plus bas comment ça fonctionne pour les ROM_CALLs en pratique.

Pour rappel, il s'agit de produire le word 0xF000 + numéro du ramcall, avec les arguments sur la pile ou dans les registres.

Et si un handler différent de celui de PreOs est installé, ton programme plantera à l'instant.

Je suis prêt à utiliser des macros dégueulasses si c'est le seul moyen.

1. Tu utilises la définition "normale" des RAM_CALLs, celle que tu utiliserais pour les RAM_CALLs relogés.
2. Tu compiles en un fichier .s avec tigcc -S -fno-function-cse (le même switch que pour les ROM_CALLs en F-Line, qui garantit que le fichier .s contient l'instruction convenable) suivi des CFLAGS habituels et de ton fichier .c.
3. sed -i -e 's/^\tjsr _RAM_CALL_/\t.word 0xF000+0x/g' fichier.s
4. Tu continues à compiler en utilisant le fichier .s patché à l'étape 3 au lieu du .c.
C'est plus ou moins comme ça que fonctionnent les ROM_CALLs F-Line, sauf que l'étape 3 est faite automatiquement par le patcherhttp://tigcc-linux.cvs.sourceforge.net/viewvc/tigcc-linux/tigcc-linux/sources/patcher/src/patcher.c?revision=1.1.1.1&view=markup#l202. (Si on sépare les étapes 2 et 4, le patcher est automatiquement appelé à la fin de l'étape 2.) Mais c'est clairement un hack.

2. Comment appeler les ramcalls qui utilisent passent des arguments dans des registres aux fonctions appelées ?

Avec des asm("d0") comme d'habitude. (Le % n'est pas obligatoire à cet endroit.)

Je pense par exemple à LibsExec :

Cette API est une horreur, des varargs dans les registres, ce n'est pas du tout fait pour être utilisable en C.

Faut-il que j'écrive quelque chose comme ça pour faire l'appel qui me convient :

void modified_LibsExec(char *name, short function, char version, int truc asm("%d0"));
#define	modified_LibsExec	_RAM_CALL_1D

Dans l'idée, c'est ça ?

Non, ça ne va pas marcher comme ça, le #define doit passer avant le prototype. Et dès que tu as plus d'une fonction comme ça, GCC va gueuler parce que tu as plusieurs prototypes pour _RAM_CALL_1D. Tu peux essayer ça:
void modified_LibsExec(char *name, short function, char version, int truc asm("%d0")) asm("_RAM_CALL_1D");ou alors tu peux essayer de bidouiller avec _RAM_CALL_01D, _RAM_CALL_001D, …

Franchement, aucune de ces APIs de PreOs n'a été conçue en pensant au C, je ne peux donc que déconseiller leur utilisation, qui nécessite des hacks de partout.

Ç'a été pensé pour être utilisé en assembleur, parce que de toute façon y'a que Folco qui allait s'en servir, et Folco il code en assembleur. Parfaitement logique

test

Bon, ben ça fait deux fois que je pense avoir répondu et qu'en fait, non

Donc merci beaucoup Kevin, j'avais bien pensé à patcher les fichiers asm, je savais pas que c'était comme ça que c'était fait
Pour l'autre, on va tenter ^^

Quant à toi, Zerosquare, je me passe fort de tes insolences

Bon, j'ai écrit ça sur tes conseil, Kevin :LibRef* as_LibsExec(char *name, short function, char version, char* Libname asm("a0"), char LibVersion asm("d1"), short* FunctionsTable asm("a1"), short* OffsetsTable asm("a2"), void* TrampolinesTableBase asm("a3")) asm("_RAM_CALL_1D");Je l'appelle comme attendu :g.PdtlibRef = as_LibsExec(PDTLIB_STR, PDTLIB_INSTALL_TRAMPOLINES, PDTLIB_VERSION, PDTLIB_STR, PDTLIB_VERSION, PdtlibFunctions, PdtlibOffsets, &g);Les trois premiers arguments sont ceux de LibsExec, les suivants se rapportent à ma lib. En regardant le .s généré, j'ai l'impression que c'est parfait :

        move.l #262145,-(%sp)
        pea .LC1
        lea (-124,%fp),%a3
        lea PdtlibOffsets,%a2
        lea PdtlibFunctions,%a1
        moveq #1,%d1
        lea .LC1,%a0
        jsr _RAM_CALL_1D
        addq.l #8,%sp

C'est exactement ça, donc le trick de Kevin semble très bien marcher
Par contre, à l'exécution (sous PedroM), je jsr emmène en plein milieu de la RAM, dans une zone peuplée de zéro, et le programme crashe en essayant d'exécuter un classique ori.b #0,d0

Qu'est-ce qui peut se passer entre le .s et le .9xz pour que ça parte en sucette ?
Je compile et linke avec ça :

CFLAGS=-Wall -Wextra -O2 -std=c99 -I. -DUSE_TI89 -DUSE_TI89TI -DUSE_TI92P -DUSE_V200 -DUSE_FLINE_EMULATOR -DUSE_FLINE_ROM_CALLS -fno-function-cse --save-temps
# TODO what about fp as global reg and no link/unlk usage ?
LDFLAGS=--remove-unused --optimize-relocs --optimize-code --cut-ranges --reorder-sections -L/usr/local/share/gcc4ti/lib

Donc, comment investiguer plus que ça ?


Juste un peu plus bas, dans le code :

        jsr _RAM_CALL_1D
        addq.l #8,%sp
        cmp.w #0,%a0 // ?????????????????????????????????
        jbeq .L17
        move.l %a0,-116(%fp) // Pas besoin de d0-d1 ici !
        move.w #1,-122(%fp)
        lea (-122,%fp),%a0
        move.l %a0,-120(%fp)
        pea -52(%fp)
        .word _F_LINE+0x266

...

.L17:
        moveq #2,%d0
.L5:
        move.l -132(%fp),%a2  // ?????
        move.l -128(%fp),%a3
        unlk %fp
        rts

=>

moveq #2,d0
move.l a0,d1
beq ...

C'était pas compliqué...

Attention, au moins --cut-ranges doit aussi être passé à la compilation pour fonctionner correctement. Mais ça, normalement, ça ne cause pas de gros problèmes si tu ne l'as pas fait, ça fait juste que --cut-ranges ne va rien faire. (Les fichiers objet qui ne sont pas compilés avec --cut-ranges sont reconnus et le range-cutting désactivé pour ces sections.) Le plantage vient d'ailleurs.

Et attention aussi, jsr _RAM_CALL_1D a besoin d'un relogement pour fonctionner. Si tu veux quelque chose qui n'a pas besoin de relogement, tu dois le convertir en F-Line manuellement avec la ligne sed que j'ai donnée. (C'est peut-être ça, la source de ton plantage?) Et si tu passes un flag comme -l ou --short-jumps à l'assembleur, ça va aussi poser problème parce que le suffixe :l n'est pas précisé. (Pour les ROM_CALLs, le patcher le rajoute automatiquement, mais les RAM_CALLs n'étaient à l'origine prévus que pour des variables, pas des fonctions, donc il n'y a pas cette logique pour les RAM_CALLs.)

Merci pour --cut-ranges.
J'ai oublié ça : CC=tigcc -v -Wa,-l

Je m'occuperai du passage de jsr _RAM_CALL_xy à $F0xy plus tard, pour le moment c'est pas grave, l'essentiel est de résoudre le #2 du ./0

Donc pour le moment, je cherche à avoir un jsr vers un ramcall relogé, tout à fait normal.
Ah au fait, j'ai le message main.o: Warning: RAM calls cannot be relative; changing to absolute, j'ignore si c'est en rapport avec mon problème. Faudrait que j'analyse le header du binaire.

Folco (./7) :
J'ai oublié ça : CC=tigcc -v -Wa,-l

Donc c'est bien ce que je dis:

Kevin Kofler (./6) :
Et si tu passes un flag comme -l ou --short-jumps à l'assembleur, ça va aussi poser problème parce que le suffixe :l n'est pas précisé.

Si tu ne veux pas passer un coup de sed ou modifier le patcher:

Kevin Kofler (./6) :
(Pour les ROM_CALLs, le patcher le rajoute automatiquement, mais les RAM_CALLs n'étaient à l'origine prévus que pour des variables, pas des fonctions, donc il n'y a pas cette logique pour les RAM_CALLs.)

alors retire -Wa,-l. (De toute façon, ça ne devrait pas être nécessaire avec l'optimisation du linker.)

Je m'occuperai du passage de jsr _RAM_CALL_xy à $F0xy plus tard, pour le moment c'est pas grave, l'essentiel est de résoudre le #2 du ./0

Mais si tu t'occupes de ça, ton bogue disparaîtra aussi.

Ah au fait, j'ai le message main.o: Warning: RAM calls cannot be relative; changing to absolute, j'ignore si c'est en rapport avec mon problème.

Bah oui, -Wa,-l t'assemble la commande en jsr _RAM_CALL_1D(%pc), ce qui n'est pas valide. (Le linker émet un relogement en abs.w, ce qui fait qu'il prend (signed short)&_RAM_CALL_1D et le rajoute au %pc, ce qui bien sûr t'envoie n'importe où.) ld-tigcc émet souvent des warnings là où d'autres outils émettraient une erreur, il faut prendre au sérieux ces warnings.

Ok, donc on (tu ! ) a(s) fait le tour de ce problème, merci beaucoup

(J'ai lu en diagonale, mais un asm{ 0xff.... } n'aurait pas été plus simple ?)

Tu fais comment pour dire au compilateur de générer les arguments dans la pile et/ou les registres ?
Sinon pour l'appel en lui-même, oui bien sûr, c'est d'ailleurs ce que je fais en asm.

Bon, passons au problème suivant, dans le même topic.

J'utilise ça : http://tigcc.ticalc.org/doc/gnuexts.html#SEC97 pour essayer d'avoir un pointeur de portée globale dans mon programme (je pourrais m'en passer, mais je devrais le passer à chaque fonction, question perf c'est pas ça)
Dans main, je crée la variable localement :#include "Global.h" ... register GLOBAL* g asm("a5"); int _main(int argc, char** argv) { GLOBAL global; g = &global; ...Et dans Global.h :typedef struct { ... } GLOBAL; extern GLOBAL* g;Alors dans main, tout va bien, mais dans un fichier à côté, qui pourtant inclut Global.h d'entrée de jeu, j'ai cette erreur : Cmdline.o: Error: Unresolved reference to `g'.
Si j'enlève "register" et "asm ("a5")", tout semble fonctionner.
Donc comment exprimer les choses quand on utilise un registre ?


EDIT -> je devrais m'en tirer avec ça : http://tichessteamhq.yuku.com/topic/2025/Global-Register-Variables
-> pas de extern, parce que pas d'emplacement réservé dans le programme ?

Donc je dois mettre :
register GLOBAL* g asm("a4") dans mon header, rien dans main.c (pas de réservation d'espace dans le binaire en fait), c'est ça ?

Oui, c'est dans le header qu'il faut mettre ta déclaration.

Et tu devrais aussi mettre:
asm(".xdef __ref_all___save_all_registers_main")dans ton main.c. (Je le mettrais là où tu as mis ta déclaration.) Parce que sinon, ton registre sera détruit sans que rien ne le restaure, ce qui pourrait produire des mauvaises surprises. (Enfin bon, en mode kernel, ce n'est que le code de démarrage que tu pourrais faire foirer, parce que le kernel sauvegarde et restaure les registres, donc si tu utilises un registre que le code de démarrage n'utilise pas, tu peux t'en sortir sans ma ligne. Mais je mets cet avertissement au cas où.)

Merci.

Bon, j'ai maintenant un souci étonnant. Le pire, c'est que c'est à l'exécution, donc je devrais parfaitement comprendre ce qui se passe, surtout que ça m'a l'air nickel au niveau assembleur

Le screen du débogueur : Fichier joint :

main.s :

        move.l %a4,%a3
        move.l #262145,-(%sp) // $(4 << 16) + $1 : fonction 4, version 1 de Pdtlib, donc c'est bon.
        pea StrPdtlib
        lea PdtlibOffsets,%a2
        lea PdtlibFunctions,%a1
        moveq #1,%d1
        lea StrPdtlib,%a0
        jsr _RAM_CALL_1D

Le fichier qui contient PdtlibOffsets :

        .globl  PdtlibOffsets
        .text
        .even
PdtlibOffsets:
        .word   16
        .word   20
        .word   24
        .word   28
        .word   32
        ...

Au premier run, j'ai un "Unknown error" de PedroM quand le lea xyz,a2 est exécuté. Je ne sais pas ce qui pemet de faire déconner cette instruction...
Où dois-je chercher

edit -> OK, toujours pareil, dans un ramcall mal appelé :[
Pourtant, j'ai compilé d'une traite, en un seul appel, c'est tigcc qui fait sa sauce après

edit2 -> Le .s généré est bon, donc c'est l'assemblage ou le linking qui foire.
Je compile avec ça :
tigcc -v -std=c99 -Wall -W -O2 -I. -DUSE_FLINE_EMULATOR -DUSE_FLINE_ROM_CALLS -fno-function-cse -fomit-frame-pointer --save-temps --remove-unused --optimize-relocs --optimize-code --cut-ranges --reorder-sections -L/usr/local/share/gcc4ti/lib -DUSE_TI89 -DUSE_TI89TI -DUSE_TI92PLUS -DUSE_V200 *.c -o as
Qu'est-ce qu'il y a encore qui lui plait pas ?? Le ramcall est mal généré encore ? Je vais donc écrire mon propre patcher, ou utiliser ta ligne sed. Je pensais pouvoir m'en passer, tant pis ^^

Le désassemblage de ta capture d'écran s'arrête juste avant l'instruction intéressante.

Folco (./11) :
Tu fais comment pour dire au compilateur de générer les arguments dans la pile et/ou les registres ?

Mmmm, pareil, asm {} ?
Enfin franchement j'en sais rien, c'est juste que je me dis que, quitte à vouloir contraindre l'assembleur sur une petite portion, autant l'écrire directement (éventuellement avec une macro) plutôt que d'essayer de feinter le compilateur.
Mais c'est peut-être plus pénible aussi, j'ai pas réfléchi plus que ça

Si tu me dis comment dire au compilateur que tel bout de code asm renvoie ci ou ça dans d0/a0, effectivement ça serait le plus simple. Mais dépêche-toi, je suis en train d'écrire mon patcher

hmmm, ok : https://www.ocf.berkeley.edu/~pad/tigcc/doc/html/gnuexts_SEC94.html
Bon, ça a l'air d'être une solution, c'est con parce que je tenais une bonne raison d'écrire mon patcher

Kevin -> oui j'ai vu xD

Il y a bien un jsr absolu, déjà ça, c'est bon. Ensuite, je constate que c'est une adresse en ROM, mais si tu utilises PedroM, c'est normal. Je n'ai pas l'impression que ce soit la chaîne d'outils qui déconne.

Folco (./18) :
Mais dépêche-toi, je suis en train d'écrire mon patcher

Pourquoi pas modifier celui qui existe déjà au lieu de réinventer la roue?

hmmm, ok : https://www.ocf.berkeley.edu/~pad/tigcc/doc/html/gnuexts_SEC94.html
Bon, ça a l'air d'être une solution, c'est con parce que je tenais une bonne raison d'écrire mon patcher

On peut effectivement faire beaucoup de choses avec les asm de GCC, mais ça a quand-meme des limitations, le code produit n'est pas toujours optimal. Mais si ça marche suffisamment bien pour toi, pourquoi pas?

Kevin Kofler (./19) :
mais si tu utilises PedroM

yep.

Kevin Kofler (./19) :
Je n'ai pas l'impression que ce soit la chaîne d'outils qui déconne.

Faut que je regarde si c'est bien le ramcall qui m'intéresse qui est appelé.

Kevin Kofler (./19) :
Pourquoi pas modifier celui qui existe déjà au lieu de réinventer la roue?

C'est 100 fois plus simple de faire un remplacement que d'ajouter une fonctionnalité à TIGCC, non ? J'ai même pas regardé le patcher, faudrait que je mette le nez dedans, que je le comprenne. Mais pourquoi pas.

Le patcher est un petit programme en C que j'ai écrit (enfin, j'ai en grande partie traduit le code Delphi de Sebastian, et il y avait aussi du code de Romain Liévin que j'ai gardé en partie).
http://tigcc-linux.cvs.sourceforge.net/viewvc/tigcc-linux/tigcc-linux/sources/patcher/

Ok, merci bien, c'est vrai que c'est un programme simple.

Le pire, c'est que la transformation pour les _RAM_CALLs y est à moitié (le remplacement jbsr → jsr est fait pour tout _CALL_), mais il manque le rajout du :l. Je ne me rappelle pas exactement de l'historique (et ça doit dater d'avant le CVS), mais je soupçonne que les 2 remplacements aient été rajoutés à des moments différents.

Quand je fais un tigcc -S ..., j'ai des jsr _RAM_CALL_xy, et non des jbsr. 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é ?

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 $F003, mais j'ai ROM_BASE dans a0 après l'exécution du handler.

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.

(tiens, j'avais un '0' en trop dans mon word )
(mais qui s'amuse à écrire du C indenté comme ça ?? ^^ perso j'utilise clang-format, comme ça j'ai pas à me fatiguer, et c'est toujours nickel, je peux admirer )

Bon, vraie question, comment obtenir quelque chose comme .set USE_FLINE_RAMCALL 1 dans mon .s ? Je dois chercher ailleurs, dans GCC ? Où et généré ce texte ?

Bah, le code indenté bizarrement est de Romain Liévin, celui indenté en K&R comme il faut est de moi ou du moins a été reformatté par moi.

Folco (./26) :
Bon, vraie question, comment obtenir quelque chose comme .set USE_FLINE_RAMCALL 1 dans mon .s ? Je dois chercher ailleurs, dans GCC ? Où et généré ce texte ?

Bah, le #define C vient de la ligne de commande (-DUSE_FLINE_RAM_CALLS) normalement. (C'est comme ça qu'on fait pour les ROM_CALLs.) Ensuite, pour l'avoir dans le fichier .s, c'est un simple:

#ifdef USE_FLINE_RAM_CALLS
asm(".set …");
#endif

dans les headers, cf. http://tigcc-linux.cvs.sourceforge.net/viewvc/tigcc-linux/tigcc/include/C/default.h?revision=1.4&view=markup#l233.

Ok, merci.

Bon, je suis en train de patcher le patcher, mais j'ai une question : à quoi sert ce code, qui s'occupe des romcalls ? // handle F-LINE ROM_CALLs if (fline_ROM_CALLs && !strncmp(buffer,"\tjsr _ROM_CALL_",15) && strlen(buffer)<=18) { memmove(buffer+3,buffer+1,strlen(buffer)); // replace "jsr _ROM_CALL_" strncpy(buffer+1,".word _F_LINE+0x",16); // with ".word _F_LINE+0x" } else { // add :l to ROM_CALLs char *p4=strstr(buffer,"_ROM_CALL_"); while (p4) { char *p5=p4; p4+=10; while (isalnum(*p4)||*p4=='_'||*p4=='+'||*p4=='-'||*p4=='*'||*p4=='/') p4++; while (*p4==':'||isalpha(*p4)) memmove(p4,p4+1,strlen(p4)); // zap :w if it's there if (strlen(buffer)>32769) break; // avoid buffer overflow memmove(p4+2,p4,strlen(p4)+1); *(p4++)=':'; // add ":l" *(p4++)='l'; if (!strncmp(p4,"(%pc)",5)||!strncmp(p4,"(%Pc)",5)||!strncmp(p4,"(%pC)",5)||!strncmp(p4,"(%PC)",5)) { memmove(p4,p4+5,strlen(p4+5)+1); } else if ((!strncmp(p4,",%pc)",5)||!strncmp(p4,",%Pc)",5)||!strncmp(p4,",%pC)",5) ||!strncmp(p4,",%PC)",5)) &&(p5>buffer)&&(p5[-1]=='(')) { memmove(p4,p4+5,strlen(p4+5)+1); memmove(p5-1,p5,strlen(p5)+1); } p4=strstr(p4,"_ROM_CALL_"); } p4=strstr(buffer,"__ld_calc_const_"); while (p4) { char *p5=p4; p4+=16; while ((*p4>='0'&&*p4<='9')||(*p4>='a'&&*p4<='z')||(*p4>='A'&&*p4<='Z')||(*p4=='_')||(*p4==':')) p4++; if (!strncmp(p4,"(%pc)",5)||!strncmp(p4,"(%Pc)",5)||!strncmp(p4,"(%pC)",5)||!strncmp(p4,"(%PC)",5)) { memmove(p4,p4+5,strlen(p4+5)+1); } else if ((!strncmp(p4,",%pc)",5)||!strncmp(p4,",%Pc)",5)||!strncmp(p4,",%pC)",5) ||!strncmp(p4,",%PC)",5)) &&(p5>buffer)&&(p5[-1]=='(')) { memmove(p4,p4+5,strlen(p4+5)+1); memmove(p5-1,p5,strlen(p5)+1); } p4=strstr(p4,"__ld_calc_const_"); } }Le if, ok, c'est le remplacement du relogement par un appel F-line.
Juste une incompréhension : pourquoi strlen(buffer)<=18 ?

Par contre, le else...

A quoi sert cette ligne ? while (isalnum(*p4)||*p4=='_'||*p4=='+'||*p4=='-'||*p4=='*'||*p4=='/') p4++;
Ou plutôt, dans quel cas on peut tomber sur un tel code ? isalnum() ok, mais les signes ??

while (*p4==':'||isalpha(*p4)) memmove(p4,p4+1,strlen(p4)); // zap :w if it's there
Là, il vaut mieux ne pas avoir trifouillé dans le .s à la main, parce que question algo c'est pas clean

Ensuite, par quel miracle pourrait-on avoir un romcall pc-relatif, avec offset ou non d'ailleurs ?

Enfin, que vient faire __ld_calc_const ?

Merci bien.

ps -> question d'ordre général : pourquoi des strncmp/strncpy plutôt que leur version sans 'n' ?