short long ?

Version imprimable

03/12/2013, 21h32
Bktero

short long ?

Bonsoir,

Je suis en train de tenter de faire compiler (sans linker) avec gcc / llvm du code pour PIC. Mon intérêt est d'éviter les messages d'erreur à la mord moi le noeud du compilateur C18 pour PIC et j'espère avoir des messages d'erreur plus compréhensibles. En gros, j'essaye de faire ce qui m'a été conseillé dans les commentaires de cet article : http://gradot.wordpress.com/2013/11/...t-pas-un-type/

J'ai passé les premières difficultés en récupérant les headers, trouvant le define pour que les inclusions marchent puis j'ai contourné les mot-clés near et far. Maintenant j'arrive sur la ligne suivante qui me laisse perplexe :

Code:

extern volatile near unsigned short long PC;

gcc est comme vous et moi :

Citation:

./p18f25k22.h:2759: error: both ‘long’ and ‘short’ in declaration specifiers

:aie:

Quelqu'un a déjà vu un truc comme ça ? Quelqu'un a t-il surtout une idée de comment remplacer ce type par un type plus "commun" ?

Bktero :)
03/12/2013, 21h50
Obsidian

Hello,

C'est un « entier au long court » ? :mouarf:

Plus sérieusement, je n'ai jamais vu cela non plus. Pas de trace dans n1256 non plus (après une simple recherche sur « long short » et « short long » sans creuser plus loin. Par contre, après une recherche sur Google, on tombe systématiquement sur les pages consacrées à Microchip, et notamment celle-ci : http://www.microchip.com/forums/m738383.aspx

Apparemment, c'est une manière pour eux de déclarer des entiers de 24 bits. « uint24_t » était probablement trop compliqué…
03/12/2013, 21h57
Bktero

Je viens de chercher dans la documentation du compilateur C18 :

Citation:

2.1 DATA TYPES AND LIMITS 2.1.1 Integer Types
The MPLAB C18 compiler supports the standard ANSI-defined integer types. The ranges of the standard integer types are documented in Table 2-1. In addition, MPLAB C18 supports a 24-bit integer type short long int (or long short int), in both a signed and unsigned variety.

C'est donc effectivement (u)int24_t.

Je ne vois pas de moyen de faire un typedef ou une macro en C pour remplacer ça. Le premier me donne me même message d'erreur que ci-dessus ; le second marche pas puisque short long, ça fait deux mots.

sed ?
03/12/2013, 22h07
Obsidian

Citation:

Envoyé par Bktero

sed ?

Oui, mais à condition que les séquences « long short » ou « short long » n'apparaissent jamais ailleurs que dans les déclarations de types, notamment au sein des chaînes de caractères (peu probable quand même) ni au sein des commentaires (sauf à vouloir les remplacer également pour maintenir la cohérence de la doc).

Jouable, mais bien pénible quand même. Je te conseille de faire un egrep récursif avec numéros de lignes sur ces deux expressions (en mettant [[:space:]]* entre les deux mots) et de renvoyer la sortie dans un fichier que liras à tête reposée. En quelques coups d'œil, tu devrais pouvoir vérifier facilement s'il s'agit toujours de déclarations ou s'il y a des cas particuliers.

Et dans le premier cas, tu peux faire un « sed -i » pour modifier directement les fichiers après en avoir fait une sauvegarde globale.
04/12/2013, 08h43
mith06

Citation:

Je suis en train de tenter de faire compiler (sans linker) avec gcc / llvm du code pour PIC

Bon Courage!!
Le C Microship, c'est du C a la sauce Microship, c'est à dire non standard :aie:
04/12/2013, 09h56
gangsoleil

Le probleme que je vois, c'est que comme tu as du C non standard, ce n'est que la premiere difficulte que tu rencontres, mais tu ne sais pas combien d'autres t'attendent.

Que cherches-tu a faire ? Compiler les sources avec GCC pour linker ensuite avec le linker C microship ? Si c'est bien le cas, le fait de remplacer "short long" par autre chose peut entrainer des bugs. Si c'est autre chose, alors il faudrait savoir ce que tu veux faire pour te conseiller.
04/12/2013, 11h17
Bktero
Merci pour vos réponses :)

Je n'ai pas été très clair dans l'explication du but final : l'idée est de compiler avec gcc pour avoir des messages d'erreurs (peut-être ?) plus clair. C18 a en effet la manie de dire "syntax error" dés qu'il rencontre une erreur. J'ai eu le cas comme je l'explique sur mon blog lorsqu'un type est inconnu ou quand je mixe code et déclaration (le compilateur suit C89). C'est pas forcément facile à comprendre, on perd du temps. J'espère que gcc me dira "unknow type" et "mixed code and declarations".

Le flow serait donc le suivant :
- si C18 sort son fameux "syntax error", alors compiler avec gcc
- trouver l'erreur plus facilement
- enfin, compiler et linker avec C18
Par conséquent, je suis prêt à faire des trucs "sauvages" comme remplacer short long par int24_t à coup de script bash. De même si jamais je n'arrive pas à remplacer / émuler tous les pragma de C18, je ne passerai pas les fichiers concernés dans gcc.

Enfin, je précise que c'est plus pour tester la faisabilité que forcément avoir quelque chose de béton.
04/12/2013, 11h19
gangsoleil

Code:

sed -i 's/short long/uint24_t/g' *.c

ou

Code:

perl -pi -e 's/short long/uint24_t/g' *.c

Tu peux bien sur faire la meme chose avec long short, ou bien l'ameliorer en gerant plusieurs espaces et/ou tabulations entre les deux.
04/12/2013, 12h49
Obsidian

Citation:

Envoyé par Bktero

Enfin, je précise que c'est plus pour tester la faisabilité que forcément avoir quelque chose de béton.

Ça vaut le coup parce que tu peux facilement faire un « typedef unsigned short long int uint24_t » dans un header unique côté C18 sur les fichiers modifiés. L'inverse n'est pas vraie.

Citation:

Envoyé par gangsoleil

sed -i 's/short long/uint24_t/g' *.c ou perl -pi -e 's/short long/uint24_t/g' *.c. Tu peux bien sur faire la meme chose avec long short, ou bien l'ameliorer en gerant plusieurs espaces et/ou tabulations entre les deux.

C'est ce qu'on disait plus haut, en effet, mais il faut tenir compte du fait que tu peux trouver ces séquences ailleurs que dans une déclaration de variable.
04/12/2013, 13h09
gangsoleil

Citation:

Envoyé par Obsidian

C'est ce qu'on disait plus haut, en effet, mais il faut tenir compte du fait que tu peux trouver ces séquences ailleurs que dans une déclaration de variable.

Oui, mais si c'est "pour tester avec un vrai compilateur qui genere des erreurs moins pourries que l'autre", c'est pas grave si tu remplaces toutes les chaines short long, y compris les chaines de caractere ou les commentaires.
10/12/2013, 21h42
Bktero

J'avance petitement sur le sujet. Quelques minutes par ci par là ^^

J'arrive pratiquement à compiler mon fichier main.c. Le retour de main est void, gcc n'aime pas. gcc n'aime pas une constante binaire comme 0b00001111. Mais le reste avance. Je vais maintenant m'attaquer d'autres fichiers avec des trucs plus marrants.

PS : je viens de tenter et gcc me sort :

Citation:

../sources/interrupts.c:203: confused by earlier errors, bailing out

Mouarf ! :mouarf:
11/12/2013, 10h44
gangsoleil

Bonjour,

En depit des recents efforts, les messages d'erreur de GCC restent souvent assez abscons. Peut-etre pourrais-tu faire le test avec Clang/LLVM, tu obtiendras des messages plus comprehensible.

Apres, pour ce qui est du type de retour de main, ca depend de tes options de compilation : tu compiles du code non standard, il te faut donc eviter absolument les options du genre "-ansi" ou "-pedantic", sauf a les utiliser en connaissance de cause.

En fait, je sous Mac OS X donc gcc rappelle llvm.

Mais je ne lui en veux pas vraiment en fait. Il y a à cet endroit pas mal de pragma avec des trucs exotiques pour définir les handlers d'interruptions.

J'ai eu encore mieux à l'instant après avoir activé les blocs assembleur (avec -fasm-block):
Code:

1 2 3 4 ../sources/interrupts.c:203: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://developer.apple.com/bugreporter> for instructions.
:aie: