FUUUUUUUUUUU UUUUUUUUUU UUUUUUUUUUU UUUUUUUUUUUUU - Page 33

J'ai probablement de la chance alors. On me demande combien de temps ça prend et si c'est raisonnable ils acceptent et je m'y mets. Pour tout le monde, tant qu'il reste des tickets ouverts ben on bosse dessus. Bon après c'est parce que c'est notre produit, pas une solution développée pour des clients. Après aussi je suis payé comme un rookie malgré mon expérience… du coup ce que je fais c'est qu'à l'intérieur des délais assez grassement définis je fais un peu plus que ce qui est nécessaire mais qui me plaît. Typiquement je m'occupe de l'UX -- pas officiellement, mais comme on bosse avec un artiste externe contracté, qui n'est pas réactif forcément, j'ai commencé à faire des "propositions" "en attendant que l'artiste nous dise comment il verrait la chose". Et comme le PO m'aime bien maintenant il ne prend même plus cette peine, il dit "fais comme tu penses, je sais que t'as de bonnes idées pour ça, et au pire on regardera avec le gars plus tard".
A mesure que je serai meilleur à estimer, je compte rajouter aussi des tâches de développement personnel (mais pour l'instant je ne suis pas encore assez casé dans une routine qui me permet de me dire "j'enlève une heure de boulot au milieu et me mets à fond dans un livre ou des tutos sur Unity" par exemple).

Ah et je dois travailler avec des Viet du Nord !

Des Ch'tits Viet ?

c'est moi aussi qui évalue le temps requis pour les propals puis on ajuste.

ca doit pas être si rare en fait...

Tron (./901) :

Tron (./898) :
Petit coup de gueule : GCC ARM (5.2.1) est une sombre merde qui casse le code dès que l'on met les optimisations en route.

Et je ne parle même pas d'Eclipse en mode debug :

C'est bon, c'est un bug de gdb : http://stackoverflow.com/questions/7571241/eclipse-gdb-expression-what-is-shown-in-default

working with C++

fail

Mais mon problème, je l'ai aussi en C, hein.

Et sur le site de DS-5, ils conseillent au moins d'avoir le flag -O1 parce que sinon, sans optimisation, tout ce qui est déclaré en inline n'est même pas inliné.

Nan mais Watt !

(./958 Voilà :

On a aussi les stylos, les bonbons, l'armagnac, les tasses et peut-être bientôt les pantoufles )

Les livebox c'est vraiment de la merde. Chez ma mère j'ai voulu installer un petit appareil pour étendre le wifi, il y a l'option pour garder le même ssid (plus pratique quand même), ça faisait planter le wifi de la livebox, et là chez mon père de temps en temps le wifi plante, ou le module télé aussi (alors que ça a déjà été changé à noël...), enfin bon, j'ai jamais vu une livebox fonctionner correctement.

Tron: tu connaissais -Og ?

ya -Oring aussi

Mais bordel, GCC ARM, connaaaaaaaaaard !

Notez la subtile différence (en -O1) :

	register u32*	 l_panSp	__asm__("r0");
	l_panSp = (u32*) __get_PSP();
	__asm__ __volatile__
	(	"	stmdb	r0!, {r4-r11}	\n");

Into :

	MRS	r2, psp		@ r2 ? Mais t'as vu la vierge, connard ?
	stmdb	r0!, {r4-r11}

Avec :

	register u32*	 l_panSp __asm__("r0");
	l_panSp = (u32*) __get_PSP();
	__asm__ __volatile__
	(	"	stmdb	r0!, {r4-r11}	\n"
	: [r0_out] __CMSIS_GCC_OUT_RW_REG(l_panSp));

Into

	MRS	r0, psp		@ Ah, enfin t'as compris qu'il faut utiliser r0...
	stmdb	r0!, {r4-r11}

Sauf que... __CMSIS_GCC_OUT_RW_REG(r) n'existe pas dans 'cmsis_gcc.h', il faut le rajouter vers la ligne 360 :

#if defined (__thumb__) && !defined (__thumb2__)
#define __CMSIS_GCC_OUT_REG(r) "=l" (r)
#define __CMSIS_GCC_OUT_RW_REG(r) "+l" (r)
#define __CMSIS_GCC_USE_REG(r) "l" (r)
#else
#define __CMSIS_GCC_OUT_REG(r) "=r" (r)
#define __CMSIS_GCC_OUT_RW_REG(r) "+r" (r)
#define __CMSIS_GCC_USE_REG(r) "r" (r)
#endif

Parce que même si on utilise __CMSIS_GCC_OUT_REG(r), on se retrouve dans le premier cas de figure.

Thanks guys, good work.

Y'a moyen de facturer le temps perdu aux fournisseurs d'outils de merde ?

Y'a certainement moyen de couler financièrement la FSF.

Oh oui, pardon, c'est des outils gratuits produit par des bénévoles, il faut leur pardonner.

Obligatory meme :

Tu vas couler la FSF!

(ha merde on a eu la meme idee!)

./967 Ooohhhhhhhhhh, c'est beau !!!! *_*

J'aime pas ces clefs USB

Oui, j'en avais une comma ça (4 Go) livré par ma boite.

Je crois que tous les fichiers qui sont passés dessus ont été corrompus.

Non mais elles fonctionnent correctement les nôtres

./971 → Ton assembleur inline n'est pas valide. Une asmspec (spécification du registre de type __asm__("r0")) sur une variable register locale n'est qu'une suggestion, GCC ne garantit pas qu'elle sera toujours respectée. Il faut utiliser la syntaxe pour les entrées, sorties et clobbers dans ton asm volatile.

La version où tu as le registre déclaré en entrée-sortie fonctionne mieux parce qu'ils ont dû rajouter une bidouille pour essayer de respecter les asmspecs au moins dans ce cas. (Je me rappelle avoir appliqué un patch comme ça dans TIGCC, il a probablement fini par atterrir dans ton GCC ARM, et j'espère aussi dans le GCC officiel.) Mais il est généralement une meilleure idée d'utiliser le placeholder correspondant au paramètre plutôt que de coder r0 en dur dans ton code ASM.

Il y a probablement une tres bonne raison d'utiliser r0 en "dur"

@Godzil : exact !

@Kevin : dans la vraie vie je n'avait pas l'intention de laisser GCC décider de quel registre il voulait bien disposer.

Si j'utilise un register local avec contrainte sur __asm__("r0") ce n'est pas pour rien.

Mais manifestement GCC ARM s'en contrebalance allègrement.

Qui te dit que l'asm volatile va contraindre l'utilisation de 'l_panSp' sur "r0" pour assurer le lien avec "stmdb" ?

Qui te dit que si j'utilise l'input list en direct sur "stmdb" je pourrait le contraindre sur "r0" ?

Je suis en train de faire une sauvegarde de contexte étendue depuis PendSV, r0-r3/r12 sont déjà sur la stack.

L'idée est de ne surtout pas corrompre les registres r4-r11 avant qu'ils ne soient sauvés eux aussi.

A ce moment précis, r1-r3 sont déjà affectés à autre chose, mais GCC ARM se permet quand même d'utiliser "r2".

Alors que je lui ai SPECIFIQUEMENT demandé d'utiliser "r0" qui n'a que cette tâche à effectuer.

C'est au final assez symptomatique des logiciels libres et de leurs codeurs :

Explique moi ce que tu veux faire, je t'expliquerais que tu a tords, que l'outil n'a pas la même logique, que tu dois t'y adapter.

Merci, mais j'avais compris figure toi.

On pourrait te reprocher la même chose : comprend comment marche l'outil, et parle-lui comme il faut. Après, s'il ne te va toujours pas, te gêne surtout pas pour en changer.

Je ne suis pas développeur de GCC, je ne le défends même pas (si tu veux mon avis personnel: je ne comprends pas l'intérêt des asmspecs sur les variables locales vu que GCC ne les respecte en général pas, je supprimerais entièrement cette fonctionnalité si elle n'est pas implémentable de manière fiable, j'accepterais probablement le code, mais avec un warning que l'asmspec est déprécié et sera ignoré), je t'explique juste comment il fonctionne.

Et franchement, pour une fonction de ce type, il vaut mieux l'écrire entièrement en assembleur.

Mon père habite Ermont eaubonne, c'est très bien, 2 lignes directes pour gare du nord et St Lazare. Sauf quand ils décident de faire des travaux en même temps sur les 2 lignes, et je me tape 70 mn pour rentrer avec la fin en bus, au lieu de 20/25 mn en temps normal la nuit...

Kevin Kofler (./981) :
si tu veux mon avis personnel: je ne comprends pas l'intérêt des asmspecs sur les variables locales vu que GCC ne les respecte en général pas, je supprimerais entièrement cette fonctionnalité si elle n'est pas implémentable de manière fiable, j'accepterais probablement le code, mais avec un warning que l'asmspec est déprécié et sera ignoré

Que tu ne comprenne pas c'est ton problème.

Que GCC prenne des libertés avec les specs constructeurs dès que ses codeurs rencontrent une difficulté (genre la syntaxe de l'assembleur x86) en est une autre.

Le savais tu :

Deux fonctions avec le même nom en C fait un crash au linkage (logique tu me dira) sauf si l'une d'elle est __weak.

Deux fonctions avec le même nom en C et ASM ne fait PAS un crash au linkage, le résultat est indéterminé.

Merci qui ?

Et non, je ne suis pas décideur des outils dans ma boite, ils travaillent à l'économie, donc au moins cher.

Même si par la suite on passe 10 ans à galérer pour contourner les limitations.

Ca sera toujours un argument supplémentaire en leur faveur pour pas nous augmenter.

Ben ouais ton boulot c'est ça quoi, contourner les limitations. Dans ce genre de structures en tous cas.

La spec [de GCC] est la spec. Il n'y a rien de standard (que je sache) en C pour l'ASM inline, et GCC te fournit telle fonctionnalité additionnelle. GCC te dit aussi qu'il ne respecte pas les registres et que c'est qu'une indication (qui comme le dit Kevin en effet ne sert pas à grand chose pour le coup). Après tu choisis de l'utiliser ou pas, et tu choisis l'outil, payant ou pas, qui a le set de fonctionnalités dont tu as besoin. Ou alors tu développes ou fais développer les fonctionnalités manquantes si l'outil est open source (pour un outil payant tu raques un contrat ultra premium pour qu'on te l'implémente à chaque fois -- et tu attends, beaucoup).

je suis pas sur que keil fasse beaucoup mieux niveaux bugs et bizarreries...

et arm inc est un gros contributeur d'arm gcc...

sinon je suis d'accord, une fonction aussi bas niveau on la fait en asm comme ca on l'a au poil de cul près, et basta. ca évite des cheveux blancs.

Pas forcément super d'accord, y'a quand même un standard définit par le constructeur :

https://developer.arm.com/products/software-development-tools/ds-5-development-studio/resources/tutorials/using-inline-assembly-to-improve-code-efficiency

Certes, c'est DS-5, dont le tarif est nécessairement en dehors du budget alloué. Mais quand même.

Il y a bien quelques recommandations concernant le nommage, mais quid du respect de l'utilisation des registres visés :

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205j/Cihccdja.html

Et non, je préfère dorénavant limiter d'usage de l'assembleur pur du fait de la perte de contexte en debug.

CECI DIT (parce que le but est de faire avancer le schmilblick je suppose) je n'ai plus en tête la syntaxe mais avec un bloc d'ASM avec entrées sorties, tu peux faire ça. Tu dois juste nommer les registres en question plutôt que les utiliser directement.

Et DS-5 n'est pas un standard du C, c'est un "standard" (un outil constructeur en fait) ARM. C'est comme si tu disais que `super` est standard en C++ et que tout compilo pour Windows devrait l'inclure, parce que Visual Studio l'implémente.

Non, je n'ai pas dit ça. Mais qu'une extension proposée par GCC ARM ne fonctionne pas comme elle est supposée.

Je ne cherche pas l'extension 'super', j'utilise un truc prétendument disponible pour faire le travail demandé.

Et je reste du coté C de la force parce que j'ai besoin d'accéder aux structures de l'OS, ce que l'asm pur ne sait pas faire.

l'asm pur ne sait pas faire quelque chose? on aura tout lu...

asm inline au moins.

Asm pur ne sait accéder aux éléments d'un typedef struct.

L'asm inline le peut.