qui sait mettre d jeux sur ti89???? - Page 6

comment j'ai fait pour ma ROM...

ah oui c'était le ldscript qui a placé ma section .data et .bss dans la RAM.
Donc les adresses étaient déja en dur

OK, et ton programme accédait à ces données par le biais d'un registre ?

ben non, piske la section .text savait que la section .data devait être à une adresse en RAM (mais fixe, on peut pas utiliser ça pour des programmes chargeables dynamiquement)

D'accord, mais comment est-on sûr que le handle sera à telle adresse précisément ?

y'a pas de handle.
le linker (ld officiel de binutils) fait des relocations statiques pour toucher les bonnes adresses.

Je comprends rien

quand je fais mon programme, j'utilise un ldscript pour donner l'adresse de début des sections au linker qui fusionne les fichiers objets. donc quand il trouve un symbole qui est dans la section .data, il donne directement la bonne adresse.

Oui mais tu parlais de mettre des variables globales en RAM.

ben.. oui c'est des variables globales que je parle... les variables locales sont sur la pile

Oui donc ma question est justement : Comment les adresses de ces variables peuvent-elles être inscrites en dur dans le programme ? Comment l'éditeur des liens sait-il à l'avance où sera logé le handle qui les contiendra ?

C'est un Flash OS entier, comme PedroM, donc il faut ce qu'il veut avec la RAM.

Ah OK Et pour un programme classique :

Thibaut (./148) :
Y'a-t-il des options à activer sur le linker pour respecter toutes les conditions (pas de relogements, etc) ?

Non, parce qu'il y a du code de TIGCCLIB qui n'est pas PC-relatif et même du code automodifiant dans TIGCCLIB.

Non
Kevin : J'utilise pas la bibliothèque de TIGCC.

Thibaut (./166) :
Kevin : J'utilise pas la bibliothèque de TIGCC.

Tu l'utilises que tu le veuilles ou pas (code de démarrage, fonctions internes de type __mulsi3 etc.).

Non, tigcc.a est un composant essentiel de TIGCC.
D'ailleurs, les stubs et headers kernel sont là-dedans, donc bonne chance pour faire du kernel sans tigcc.a.

Justement, mon point de vue est que TIGCCLIB n'est pas optionnel, sauf évidemment pour les targets bien particuliers (Fargo, Flash OS) qui viennent avec leurs propres stubs et qui auraient aussi besoin de leur propre librairie de fonctions (actuellement leurs .a ne contiennent que les stubs et/ou headers).

et de toute façon, vu qu'un .a est une collection de tous petits .o, le linker n'insère dans le binaire qu'uniquement ce qui est nécessaire. Tu ne trouveras jamais de stubs nostub dans un programme kernel, seulement parce que ton code n'y fait pas référence.

imaginez qu'un .a c'est une archive de .o, donc on les insère pas tous dans le binaire final, juste ce qui est nécessaire

Kevin ./168 : Et ces fonctions se modifient elles-mêmes ? Elles utilisent des adresses relogées ?

Le code de démarrage utilise des variables globales à l'intérieur du code à certains endroits, donc c'est comme du code automodifiant. Il n'y a pas de relogements dans le code de démarrage normalement parce qu'il peut tourner avant que le relogement soit effectué en fonction de la méthode de relogements, mais il y a ces variables. Par exemple __calculator, le modèle de calculatrice détecté, pour éviter de devoir refaire le test à chaque utilisation. Il y en a d'autres aussi. On ne peut pas rendre ces variables externalisables pour plusieurs raisons: les sections externes ne sont pas encore allouées à cet endroit (c'est le code de démarrage qui le fait), efficacité des accès, ... Et de toute façon l'externalisation automatique des fichiers de données fonctionne avec des relogements, donc ce n'est pas possible non plus dans ton cas.

./167: Pas mal. Sauf que j'aurais fini en :
lea.l table(pc),a0
jmp flashlib@0000

Si tu fais un kernel::exec, Preos va surement désarchiver ton programme, et donc il ne sera en flash.

PreOS exécute-t-il en Flash automatiquement les programmes dénués de table de relogement ?