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 C » [Résolu] Pb avec une fonction (15 réponse(s))

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

geogeo

Ecrit le: Lundi 31 juillet 2006 à 02:14

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4256

Membre n°3

Inscrit le 29 janvier 2004

Voilà j'ai une fonction qui doit écrire un simple octet dans un buffer, là voici:

void GFA_Tokenisor_WriteByte(GFA_TokensBuffer *tks_buff, unsigned char b) {
GFA_Tokenisor_PrepareWriteData(tks_buff, sizeof(b));
*((unsigned char *)(tks_buff->buffer + tks_buff->offset++)) = b;
}

Je la fait appelle ici:

case GFA_SUBTAG_INT_U8:
{
GFA_Tokenisor_WriteByte(tks_buff, (unsigned char)tag->info.number.ivalue);
continue;
}

Or je constate avec un coup de débuggeur que l'octet écrit est toujours égal à 0x00 malgré que tag->info.number.ivalue soit différent de 0.
J'ai donc essayé de remplacer le code par ceci:

case GFA_SUBTAG_INT_U8:
{
*((unsigned char *)(tks_buff->buffer + tks_buff->offset++)) = (unsigned char)tag->info.number.ivalue;
continue;
}

Et là l'octet est correctement écrit. #eek#

Bon j'ai donc décidé de regarder un peu le code en assembleur et j'ai isolé le code:
Pour l'appel de fonction qui merde j'ai relevé ceci:

  ...
  move.w 24(%a3),-(%sp)
  jbra .L59
  ...
.L59:
  move.l %d4,-(%sp)
  jbsr GFA_Tokenisor_WriteByte

Et enfin le code qui fonctionne:

.L53:
  move.w 6(%a4),%d1
  moveq #0,%d0
  move.w %d1,%d0
  move.l (%a4),%a0
  move.b 27(%a3),(%a0,%d0.l)
  addq.w #1,%d1
  move.w %d1,6(%a4)
  jbra .L41

Bref move.w 24(%a3),-(%sp) devrait être plutôt move.w 26(%a3),-(%sp)
Je précise que %a3 ne change pas durant les 2 versions en assembleur, il n'y a que les 2 codes en assembleur que je viens de présenter qui changent, le reste ne bouge pas.

J'ai téléchargé la dernière version 0.96 Beta 7 et c'est la même histoire.
-Edité le Lundi 31 juillet 2006 à 14:16 par geogeo-
-Edité le Mercredi 2 août 2006 à 03:21 par geogeo-
-Edité le Mercredi 2 août 2006 à 03:21 par geogeo-

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°1 Marquer comme non lu.

Kevin Kofler

Ecrit le: Lundi 31 juillet 2006 à 12:55

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

On dirait effectivement un bogue de GCC (grrr, c'est quand je viens de sortir une nouvelle bêta que tu trouves ça...

). Tu peux me mailer le projet complet pour que je regarde ça?

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.

geogeo

Ecrit le: Lundi 31 juillet 2006 à 14:15

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4256

Membre n°3

Inscrit le 29 janvier 2004

Voilà c'est envoyé. T'aurais dû attendre un peu avant de diffuser une nouvelle bêta.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°3 Marquer comme non lu.

Kevin Kofler

Ecrit le: Lundi 31 juillet 2006 à 19:14

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

En tout cas, je pense que c'est un bogue de mes peepholes pour optimiser le passage d'arguments de mode QImode (cad. de taille 1 octet). Je vais regarder ça.

./Post n°4 Marquer comme non lu.

geogeo

Ecrit le: Lundi 31 juillet 2006 à 19:33

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4256

Membre n°3

Inscrit le 29 janvier 2004

Ah ok et ça veut dire quoi peepholes?

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°5 Marquer comme non lu.

Kevin Kofler

Ecrit le: Lundi 31 juillet 2006 à 20:36

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Des optimisations locales spécifiques à la machine de destination.

./Post n°6 Marquer comme non lu.

Kevin Kofler

Ecrit le: Lundi 31 juillet 2006 à 23:11

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Bon, je n'ai pas encore regardé ton projet, mais je pense déjà avoir trouvé l'endroit de GCC où ça cloche. Voilà mon define_expand:

(define_expand "pushqi1"
  [(match_operand:QI 0 "general_operand" "")]
  "!TARGET_COLDFIRE"
"{
  if (const_int_operand (operands[0], QImode))
    emit_insn (gen_pushqi1_imm (operands[0]));
  else if (register_operand (operands[0], QImode)) {
    if (GET_CODE (operands[0]) == SUBREG)
      emit_insn (gen_pushqi1_reg (SUBREG_REG (operands[0])));
    else
      emit_insn (gen_pushqi1_reg (operands[0]));
  } else
    emit_insn (gen_pushqi1_mem (operands[0]));
  DONE;
}")

Le problème serait que ça fait n'importe quoi avec (SUBREG QI (MEM ...)) (ça appelle gen_pushqi1_reg sur le MEM). À vérifier...

./Post n°7 Marquer comme non lu.

Kevin Kofler

Ecrit le: Lundi 31 juillet 2006 à 23:23

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

En présupposant que le bogue soit bien à cet endroit, voilà l'origine de la régression:

2005-02-10  Kevin Kofler  <Kevin@tigcc.ticalc.org>

        * gcc/config/m68k.md (pushqi1_imm, pushqi1_reg, pushqi1_mem): New expanders for byte
                                                                      pushes.
          (pushqi1): Use them. Original code moved to pushqi1_mem.

./Post n°8 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 1er août 2006 à 00:14

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Non, le bogue n'est pas là. Voilà le code sorti par mon expander:

(insn 219 217 220 23 (set (reg:SI 80)
        (mem/s:SI (plus:SI (reg/v/f:SI 34 [ tag ])
                (const_int 24 [0x18])) [0 <variable>.info.number.ivalue+0 S4 A16])) -1 (nil)
    (nil))

(insn 220 219 221 23 (set (mem:HI (pre_dec:SI (reg/f:SI 15 %sp)) [0 S2 A16])
        (subreg:HI (reg:SI 80) 0)) -1 (nil)
    (nil))

Traduit du chinois (

), ça correspond à:

move.l 24(%a3),%reg80
move.w %reg80,-(%a7)

sachant que %reg80 n'existe pas, c'est un pseudo-registre encore à allouer ou éliminer. (D'ailleurs, %a3 n'est pas encore alloué non plus à cet endroit, c'est noté %reg34.) C'est les transformations successives qui changent ça en move.w 24(%a3),-(%a7), ce qui n'est bien sûr pas une transformation correcte.

./Post n°9 Marquer comme non lu.

geogeo

Ecrit le: Mardi 1er août 2006 à 00:23

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4256

Membre n°3

Inscrit le 29 janvier 2004

Oula ce bug a l'air coriace!!!
C'est peut être mon union qu'il n'aime pas dans tbl_tags?
-Edité le Mardi 1er août 2006 à 00:23 par geogeo-

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°10 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 1er août 2006 à 00:27

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Bon, c'est la passe combine qui fait n'importe quoi. Avant combine:

(insn 219 217 220 22 (set (reg:SI 80 [ <variable>.info.number.ivalue ])
        (mem/s:SI (plus:SI (reg/v/f:SI 34 [ tag ])
                (const_int 24 [0x18])) [0 <variable>.info.number.ivalue+0 S4 A16])) 25 {*m68k.md:689} (nil)
    (expr_list:REG_DEAD (reg/v/f:SI 34 [ tag ])
        (nil)))

(insn 220 219 221 22 (set (mem:HI (pre_dec:SI (reg/f:SI 15 %sp)) [0 S2 A16])
        (subreg:HI (reg:SI 80 [ <variable>.info.number.ivalue ]) 0)) 30 {*m68k.md:739} (insn_list:REG_DEP_TRUE 219 (nil))
    (expr_list:REG_DEAD (reg:SI 80 [ <variable>.info.number.ivalue ])
        (nil)))

Après combine:

(insn 220 219 221 22 (set (mem:HI (pre_dec:SI (reg/f:SI 15 %sp)) [0 S2 A16])
        (mem/s:HI (plus:SI (reg/v/f:SI 34 [ tag ])
                (const_int 24 [0x18])) [0 <variable>.info.number.ivalue+0 S2 A16])) 30 {*m68k.md:739} (nil)
    (expr_list:REG_DEAD (reg/v/f:SI 34 [ tag ])
        (nil)))

./Post n°11 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 1er août 2006 à 00:30

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

geogeo :
C'est peut être mon union qu'il n'aime pas dans tbl_tags?

Peut-être, mais je pense qu'il ferait la même déconnade avec juste (unsigned char)une_structure.un_membre_de_type_long. En tout cas, c'est bien sûr un bogue du compilateur et je vais faire mon possible pour le corriger au plus vite. Il doit y avoir du code qui présuppose un target little-endian quelque part.

./Post n°12 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 1er août 2006 à 01:06

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Bon, c'est la faute de mon expander après tout. Dans ce qu'il génère, le problème est le 0 en gras:

(insn 219 217 220 23 (set (reg:SI 80)
         (mem/s:SI (plus:SI (reg/v/f:SI 34 [ tag ])
                 (const_int 24 [0x18])) [0 <variable>.info.number.ivalue+0 S4 A16])) -1 (nil)
     (nil))

(insn 220 219 221 23 (set (mem:HI (pre_dec:SI (reg/f:SI 15 %sp)) [0 S2 A16])
         (subreg:HI (reg:SI 80) 0)) -1 (nil)
     (nil))

C'est le "subreg offset", et il est censé être 2 ici. Je vais corriger ça.

[EDIT: Mauvais tags...]
-Edité le Mardi 1er août 2006 à 01:59 par Kevin Kofler-

./Post n°13 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 1er août 2006 à 02:05

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Corrigé dans le CVS:

2006-08-01  Kevin Kofler  <Kevin@tigcc.ticalc.org>

        * version.c (VERSUFFIX): Bump to "4.1.2-pre8".
        * config/m68k/m68k.md (pushqi1): Don't use the optimized pushqi1_reg on SUBREGs with even
                                         offsets. Pass the full SUBREG expression to pushqi1_reg.
          (pushqi1_reg): Handle SUBREGs here. Compute new SUBREG_BYTE when handling SUBREGs instead
                         of hard-coding it as 0.

Je suis en train d'uploader des binaires (cc1.exe, gcc.exe) corrigés sur la page du projet gcc41 sur TI-News.

./Post n°14 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 1er août 2006 à 02:20

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Corrigé dans GCC 4.1.2-tigcc-pre8.
http://www.ti-news.net/projects/gcc41

./Post n°15 Marquer comme non lu.

geogeo

Ecrit le: Mardi 1er août 2006 à 13:21

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4256

Membre n°3

Inscrit le 29 janvier 2004

ok merci ça marche.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic