Problème avec TIGCC/a68k - Page 4

PpHd (./82) :
Mais le problème provient du fait que main n'exporte que 4 symboles et pas 6. Bug du linkeur de tigcc je dirais donc

Non, bogue de son code, comme tu l'as vu par la suite:

PpHd (./84) :
Essaye de reformuler tes xdef dans screen.asm (1 par ligne).

Pas le droit de mettre 2 xdef par ligne, du moins pas avec A68k.

Martial Demolins (./91) :
Kevin, mes xdef étaient comme ça:

	xdef	Synchro15fps,	main@0003
	xdef	Synchro30fps,	main@0004
	xdef	PortSetLG,	main@0005
	xdef	PortSetDG,	main@0006

Normal que ça déconne?

Oui.
Si A68k voit des trucs en trop en fin de ligne, il les considère comme des commentaires.

Martial Demolins (./95) :
J'avais un export pour une ttable de tile que j'utilise pas encore (encore nommé rbmain@0003) et un autre export vers une routine de synchro nommé main@0003, et ce tndouille de a68k a cru bon de devoir compiler sans rien dire, et en utilisant rbmain@xx à la place de main@xx. Il ne doit regarder que les numéros, et pas les préfixes, au lieu de balancer une erreur bien propre.

C'est ton code qui ne va pas là, tu n'as pas le droit d'exporter rbmain@0003 dans le programme main.

ld-tigcc s'en fout de si tu mets main@0003, rbmain@0003 ou toto@0003, si tu exportes machin@0003, c'est pris comme un export de ton programme actuel.

Et tu ne devrais pas utiliser main@0003 à l'intérieur du logiciel main lui-même, parce que ça crée une importation de lib au lieu d'une référence directe.

Ça bogue parce que tu l'as mis en equ. (Enfin, ce n'est probablement pas censé boguer, mais ça le fait, et de toute façon ça ne résoudrait pas du tout ce problème.)

Tu es censé mettre ça:

main@0003:
main::machin-chouette:

et utiliser main::machin-chouette à l'intérieur de main et main@0003 à l'extérieur.

J'ai regardé le testcase du ./56:
* Le bogue est entièrement dans l'assembleur, déjà à l'entrée du linker (DUMP 0), le code est mauvais.
* Le bogue se produit avec ou sans mode all-relocs.
* C'est la même chose avec un relogement absolu.
* Ce n'est pas non plus un problème avec test@0000 vu que c'est entièrement dans l'assembleur (qui s'en fout de ces noms spéciaux), j'ai aussi vérifié en mettant test à la place, ça ne change rien.

Bref, le problème est que A68k nous met l'endroit du equ au lieu du symbole à droite du equ.

Test-case réduit et sans headers non supportés (tios.h - doorsos.h est le header kernel maintenu de TIGCC):

test2 equ test

_nostub: xdef _nostub
_ti89: xdef _ti89

_main:
 lea.l test(pc),a0
 lea.l test2(pc),a0
 rts

test: dc.l 0

Martial Demolins (./100) :
C'est solvable comme problème? Je veux dire, tu vas corriger pour qu'on puisse utiliser des file::func comme dans les libs dynamiques?

La solution du ./98 ne te va-t-elle pas?

Kevin Kofler (./101) :
tios.h - doorsos.h

Je suis tout à fait d'accord !

Citation hors-contexte.
moi -> <- tios.h

Notre doorsos.h est régulièrement regénéré avec la liste des ROM_CALLs la plus récente extraite de la documentation de TIGCC par hsf2RC. Ça n'a plus grand chose à voir avec le doorsos.h d'origine, sauf que c'est compatible! tios.h, lui, en est toujours aux ROM_CALLs de AMS 1.01.

Le mode kernel est obsolète, c'est pour ça qu'il ne se passe plus grand chose pour les headers kernel.

Il ne se passe plus grand chose tout court

> Il ne se passe plus grand chose tout court
Je lui ai écrit un mail à ce sujet, mais il n'a pas répondu...

J'avais vu venir le contenu de ./109

Martial Demolins (./114) :
Le Joypad de genlib fait bien une lecture du clavier à bas niveau? Il n'y a pas de touches stockées dans un tampon?

Oui. Non.

C'est vrai que AS est bien mieux que A68K. A l'époque j'avais pas mal de pbs avec A68K (bugs, optimisations, syntaxe chiante...).