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
Citer : Posté le 26/08/2015 12:14 | #
Mon pauvre ami, fais un fichier assembleur.
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 :
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 :
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.
Citer : Posté le 26/08/2015 12:50 | #
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...).
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 à :
Si tu rajoutais des fins de ligne ?
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…
_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
Citer : Posté le 29/08/2015 09:22 | #
Si tu fais un mov.w tu dois utiliser un word et non un long :
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 :
Avec gcc, on écrit plutôt :
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 :
Tu bosses avec gcc ou pas avec gcc...
Pareil, pour le .end, il ne sert à rien.
Citer : Posté le 29/08/2015 15:48 | #
J'ai ça maintenant, toujours le missing separator à la ligne 1
_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 :
20: a_2: .long #0xCFFF
21: a_3: .word #0x1000
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 ?
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.
Au temps pour moi, ça venait du Makefile…
gcc est plus flexible que je ne le pensais...
Sur ces lignes j'ai ces erreurs :
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.
Citer : Posté le 29/08/2015 21:04 | #
J'en déduis que mon code est bon.
Merci pour ces précisions.