Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.

Forum Casio - Autres questions


Index du Forum » Autres questions » Problème compilation avec GCC
Dark storm Hors ligne Labélisateur Points: 11538 Défis: 176 Message

Problème compilation avec GCC

Posté le 26/08/2015 12:09

En bossant sur FiXos, j'ai voulu tester le code de Kucalc au niveau du port série.

Toutes les fonctions sont récupérables directement, sauf une qui est en assembleur. Étant donné que j'ai la flemme de modifier son fichier .asm compatible avec le fx9860 SDK pour en faire un .s normé, j'ai utilisé la balise __asm__.

Seul problème, ça ne compile pas, mais c'est même pas dans mon fichier que j'ai l'erreur.

Bref, voici le code qui pose problème :
void Setup_Serial(void)
{
    __asm__
    (
        "mov.l    #h'A4000100, r2"
        "ldc    r2, gbr"
        "mov.w    @(h'C,gbr), r0"
        "mov.l    #h'CFFF, r1"
        "mov.w    #h'1000, r3"
        "and    r1, r0"
        "or    r3, r0"
        "mov.w    r0, @(h'C,gbr)"
        "add    #h'20, r2"
        "ldc    r2, gbr"
        "mov    #h'C, r0"
        "or.b    #h'60, @(r0,gbr)"

        "rts"
        "nop"
    );
}


Et le log de compilation
[chaos@Korpiklaani FiXos]$ make
sh3eb-elf-gcc -c -I. -Iinterface -Iarch/sh/include -include config.h -g -std=c99 -Wall -m3 -mb -Os -fno-builtin  -o arch/sh/modules/usart.o arch/sh/modules/usart.c
arch/sh/modules/usart.c: In function 'SerialReceive':
arch/sh/modules/usart.c:194:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
arch/sh/modules/usart.c: In function 'serial_receive':
arch/sh/modules/usart.c:221:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
/tmp/ccrblXfE.s: Assembler messages:
/tmp/ccrblXfE.s:415: Error: invalid operands for opcode
/tmp/ccrblXfE.s:631: Error: invalid operands for opcode
Makefile:76 : la recette pour la cible « arch/sh/modules/usart.o » a échouée
make: *** [arch/sh/modules/usart.o] Erreur 1



Lephenixnoir En ligne Administrateur Points: 20809 Défis: 143 Message

Citer : Posté le 26/08/2015 12:14 | #


Mon pauvre ami, fais un fichier assembleur.
mov.l    #h'A4000100, r2

Lol. T'as pas le droit de faire ça : y'a déjà quatre octets de données, alors que l'instruction doit en faire deux !
Tu dois faire ça :
mov.l symbole, r2
suite du code...

.align 4

symbole:
    .long #h'A4000100

Et dans le mov.l, symbole sera compilé en un @(disp, pc) (c'est-à-dire en position relative depuis l'instruction qui l'utilise), ce que j'essayais de t'expliquer l'autre jour (quand on désassemble, là où on obtient des @(disp, pc), c'est souvent que des symboles avaient été utilisés).

Ajouté le 26/08/2015 à 12:16 :
Pareil pour tous les autres. Les instructions qui utilisent des données immédiates n'ont pas de taille (.b, .w, .l), seules les instuctions qui lisent la mémoire (avec un @) en ont besoin la plupart du temps (pour mov, c'est toujours vérifié).

Au passage l'erreur qui signale ça est :
/tmp/ccrblXfE.s:415: Error: invalid operands for opcode
Dark storm Hors ligne Labélisateur Points: 11538 Défis: 176 Message

Citer : Posté le 26/08/2015 12:24 | #


Non, je ne ferai pas de fichier assembleur

Au passage c'est un copié-collé du code de Kucalc, c'est pour ça que je comprennais pas pourquoi ça ne marchais pas. Bref là je vais bouffer, je regarderai ça après.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 20809 Défis: 143 Message

Citer : Posté le 26/08/2015 12:50 | #


Dark storm a écrit :
Non, je ne ferai pas de fichier assembleur

M'embête pas, ton code fonctionnera pas comme ça, problème de compilation ou pas.

Si tu veux pas m'écouter, c'est-à-dire faire un fichier assembleur, tu peux chercher où est le problème mais quelque chose me dit que t'es pas tout à fait rendu (j'en vois deux...).

Dark storm a écrit :
Au passage c'est un copié-collé du code de Kucalc, c'est pour ça que je comprennais pas pourquoi ça ne marchais pas.

Ah. Peut-être que tu vas enfin comprendre ce que je vous martelais que l'assembleur de gcc et celui du compilateur de renesas sont incompatibles l'un avec l'autre à cause de différences de syntaxe ?

Ah oui, et puis je vais te donner un conseil : ton assembleur inline ressemble actuellement à :
mov.l    #h'A4000100, r2ldc    r2, gbrmov.w    @(h'C,gbr), r0...

Si tu rajoutais des fins de ligne ?
Dark storm Hors ligne Labélisateur Points: 11538 Défis: 176 Message

Citer : Posté le 28/08/2015 22:57 | #


Je ne sais pas si c'est ce qu'il fallait faire, mais ça ne compile toujours pas. J'ai rajouté une règle pour usart.s dans le submake.mk, mais il rechigne un peu…

.export _Setup_Serial
_Setup_Serial:
    mov.l    a1, r2
    ldc    r2, gbr
    mov.w    @(h'C,gbr), r0
    mov.l    a2, r1
    mov.w    a3, r3
    and    r1, r0
    or    r3, r0
    mov.w    r0, @(h'C,gbr)
    add    #h'20, r2
    ldc    r2, gbr
    mov    #h'C, r0
    or.b    #h'60, @(r0,gbr)
    rts
    nop

.align 4
a1: .long #h'A4000100
a2: .long #h'CFFF
a3: .long #h'1000

.end


arch/sh/modules/usart.s:1: *** missing separator. Arrêt.

Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 20809 Défis: 143 Message

Citer : Posté le 29/08/2015 09:22 | #


mov.w    a3, r3

Si tu fais un mov.w tu dois utiliser un word et non un long :
a3: .word #h'1000

Parce que là à a3 tu as probablement 0x0000'1000, donc un mov.w ne te lira que 0x0000 !

Et sinon, la notation de constantes du compilateur d'hitachi :
add    #h'20, r2

Avec gcc, on écrit plutôt :
add    #0x20, r2

Après, c'est peut-être compatible, mais bon... autant faire du gcc quoi.

Ah oui, je crois que l'erreur en elle-même est comme indiqué dans le log :
.export _Setup_Serial

Tu bosses avec gcc ou pas avec gcc...
.global _Setup_Serial

Pareil, pour le .end, il ne sert à rien.
Dark storm Hors ligne Labélisateur Points: 11538 Défis: 176 Message

Citer : Posté le 29/08/2015 15:48 | #


J'ai ça maintenant, toujours le missing separator à la ligne 1

.global _Setup_Serial
_Setup_Serial:
    mov.l    a1, r2
    ldc    r2, gbr
    mov.w    @(0xC,gbr), r0
    mov.l    a2, r1
    mov.w    a3, r3
    and    r1, r0
    or    r3, r0
    mov.w    r0, @(0xC,gbr)
    add    #0x[b]20[/b], r2 // Ça c'est pas correct non ? Du coup faut que je créé un symbole de type byte ?
    ldc    r2, gbr
    mov    #0xC, r0
    or.b    #0x[b]60[/b], @(r0,gbr) // Idem
    rts
    nop

.align 4
a1: .long #0xA4000100
a2: .long #0xCFFF
a3: .word #0x1000


Ajouté le 29/08/2015 à 15:55 :
Au temps pour moi, ça venait du Makefile…

Ajouté le 29/08/2015 à 15:59 :
Sur ces lignes j'ai ces erreurs :
19:    a_1: .long #0xA4000100
20:    a_2: .long #0xCFFF
21:    a_3: .word #0x1000

arch/sh/modules/usart_asm.s:19: Error: bad expression
arch/sh/modules/usart_asm.s:19: Error: junk at end of line, first unrecognized character is `0'
arch/sh/modules/usart_asm.s:20: Error: bad expression
arch/sh/modules/usart_asm.s:20: Error: junk at end of line, first unrecognized character is `0'
arch/sh/modules/usart_asm.s:21: Error: bad expression
arch/sh/modules/usart_asm.s:21: Error: junk at end of line, first unrecognized character is `0'


Ajouté le 29/08/2015 à 16:03 :
En enlevant les « # », ça compile, par contre est-ce bien judicieux ?
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir En ligne Administrateur Points: 20809 Défis: 143 Message

Citer : Posté le 29/08/2015 18:52 | #


Lorsque tu as des instructions a données immédiates (#imm), tu peux mettre des valeurs jusqu'à 1 octet. Donc tes add et or.b sont bons.

Dark storm a écrit :
Au temps pour moi, ça venait du Makefile…

gcc est plus flexible que je ne le pensais...

Dark storm a écrit :
Sur ces lignes j'ai ces erreurs :

Dark storm a écrit :
En enlevant les « # », ça compile, par contre est-ce bien judicieux ?

Les # ont les met quand on a des instructions à données immédiates (#imm), pour indiquer que c'est une donnée immédiate, justement. Le reste du temps il faut les enlever.
Dark storm Hors ligne Labélisateur Points: 11538 Défis: 176 Message

Citer : Posté le 29/08/2015 21:04 | #


J'en déduis que mon code est bon.
Merci pour ces précisions.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2021 | Il y a 53 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd