Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum Ti68K » Programmation Assembleur 68K » sprintf et F-Line (79 réponse(s))

./REPRISE DU POST PRECEDENT (post n°19) Marquer comme non lu.

Kevin Kofler

Ecrit le: Mercredi 15 mars 2006 à 17:03

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Ça ne va pas marcher parce que plein d'allocations sont faites à l'intérieur de AMS, qui bien sûr appelle les fonctions d'allocation par adresse absolue. Si tu veux intercepter tous les ROM_CALLs qui peuvent allouer de la mémoire directement ou indirectement, tu ne vas pas t'en sortir. La seule manière de voir ce qui a été alloué de manière fiable est de comparer la table du heap. Et pour libérer un cache lorsqu'une allocation échoue (et ensuite relancer l'allocation), c'est impossible de faire ça de manière fiable, il y a plein d'endroits où de la mémoire est allouée. La solution de PpHd marche peut-être dans le contexte bien précis de CF (et encore, je n'en suis pas aussi sûr que lui), mais il est absolument impossible de faire marcher ça dans un programme plus général (qui utilise des ROM_CALLs non-triviaux) sans patcher AMS.
-Edité le Mercredi 15 mars 2006 à 17:07 par Kevin Kofler-

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°20 Marquer comme non lu.

Folco

Ecrit le: Jeudi 16 mars 2006 à 08:21

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ouep, tu as sûrement raison si on parle de l'ensemble des ROM calls. Maintenant, si le gestionnaire de cache ne peut intercepter qu'une partie des appels (par F-Line et par table des ROM calls), ça sera toujorus ça de pris.
Quant à la méthode de PpHd, la gestion du cache m'a l'air d'être complètement laissée à l'utilisateur, perso j'imagine quelquechose de beaucoup plus directif, ie beaucoup plus transparent pour l'utilisateur.

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°21 Marquer comme non lu.

Folco

Ecrit le: Jeudi 16 mars 2006 à 11:54

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Au fait Sasume:

Sasume :
Par contre, le terme F-Line est adopté parce que les 8 premiers bits des instructions concernées sont tous armés, donc en hexa ça donne F.

ouep

j'avais dû lire le post en speed, parcequ'en relisant le topic, ça m'a sauté aux yeux

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°22 Marquer comme non lu.

Folco

Ecrit le: Lundi 20 mars 2006 à 12:15

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Bon Kevin, je suis en train de passer à GNU as, définitivement si j'arrive à résoudre ces quelques menus problèmes.

je veux utiliser os.h de /include/S/ pour les ROM calls, sachant que je ne veux pas de relogement, et uniquement des appels en F-Line. ok. Par contre, comment faire pour les RAM calls? ils ne sont pas définis dans le header...
et quoi utiliser si malgré tout, je veux utiliser les relogements kernel pour les ROM calls? il me faut quel header?

Comment faire pour faire un programme kernel à partir de ce header? dans tios.h, on trouvait _main, _mistub, _install_preos et tous les autres exports pour le kernel. Là, il n'y a rien, si je compile ça me fera du _nostub non?

un appel de lib, ça se définit comme ça?:
.set lib::0000, lib__0000

vala vala, j'aimerais juste retrouver mes points de repères pour faire du programme kernel et des libs dynamiques avec GNU as (pour le nostub, je sais car j'en ai déjà fait).

Merci d'avance!

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°23 Marquer comme non lu.

Kevin Kofler

Ecrit le: Lundi 20 mars 2006 à 13:01

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Martial Demolins :
je veux utiliser os.h de /include/S/ pour les ROM calls, sachant que je ne veux pas de relogement, et uniquement des appels en F-Line. ok. Par contre, comment faire pour les RAM calls? ils ne sont pas définis dans le header...
et quoi utiliser si malgré tout, je veux utiliser les relogements kernel pour les ROM calls? il me faut quel header?

Les headers kernel n'ont pas été portés pour GNU as, faudra que quelqu'un le fasse (pourquoi pas toi?)... Enfin bon, le mode kernel est obsolète de toute façon.

Comment faire pour faire un programme kernel à partir de ce header? dans tios.h, on trouvait _main, _mistub, _install_preos et tous les autres exports pour le kernel. Là, il n'y a rien, si je compile ça me fera du _nostub non?

Euh, non, le mode par défaut du linker est toujours le mode kernel pour des raisons de compatibilité, c'est .xdef _nostub pour mettre en _nostub sans code de démarrage (obsolète), et .xdef _tigcc_native; .xdef __ref_all___startup_code; .xdef __ref_all___nostub; .xdef __main; __main: pour le _nostub avec code de démarrage (plus flexible, mais si tu ne mets rien d'autre que ces 4 xdefs-là, le code de démarrage sera un simple jmp qui est viré par le linker). Mais bien sûr, avec os.h, tu n'utilises pas les fonctionnalités du kernel, donc ça ne sert à rien d'être en kernel.

un appel de lib, ça se définit comme ça?:
.set lib::0000, lib__0000

Je ne pense pas que le :: passe, à mon avis tu dois utiliser __ partout.

Et la syntaxe pour les fonctionnalités du kernel est la même qu'avec A68k (normal, c'est le linker qui gère ça), sauf que tu dois utiliser __ à la place de @ qui n'est pas autorisé dans les noms de symbole. (A68k accepte vraiment tout et n'importe quoi, un @ n'a strictement rien à faire dans un nom de symbole!)
-Edité le Lundi 20 mars 2006 à 13:02 par Kevin Kofler-

./Post n°24 Marquer comme non lu.

Folco

Ecrit le: Lundi 20 mars 2006 à 13:07

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ok, merci pour les libs, je vais me débrouiller pour un header kernel, et je te le proposerai d'ailleurs.

(d'ailleurs, comment l'appeler? doorsos.h aussi? tios.h?).

Sinon, merci pour les autres renseignements, je vaisd me débrouiller avec tout ça.

(par contre, "le mode kernel est obsolète", ça c'est toi qui le dit

)
-Edité le Lundi 20 mars 2006 à 13:08 par Martial Demolins-

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°25 Marquer comme non lu.

Kevin Kofler

Ecrit le: Lundi 20 mars 2006 à 15:50

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Martial Demolins :
ok, merci pour les libs, je vais me débrouiller pour un header kernel, et je te le proposerai d'ailleurs.

(d'ailleurs, comment l'appeler? doorsos.h aussi? tios.h?).

Hmmm... D'un côté, DoorsOS est totalement obsolète, d'un autre c'est le nom que TIGCC a toujours utilisé, et c'est le kernel qui a inventé le format. Mais peut-être que le changement de syntaxe est le bon moment pour changer ça aussi? Cela dit, je ne suis pas sûr que tios soit tellement mieux que doorsos comme nom, le nom "TIOS" est un nom inventé par Fargo qui n'a jamais officiellement existé, l'OS de la TI-92 n'avait pas de nom et celui des nouvelles TIs s'appelle AMS. Et sinon, utiliser un nom comme "tios" ou "ams" n'indique pas clairement qu'il s'agit d'un header kernel (ce que doorsos.h faisait très bien). Bref, je ne sais pas trop, je trouve que doorsos.h est mieux que tios.h, mais ce n'est pas parfait non plus (surtout vu que les ROM_CALLs de AMS en doorsos::, c'est moyen).

Peut-être que la bonne solution, c'est d'appeler le header "doorsos.h", mais d'appeler les ROM_CALLs "ams__FirstWindow" etc. au lieu de "doorsos::FirstWindow". (Virer le préfixe complètement n'est pas une très bonne idée parce que ça empêche d'inclure os.h en même temps et donc d'utiliser les ROM_CALLs en F-Line.)
-Edité le Lundi 20 mars 2006 à 15:52 par Kevin Kofler-

./Post n°26 Marquer comme non lu.

Sasume

Ecrit le: Lundi 20 mars 2006 à 16:15

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Pourquoi pas kernel.h ?

./Post n°27 Marquer comme non lu.

Folco

Ecrit le: Lundi 20 mars 2006 à 16:19

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

d'accord avec toi, il faut garder un préfixe pour les appels qui seront relogés, parcequ'on peut très bien être applé à utiliser en même temps des appels relogés et en F_Line.
"ams__ROM_call" me semble bien. Je pars sur cette idée, c'est ok. Quant au nom du header, je suis pas super chaud pour doorsos, il existe plus depuis tellement longtemps... à part pour le côté nostalgie?

je réfléchirai si je trouve un truc, on verra ben

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°28 Marquer comme non lu.

Folco

Ecrit le: Lundi 20 mars 2006 à 16:19

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

cross. kernel.h, j'y ai pensé, mais c'est déjà un header de PreOS...

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°29 Marquer comme non lu.

Sasume

Ecrit le: Lundi 20 mars 2006 à 17:16

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Bah attends, tu veux écrire un header qui sert à quoi ?

./Post n°30 Marquer comme non lu.

Folco

Ecrit le: Lundi 20 mars 2006 à 17:21

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

compiler en kernel avec GNU as. actuellement, il y a pas de header.mais je suis d'accord avec toi, en soi le nom du header serait idéal. c'est ce que je garderai probablement pour moi, après, Kevin fera ce qu'il en voudra s'il veut intégrer ça à la distrib de TIGCC.

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°31 Marquer comme non lu.

Sasume

Ecrit le: Lundi 20 mars 2006 à 17:48

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Euh je suis un peu perdu, dsl

Il contiendra quoi, ce header ? Pourquoi est-il nécessaire ?

./Post n°32 Marquer comme non lu.

Kevin Kofler

Ecrit le: Lundi 20 mars 2006 à 18:55

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Les définitions GNU as correspondant au doorsos.h A68k.

./Post n°33 Marquer comme non lu.

Link

Ecrit le: Lundi 20 mars 2006 à 21:06

Membre: Magister

Messages: 302

Membre n°896

Inscrit le 25 juin 2005

J'ai du mal à comprendre précisément ce que c'est, mais s'il déclare seulement des fonctions kernel, je conseillerais "oldkrnl.h"
Par contre, s'il définit des ROM_CALLs (ainsi que l'aurait indiqué "ams.h" ou "tios.h"), je conseillerais quelque chose comme "kernelos.h", qui signifierait quelque chose comme "header kernel pour les fonctions de l'OS"...

./Post n°34 Marquer comme non lu.

Folco

Ecrit le: Mardi 21 mars 2006 à 08:03

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ouep, ça me semble pas être de bonnes idées link.
oldkrnl.h-> c'est bizare pour compiler pour le dernier kernel à jour.
kernelos.h-> ça serait déjà mieux, mais il n'y aura de toute façon pas que les ROM calls, mais aussi toutes les macros et RAM call présent dans tios.h.

penche-toi sur tios.h ou doorsos.h pour voir de quoi il retourne.

et au fait Kevin, les RAM calls tiendront plus de ceux de tios.h que de doorsos.h, je vais certainement pas écrire un header qui ne puisse pas utiliser les features de PreOS.

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°35 Marquer comme non lu.

Sasume

Ecrit le: Mardi 21 mars 2006 à 08:21

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Ah oui, j'ai compris, tu veux faire l'équivalent de tios.h de PpHd, pour GNU AS.
Je te conseille alors d'utiliser le nom tios.h.

./Post n°36 Marquer comme non lu.

Folco

Ecrit le: Mardi 21 mars 2006 à 10:26

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ouep, tu as bien compris, et tios.h, c'est faisable aussi, ça faciliterait la compréhension, c'est sûr. Mais ne fait, les headers kernels ont toujours été limite foireux sur TI, et on retrouve dans un header du tios des tonnes de trucs qui sont là pour la compatibilité, mais qui n'ont rien à voir avec le tios

. c'est pour ça que ce nom de tios.h, même si tout le monde le comprendrait directement, ça serait pas non plus idéal.

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°37 Marquer comme non lu.

Folco

Ecrit le: Mardi 21 mars 2006 à 12:16

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Première ébauche, il n'y a que les symboles, les ROM calls et les RAM calls.
Vu que GNU as est beaucoup plus récent que A68k, je ne mettrai probablement pas toutes les équivalences à base de doorsos::globals etc..., complètement obsolètes, et qui n'ont jamais dû exister avec GNU as.

Il me reste par contre les macros à mettre, même si ça doit pas être non plus ce qui est le plus utilisé.

Kevin va probablement gueuler contre les RAM calls et les symboles

, mais j'aimerais plutôt qu'on arrive à s'entendre sur une solution intelligente.

le header: http://databob.free.fr/Volume/files/00000033/kernel.txt

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°38 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 21 mars 2006 à 15:02

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

|======================
| Symbols
|======================
_library
_ti89ti
_ti89
_ti92plus
_v200
_mistub
_readonly
_install_preos
_nosavescreen

1. Ça ne sert à rien de mettre ça avec GNU as, vu que tu peux mettre un .xdef sans un label qui correspond (et c'est ce que TIGCCLIB fait partout pour les symboles de contrôle du linker, donc ça ne risque pas de changer).
2. Il n'y a que les 5 premiers symboles qui ont un sens avec TIGCC. _mistub et _install_preos ne sont pas supportés par ld-tigcc et _readonly et _nosavescreen sont à noter à travers leur numéro de flag (_flag_2 pour _nosavescreen). (C'est aussi pour ça que je dis qu'il ne faut pas utiliser le tios.h de PpHd avec TIGCC.) Ce n'est pas que je n'aime pas ces symboles, mais qu'ils ne fonctionnent pas, donc ça ne sert à rien de les mettre.

Quant à tes RAM_CALLs, il manque le .equ ou .set (GNU as ne distingue pas les deux).
-Edité le Mardi 21 mars 2006 à 15:03 par Kevin Kofler-