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

Folco

Ecrit le: Jeudi 23 mars 2006 à 16:49

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

1-> je me suis rendu compte de ma faute en compulsant le doc, et je l'ai corrigée.

2-> ok pour la syntaxe à adopter, merci bien! et ok pour les explications des tables de relogements compressés, je pensais que ça venait du fait qu'il n'y avait qu'un seul relogement (ngetchx) dans mon "code".

3-> ah ok. Tant mieux. C'était pas à Flanker que c'était arrivé ce problème?

4-> Je sais!!!

merci pour ta réponse et ton support de toute façon, c'est sympa à toi de le faire, ce n'est en aucun cas une obligation.

.equ _nosavescreen,_flag_2

j'ai mis:

.set _nosavescreen,_flag_2

normalement c'est pareil, il n'y a pas d'erreur à la compilation, mais je n'ai pas pu tester encore (toujours pas d'ému...).

Merci encore pour tout!

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

Folco

Ecrit le: Jeudi 23 mars 2006 à 16:55

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

c'est bon, ça marche

c'était la définition du symbole _library qui faisait tout foirer

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

Kevin Kofler

Ecrit le: Jeudi 23 mars 2006 à 19:29

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Ben oui, une lib n'a pas de _main (en revanche, un programme, qui a donc un _main, peut aussi exporter des libcalls en même temps, ce n'est pas très propre, mais PpHd utilise ça dans CF par exemple).

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

Sasume

Ecrit le: Jeudi 23 mars 2006 à 22:54

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Pourquoi ce n'est pas très propre ?
Je ne vois pas le pb... Dans certains cas ça peut se révéler très intéressant. Et ça n'alourdit quasiment pas l'écriture du kernel.

./Post n°61 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 24 mars 2006 à 00:26

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Un programme est fait pour être lancé, pas pour être utilisé comme lib.

Et le problème est surtout que dans CF, il y a des dépendances non seulement programme->lib comme normalement, mais aussi lib->programme, ce qui fait que la librairie n'est plus réutilisable vu qu'elle référence directement le programme client par son nom! Bref, la "lib" n'en est plus une, c'est devenu un morceau de programme qui est dans un fichier à part alors que ça ne sert à rien (enfin en théorie, en pratique CF fait ça à cause de la limite de 64 KO).
-Edité le Vendredi 24 mars 2006 à 00:26 par Kevin Kofler-

./Post n°62 Marquer comme non lu.

Sasume

Ecrit le: Vendredi 24 mars 2006 à 08:42

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

C'est parce que ta définition de programme est obsolète... Regarde les applications KDE par exemple, elles exportent des services.

./Post n°63 Marquer comme non lu.

Folco

Ecrit le: Lundi 27 mars 2006 à 16:27

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

-rien-

-Edité le Lundi 27 mars 2006 à 16:30 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°64 Marquer comme non lu.

Folco

Ecrit le: Mardi 28 mars 2006 à 11:15

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Pour info, le trap #12 est souvent utilisé par ams? il pop le sr dans d0, ams se sert de ça ou pas? pour savoir si je peux juste ajuster la pile sans renvoyer le sr, parceque perso ça me gêne...

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

Folco

Ecrit le: Mardi 28 mars 2006 à 15:11

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

tiens, comportement étrange de TIGCC ou faute de ma part? Voici le code incriminé:

|===================================================
|  Copy the First Handle
|===================================================
FH_Ok:   moveq  #(FH_End-FH_Start)-1,d0
  lea.l  FH_Start(pc),a1
FH_Copy:
  move.b  (a1)+,(a0)+
  dbra.w  d0,FH_Copy

Ca, ça marche très bien.

Quand je veux mettre:

moveq #(FH_End-FH_Start)/2-1,d0

voire

moveq #(FH_End-FH_Start+1)/2-1,d0

j'ai les erreurs:
'undefined symbol FH_End in operation' et 'undefined symbol FH_Start in operation'...
Pour info, les deux labels appartiennent à un autre fichier source assembleur d'où ils sont exportés.

-Edité le Mardi 28 mars 2006 à 15:12 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°66 Marquer comme non lu.

Sasume

Ecrit le: Mardi 28 mars 2006 à 16:39

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Je pense que Kevin te donnera une réponse claire sur cette question.
Mais faut savoir que c'est pas forcément évident au niveau de a68k de gérer ce genre de cas.

./Post n°67 Marquer comme non lu.

Folco

Ecrit le: Mardi 28 mars 2006 à 17:06

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

arf... si ça tombe, c'est la même réponse qui avait été faite à Flanker et que Kevin m'avait fowardé... j'ai encore le mail...
ceci dit, l'intitulé de l'erreur m'étonne, c'est comme s'il ne voyait pas le label dans l'autre fichier...
et au passage, il s'agit de GNU as.

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

Kevin Kofler

Ecrit le: Mercredi 29 mars 2006 à 04:59

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Oui, c'est le même problème que sous A68k, c'est-à-dire ça:

move.w #((end_compressions_table-start_compressions_table)/6)-1,d1
ne passe pas si tu compiles en mode all-relocs (ce qui est impliqué par tigcc
--cut-ranges), parce que ce n'est pas représentable en le format objet. La
différence d'adresses:
move.w #((end_compressions_table-start_compressions_table))-1,d1
est représentable par une paire de relogements positif/négatif (extension
TIGCC au format objet, le format AmigaOS pur ne permettrait même pas ça).

En mode non-all-relocs, la différence d'adresses est calculée lors de
l'assemblage (ce qui permet de diviser par 6), mais on ne peut pas faire ça
en mode all-relocs parce que la différence est susceptible de changer après
optimisation linker (bon OK, pas dans ce cas parce qu'il n'y a, je suppose,
que des données entre tes 2 labels, mais en général oui).

Le fait que cette différence soit susceptible de changer sous l'effet du range
cutting est aussi ce qui rend cette représentation nécessaire. Si on assemble
en mode non-all-relocs (donc avec les différences codées en dur), le linker
ne peut pas effectuer son range-cutting (et il ne le fait effectivement pas,
il y a une protection pour ne pas faire n'importe quoi: le mode all-relocs
définit le symbole __ld_all_relocs; si ce symbole n'est pas défini, le linker
n'effectue pas de range cutting sur ce fichier).

J'espère que cette explication éclaircisse la situation pour toi.

sauf qu'ici c'est GNU as qui l'a. Cette expression n'est pas représentable dans nos formats objets (tous les deux), et cela indépendamment de l'assembleur utilisé.

Pour l'intitulé, ben ce sont deux symboles non définis (pas de .equ/.set) qui sont utilisés dans une opération (la division) et l'expression ne peut pas être simplifiée (mode all-relocs), donc voilà. Je trouve que c'est quand-même assez clair comme intitulé, si tu compares avec les messages d'erreur vagues de A68k (genre "Relocatability error").
-Edité le Mercredi 29 mars 2006 à 05:03 par Kevin Kofler-

./Post n°69 Marquer comme non lu.

Folco

Ecrit le: Mercredi 29 mars 2006 à 08:51

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Ok, merci Kevin #top#

heu, c'est assez clair, oui... si tu connais le détail du fonctionnement du linker

sinon, c'est dommage de voir ça, je vais devoir coder ces valeurs en dur en fin de dev...

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

Folco

Ecrit le: Jeudi 30 mars 2006 à 11:17

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

encore un truc que j'aurais voulu savoir. J'ai peur de certaines optimisations du linker, voire de l'assembleur.
en faisant du smc, j'écris des trucs du genre:
.word 0x4ef9
.long 0
est-ce que le linker ne risque pas un jour ou l'autre de me dégager ça? (jmp 0) comment faire au cas où pour l'éviter?

pareil pour:
move.w #0,-(sp)
il faudrait pas que ça soit optimisé en clr.w -(sp), parceque je pourrais plus écrire mon handle à la place du 0... je sais que tous les clr.l étaient remplacés par des moveq #0, c'est encore le cas?

vala vala, je suis pas trop sûr de ce qui peut se passer à la compilation en jouant à ça en fait

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

Sasume

Ecrit le: Jeudi 30 mars 2006 à 12:26

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

1. Je crois que de toute façon, c'est paramétrable (si tu utilises ld-tigcc). Mais faut fouiller dans la doc pour trouver des infos là-dessus.
2. Il faut savoir que l'assembleur lui-même se permet parfois de faire des optimisations (celles dans ce genre sont fréquentes). Je crois qu'il y a un flag pour l'en empêcher.

./Post n°72 Marquer comme non lu.

Folco

Ecrit le: Jeudi 30 mars 2006 à 13:00

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

okay, merci bien, je vais chercher ça. c'est clair que si les optimisations move->moveq elles sont très bien quand tu débutes, tu t'en passes rapidement après

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

Kevin Kofler

Ecrit le: Jeudi 30 mars 2006 à 13:05

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Martial Demolins :
encore un truc que j'aurais voulu savoir. J'ai peur de certaines optimisations du linker, voire de l'assembleur.
en faisant du smc, j'écris des trucs du genre:
.word 0x4ef9
.long 0
est-ce que le linker ne risque pas un jour ou l'autre de me dégager ça? (jmp 0)

Non:
1. S'il n'y a pas de relogement, il n'y a rien à optimiser pour le linker. Tu peux même écrire jmp 0:l.
2. Si tu écris ton code avec des .word et .long, c'est considéré comme des données, donc tout relogement est marqué non-optimisable, le linker ne va pas y toucher.
3. Si tu écris jmp label:l (taille spécifiée explicitement), c'est également marqué non-optimisable pour le linker.

pareil pour:
move.w #0,-(sp)
il faudrait pas que ça soit optimisé en clr.w -(sp), parceque je pourrais plus écrire mon handle à la place du 0...

Ce n'est pas optimisé.

je sais que tous les clr.l étaient remplacés par des moveq #0, c'est encore le cas?

Ce hack est toujours là (à préciser que ça ne concerne que les clr.l %dn, pas les clr.l en mémoire), faudra que je patche ça dans GCC un de ces jours (le problème, c'est qu'il y a une dizaine d'endroits à modifier au moins), comme ça je pourai virer ce hack sauvage dans GNU as.

Sasume :
2. Il faut savoir que l'assembleur lui-même se permet parfois de faire des optimisations (celles dans ce genre sont fréquentes). Je crois qu'il y a un flag pour l'en empêcher.

GNU as fait beaucoup moins d'optimisations sauvages que A68k parce qu'elles ne sont pas implémentées, tout simplement, et vu le peu d'intérêt que ça a par rapport aux ennuis que ça crée (surtout vu que les cas où ça fonctionne sont restreints par pas mal de limitations dans l'implémentation), elles ne le seront probablement jamais. Si quelqu'un implémente ça, je ferai en sorte que c'est désactivable, bien sûr (comme le -n de A68k), voire désactivé par défaut (probablement le plus sûr).

./Post n°74 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 30 mars 2006 à 13:10

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Martial Demolins :
okay, merci bien, je vais chercher ça. c'est clair que si les optimisations move->moveq elles sont très bien quand tu débutes, tu t'en passes rapidement après

Euh, attention, les * -> *q, GNU as les fait aussi et ce n'est pas désactivable (c'est codé en dur dans la table des opcodes). En général, tu peux éviter ça en spécifiant le nom en *i, mais il n'y a pas de movei.
-Edité le Jeudi 30 mars 2006 à 13:11 par Kevin Kofler-

./Post n°75 Marquer comme non lu.

Folco

Ecrit le: Jeudi 30 mars 2006 à 13:31

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ok, merci Kevin pour toutes ces précisions rassurantes! #top#

ptit edit: quelle est la différence entre jmp 0.l et jmp 0:l?

-Edité le Jeudi 30 mars 2006 à 15: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°76 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 31 mars 2006 à 10:37