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))

./POST DE DEPART (post n°0) Marquer comme non lu.

Folco

Ecrit le: Jeudi 9 mars 2006 à 16:20

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

J'ai deux questions bien distinctes:
quel Line Emulator faut-il utiliser pour les ROM calls? et un appel valide est de la forme:
dc.w 0xfline+ROM_CALL ?

comment utiliser sprintf en asm, vu que le nombre d'argument est variable? comment pousser ça sur la pile, comment fait le tios pour savoir qu'il doit s'arrêter?
comment passer les séquences d'échapement en asm?

<<< 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°1 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 9 mars 2006 à 22:59

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

1. Il me semble que c'est dc.w 0xf000+ROM_CALL.
C'est donc le F-Line (et l'émulateur n'est nécessaire que sous AMS < 2).

2. Comme les autres fonctions : tu empiles tes arguments dans le même ordre que d'habitude.
La fonction lit les arguments au fur et à mesure qu'elle rencontre les séquences de formatage dans la chaine de formatage.
Il faut juste faire attention aux données codées sur un octet, quand tu les pousses sur la pile il faut au préalable les étendre sur un word pour que sprintf les gère correctement.
Quel est le pb pour écrire les séquences d'échappement en ASM ?

./Post n°2 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 10 mars 2006 à 02:13

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

C'est 0xf800+num, pas 0xf000+num.

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°3 Marquer comme non lu.

Folco

Ecrit le: Lundi 13 mars 2006 à 08:10

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ok, merci pour le fline.
pour les séquences d'échappement, je ne sais pas comment transcrire un \n par exemple. Je dois coder ces deux octets en dur?

<<< 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°4 Marquer comme non lu.

Link

Ecrit le: Lundi 13 mars 2006 à 08:21

Membre: Magister

Messages: 302

Membre n°896

Inscrit le 25 juin 2005

Je ne pense pas: Un \n ne fait toujours qu'un seul caractère. D'ailleurs, l'assembleur doit accepter DC.b '\n'

Par contre, pour les formats de printf, évidemment, eux doivent être en dur (%d, etc).

./Post n°5 Marquer comme non lu.

Kevin Kofler

Ecrit le: Lundi 13 mars 2006 à 08:46

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

A68k n'accepte pas \n (ni aucune autre séquence d'échappement, il interprète le \ comme un caractère comme les autres). (Raison de plus de ne pas l'utiliser.)
GNU as est codé correctement et accepte les séquences d'échappement.
Bref, arrêtez d'utiliser A68k, de toute façon vous devrez le faire quand TIGCC arrêtera de supporter cet assembleur obsolète.

./Post n°6 Marquer comme non lu.

Folco

Ecrit le: Lundi 13 mars 2006 à 08:52

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Ok, je m'en doutais un peu

Mais je vais y venir #oui#

Sinon, à quoi servent les deux F-Line utilisés par le tios? l'un est pour les ROM calls, l'autre pour les erreurs non? Peut-on réécrire un handler pour celui qui gère les erreurs si on ne compte pas utiliser des ROM calls l'utilisant (je suppose que HeapAllocThrow, par ex., utilise ce F-Line)?
Et si je comprends bien, ce sont les 8 premiers bits de l'instruction qui vont provoquer l'exeption F-Line, et non les 4 premiers comme je le pensais?

Et que fait PreOS avec les F-Line? Il en réécrit un, mais juste pour des raisons de compatibilité, ou il a besoin des deux pour tourner?

<<< 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°7 Marquer comme non lu.

Sasume

Ecrit le: Lundi 13 mars 2006 à 09:06

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Martial Demolins :
Sinon, à quoi servent les deux F-Line utilisés par le tios? l'un est pour les ROM calls, l'autre pour les erreurs non?

Oui, d'après la doc de TIGCC, l'autre est utilisé par le TIOS pour gérer les erreurs.
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.
Pour l'autre, c'est une autre forme d'opcode qui est concernée, donc on ne l'appelle pas F-Line (je crois que c'est un A).

Peut-on réécrire un handler pour celui qui gère les erreurs si on ne compte pas utiliser des ROM calls l'utilisant (je suppose que HeapAllocThrow, par ex., utilise ce F-Line)?

Je pense que oui, mais fais bien attention à ne pas utiliser de ROM_CALL utilisant un ROM_CALL utilisant un ROM_CALL ... utilisant le Line en question.

./Post n°8 Marquer comme non lu.

Folco

Ecrit le: Lundi 13 mars 2006 à 09:28

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ok Sasume, merci pour ce conseil de prudence!

<<< 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°9 Marquer comme non lu.

Kevin Kofler

Ecrit le: Lundi 13 mars 2006 à 17:48

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Si tu cherches des opcodes non-utilisés, 0xF000-0xF7FF devrait être à ta disposition. (PreOs convertit ça en "Crash Intercepted" et AMS en une barre noire avec "Line 1111 Emulator" écrit dedans, donc ça m'étonnerait que des programmes utilisent ça.

)

./Post n°10 Marquer comme non lu.

Folco

Ecrit le: Mardi 14 mars 2006 à 07:58

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

oué merci, c'est ce que je cherchais! #top#

<<< 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°11 Marquer comme non lu.

Folco

Ecrit le: Mardi 14 mars 2006 à 11:03

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

bon, sachant qu'on peut aller de $F000 à $F7FF, ça me laisse donc 4 bits pour me faire un flag, et 8 pour y mettre des données.

mais c'est formidable tout ça!

d'ailleurs, j'ai écrit des specs ce week-end, en espérant qu'un appel s'écrive ainsi, et c'est le cas.

imagine, tous les appels d'allocation, les bsr/bra et jsr/jmp, ainsi que les rts retournant vers une autre routine que celle en cours d'éxécution, tout ça en 2 petits octets.

elle est pas belle la vie?

<<< 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°12 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 14 mars 2006 à 11:17

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Euh, c'est 3+8 ou 4+7 seulement...

./Post n°13 Marquer comme non lu.

Folco

Ecrit le: Mardi 14 mars 2006 à 11:22

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ben oui c'est vrai.
alors ce sera 4 + 7, 128 routines suffiront bien dans la lib

à moins que je me prenne un flag de 4+7 bits, et carrément 2 octets en plus pour l'autre info.

t1 tout ça pour faire un système de cache complètement transparent, je pense être encore moins gourmand que le système de PpHd, plus simple (ben oui, l'utilisateur a rien à faire quand il code, juste changer les appels de ROM calls par un appel en F-Line, et je le récupère, pareil pour les sauts [ dc.w F_LINE+tag jbsr ou jbra+n° de procédure, sachant que c'est un tag spécial en cas de rts]
et ce ausis bien en kernel qu'en nostub, elle est belle la vie

<<< 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°14 Marquer comme non lu.

Folco

Ecrit le: Mardi 14 mars 2006 à 16:08

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

extrait de backgammon de Kevin:

...
  .set _F_LINE,0xF800
  .set _A_LINE,0xA000
...
.L436:
  move.w %d0,-(%sp)
  pea .LC28-__relation(%a4)
  move.l %a6,%d7
  subq.l #4,%d7
  move.l %d7,-(%sp)
  .word _F_LINE+0x53
  lea (10,%sp),%sp
  moveq.l #1,%d0
  tst.w __calculator-__relation(%a4)
  jbeq .L438
  moveq.l #2,%d0
...

Donc l'appel de ROM call se fait apparemment par F_LINE, ne pas utiliser les appels en A_LINE pour ce que je veux, en réécrivant un handler à la place de celui du tios, si j'ai pas envie de m'en servir? ça me permettrait de gagner un bit de flag ou de données...
Il sert à quoi le A_LINE du tios? pour gérer les erreurs et compagnie non? et si j'utilise pas les ROM calls qui y touchent, je suppose que je peux le dégager allègrement non?

<<< 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°15 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 14 mars 2006 à 19:42

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

A_LINE = ER_throw. C'est utilisé à peu près partout dans AMS. Par exemple, EX_patch l'utilise. Bref, impossible de le redéfinir.

./Post n°16 Marquer comme non lu.

Folco

Ecrit le: Mercredi 15 mars 2006 à 11:23

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ok, merci!

ah au fait, je devrais pouvoir intercepter tous les appels à HeapAlloc* en filtrant ce qui est appelé par 0xF8xx+HeapAlloc*, pour vérifier le succès des allocations. Naturellement, si je veux contrôler tout, il faudrait que tous les appels soient faits en FLine.

Sinon, y a-t-il un autre moyen plus efficace de contrôler ça? même en modifiant la table des ROM calls, les appels kernels relogés passeraient à côté :'(

<<< 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°17 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mercredi 15 mars 2006 à 12:41

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Et les appels à l'intérieur de AMS aussi.
Sans modifier le code de la fonction elle-même en FlashROM, il n'y a pas vraiment de solution.

./Post n°18 Marquer comme non lu.

Folco

Ecrit le: Mercredi 15 mars 2006 à 13:12

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Ok. Je ne peux que faire tous mes appels en F_Line et modifier le handler alors. Parceque hors de question de patcher AMS évidemment

<<< 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°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-