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 » Bizare bizare... (21 réponse(s))

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

Folco

Ecrit le: Mercredi 19 janvier 2005 à 12:06

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Hier, j'étais en train de débugguer une lib, et je suis tombé sur un truc étrange:

en regardant avec VTI, j'ai vu que mon code:

mulu.l #6,d4
add.l d4,d5

avait été changé en:

mulu.l #$0,d4
ori.b #$84,d6

vraiment, rien compris!!!
pour info, je compile avec TIGCC 0.95, avec toutes les optimisations désactivées, sauf NOPs.

Les deux fonctions dont le code était modifié étaient les fonctions 000a et 000b. En regardant le header de genlib, j'ai vu que PpHd avait noté pour les fonctions 000a 000b, 000c "I use this, because, else a strange bug appears". Il s'agit de la même chose? En tout cas, je suis bien embêté pour résoudre ce bug. Ca vient de a68k?

Si vous avez déjà eu ce bug, ou des idées pour résoudre ce problème (je vais déjà essayer la méthode de PpHd).

edit-> marchent pas les balises code??? re-edit-> ah si c'est bon!!

-Edité le Mercredi 19 janvier 2005 à 12:09 par Martial Demolins-
-Edité le Mercredi 19 janvier 2005 à 12:10 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°1 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mercredi 19 janvier 2005 à 13:44

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Ce qui est clair est qu'il y a un bogue quelque part. Déjà, l'instruction mulu.l n'existe pas sur 68000. (C'est mulu.w et ça multiplie word*word->long.) C'est peut-être ça, ton problème. Sinon, tu pourrais m'envoyer les fichiers en question s'il te plaît, pour que je puisse regarder où est-ce que le code est corrompu?

(Quant aux fonctions de genlib, c'était avec un linker préhistorique qu'il y a eu le problème, et il ne peut plus changer l'API maintenant pour des raisons de compatibilité, je ne pense pas que ce problème se produit avec TIGCC 0.95.)

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

Folco

Ecrit le: Mercredi 19 janvier 2005 à 15:50

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ok merci, je n'ai plus de connexion, mais je vais essayer de te ramener ça pour demain.

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

Folco

Ecrit le: Jeudi 20 janvier 2005 à 13:28

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Kevin-> voici ce que j'ai posté sur yN:

Bon et bien j'ai résolu ce problème. Comme me l'a fait remarquer Kevin, ce sont les mulu.l (dans la lib) qui ne sont pas passés.
J'ai utilisé ce que m'a conseillé PpHd, à savoir un BP en écriture sur mon code.

D'ailleurs, en les remplaçant par des mulu.w plsu traditionnels, la taille de mon programme à la compilation est passée de 865 à 857 octets.

Quand je lançais le prog à partir de tigcc avec le code erronné, voici le code éxécuté au lancement du programme. (ie: le prog étant fini de transférer, en cours de chargement).

code 1
sge.b 29(a4,d3.w)
ori.b $56,d6
move.w 2(a1),d2
move.b 8(a1,d2.w),(a0)+ <--ligne qui modifiait ma lib
addq.w #1,d3
addq.w #1,d2
cmp.w 4(a1),d2
moveq #$0,d2

Parfois, j'avais une autre variante de code. (mais je ne sais plus exactement à quel moment).

code 2
move.l $10(a6),d0
movea.l a3,a1
movea.l $c(a6),d0
cmpa.l a1,a2
bls.s *+$1a
bra.s *+$4
move.b (a2)+,(a1)+ <--ligne qui modifiait ma lib
dbf d0,*-$2
subi.l #$10000,d0
cmpi.l #$ffffffff,d0
bne.s *-$12
bra.s *+$1c

Voilà voilà, en écrivant des mulu.w à la place des mulu.l, tout rentre dans l'ordre, mais jene sais pas exactement d'où vient le bug. J'ai regardé vite fait le source de PreOs, apparemment ce n'est pas lui qui provoque ça. Ce serait du code de AMS???

Vu que la compilation est mauvaise (compilation d'instructions qui ne devraient pas exister, taille différente mais succès de compilation), je vais faire un report précis à Kevin, il faudrait peut-être qu'il regarde du côté de a68k.

Sinon, en parlant de progs transférés par tigcc vers vti, j'avais reporté a PpHd le fait que quand une lib est absente, on a pas le message "Library not found", mais un "Crash intercepted" à la place. Je ne sais pas si ces histoires sont liées, si quelquechose a été fit de puis, ou si ça n'a aucun rapport.

Pour ceux qui voudraient bosser un peu sur ce cas, je peux leur mailer ma sauvegarde de VTI avec la lib et le prog qui provoquait le plantage.

Kevin-> je te mail ce que j'ai, si tu veux pouvoir reproduire le bug.

Voilà, et si tu veux d'autres précisions, demandes-moi.

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

Kevin Kofler

Ecrit le: Jeudi 20 janvier 2005 à 19:36

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

A68k accepte pas mal d'instructions qui n'existent pas, c'est un problème connu.

./Post n°5 Marquer comme non lu.

Folco

Ecrit le: Vendredi 21 janvier 2005 à 08:00

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ah ok. Et en tant que mainteneur, tu ne peux pas faire quelquechose?

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

Sasume

Ecrit le: Vendredi 21 janvier 2005 à 08:10

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Je crois qu'il a pas mal de boulot sur le reste de TIGCC.

./Post n°7 Marquer comme non lu.

Folco

Ecrit le: Vendredi 21 janvier 2005 à 12:47

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

C'et sûr.

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

Kevin Kofler

Ecrit le: Vendredi 21 janvier 2005 à 18:43

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Martial Demolins :
ah ok. Et en tant que mainteneur, tu ne peux pas faire quelquechose?

Déjà, pas mal de ces instructions sont assemblés en des instructions valides (contrairement à ton mulu.l) et des programmes l'utilisent (j'ai vu pas mal de moveq.w, par exemple). Et ensuite, je n'ai pas envie de faire beaucoup plus que des corrections de bogue sur A68k. À la limite rajouter le support assembleur pour les features du linker (je l'ai déjà fait pour le mode all-relocs et les relogements non-optimisables), mais pas plus.

Mon but à long terme est d'étendre le switch --mri-compat de GNU as pour avoir un mode --a68k-compat qui accepte les sources A68k. Ce bogue sera un des bogues qui se corrigeront pratiquement d'eux-mêmes avec ça.
-Edité le Vendredi 21 janvier 2005 à 18:43 par Kevin Kofler-

./Post n°9 Marquer comme non lu.

Sasume

Ecrit le: Vendredi 21 janvier 2005 à 18:44

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

C'est compliqué à faire ?
Je n'ai jamais vu les sources de GNU AS.

./Post n°10 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 21 janvier 2005 à 18:53

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Sasume :
C'est compliqué à faire ?

Je ne sais pas encore. Faut voir à quelle point --mri-compat émule déjà la syntaxe existante. (L'assembleur MRI utilise une syntaxe très proche de A68k.) Il y a des trucs qu'il faudra rajouter, et qui seraient d'ailleurs intéressants à rajouter globalement (même en syntaxe GNU), notamment les labels locaux à la A68k, valides entre 2 labels globaux.

./Post n°11 Marquer comme non lu.

Folco

Ecrit le: Vendredi 21 janvier 2005 à 20:31

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

>>notamment les labels locaux à la A68k, valides entre 2 labels globaux

Il n'y a pas ça sur GNU AS? C'est pourtant très commode je trouve!

edit-> Kevin, je suppose en fait que tu n'auras pas besoin de ce que je t'ai envoyé si je comprends bien.
-Edité le Vendredi 21 janvier 2005 à 20:31 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°12 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 21 janvier 2005 à 20:57

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Comme on a déjà trouvé le problème, je n'ai plus besoin de ce que tu m'as envoyé, en effet.

./Post n°13 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 21 janvier 2005 à 20:59

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Martial Demolins :
>>notamment les labels locaux à la A68k, valides entre 2 labels globaux

Il n'y a pas ça sur GNU AS? C'est pourtant très commode je trouve!

Ce que tu as actuellement sous GNU as:

L.foo

xdef

123b

123f

./Post n°14 Marquer comme non lu.

Folco

Ecrit le: Vendredi 21 janvier 2005 à 21:26

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Désolé our ta boite mail alors

<<< 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: Vendredi 21 janvier 2005 à 23:33

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

M'en fous, je suis en POP3, moi, donc c'est sur mon DD que ça traîne, pas dans la boîte mail. Et dans mes MOs d'archives mail, quelques KO ne vont pas faire la différence.

./Post n°16 Marquer comme non lu.

Folco

Ecrit le: Samedi 22 janvier 2005 à 00:19

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

hum si, yavait ma sauvegarde de VTI et les MOs de preos pour que tu testes avec les mêmes versions

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

Folco

Ecrit le: Mardi 3 janvier 2006 à 16:40

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

arf, à nouveau encore un pb avec a68k:

;|==========================================================
;|  CheckTag
;|==========================================================
;|jump to the right function if (a2).l is a tag. else return
;|
;|input:
;|  a2.l  longowrd to test
;|  a3.l  JumpTable
;|output:
;|  nothing
;|destroys:
;|  d0
;|==========================================================
CheckTag:
  cmpi.l  #NUMBER_OF_TAGS-1,(a2)
  bcc  \NotFlag
  addq.l  #4,sp      ;destroy the return adress of the calling function
  move.l  (a2)+,d0    ;tag in d0, and a2 points to the first data after the tag
  lsl.b  #2,d0      ;d0 offset of the right function in the jump table
  bra  0(a3,d0.l)    ;jump to the function
\NotFlag:
  rts        ;(a2).l is not a flag, so return to calling function

le bra 0(a3,d0.l) est compilé en bra *+$2
c'est mon adressage qui est interdit mais compilé, ou c'est a68k qui compile mal un truc autorisé?
y a-t-il un workaround à ça?
-Edité le Mardi 3 janvier 2006 à 16:42 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°18 Marquer comme non lu.

Folco

Ecrit le: Mercredi 4 janvier 2006 à 09:58

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

j'ai essayé ce workaround:

CheckTag:
      cmpi.l  #NUMBER_OF_TAGS-1,(a2)
      bcc      \NotFlag
      addq.l  #4,sp      ;destroy the return adress of the calling function
      move.l  (a2)+,d0  ;tag in d0, and a2 points to the first data after the tag
      lsl.b    #2,d0      ;d0 offset of the right function in the jump table
      adda.l  d0,a3      ;bra 0(a3,d0.l) is compiled as bra *+$2 !!!
      bra      (a3)      ;jump to the function
\NotFlag:
      rts                ;(a2).l is not a flag, so return to calling function

toujours pareil, mon bra (a3) est compilé en bra *+$2...
si quelqu'un a déjà résolu un tel problème, merci de m'en faire part...

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

Folco

Ecrit le: Mercredi 4 janvier 2006 à 10:45

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

bon ok, problème résolu, prochaine fois j'apprends à coder en 68k avant de poster #sifflotte#

<<< 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."