J'ai pas fais de système depuis longtemps, donc je me trompe peux-être, mais je pense que l'implementation initiale en C avec volatile est fausse:
a) volatile n'est même pas forcement nécessaire ici. Le compilateur n'a pas de raison d'optimiser la lecture écriture d'une variable globale dans ce contexte. Si tu avais une boucle genre while(tick < 100) { }, alors, oui, volatile pourrait faire partie de la solution car le compilateur à le droit de considérer que tick ne change pas depuis l’extérieur. Mais dans ta fonction Systick_IRQHandler, le compilateur est forcé de lire et écrire la valeur globale. J'ai regardé dans goldbot, il n'y a aucune difference avec ou sans volatile: https://godbolt.org/z/3bW9PEPWP
b) Sauf erreur de ma part, l'incrementation d'un entier n'est pas forcement atomique, semantiquement, cela reste un fetch; add; store. Sur x86_64, le add n'est pas atomique par défaut, il faut lui ajouter "lock" pour que cela le soit.
Bref, si ici Rust est plus verbeux, c'est aussi parce que la solution "naive" en C est très certainement fausse. En C il faudra utiliser des atomic aussi (si disponible dans ta version de C) ou differentes primitives qui font principalement des barrier memoire.
# u32++ n'est pas atomique
Posté par Guillaum (site web personnel) . En réponse au journal Découverte de rust pour l'embarqué 2. Évalué à 7 (+5/-0).
J'ai pas fais de système depuis longtemps, donc je me trompe peux-être, mais je pense que l'implementation initiale en C avec
volatileest fausse:a)
volatilen'est même pas forcement nécessaire ici. Le compilateur n'a pas de raison d'optimiser la lecture écriture d'une variable globale dans ce contexte. Si tu avais une boucle genrewhile(tick < 100) { }, alors, oui,volatilepourrait faire partie de la solution car le compilateur à le droit de considérer quetickne change pas depuis l’extérieur. Mais dans ta fonctionSystick_IRQHandler, le compilateur est forcé de lire et écrire la valeur globale. J'ai regardé dans goldbot, il n'y a aucune difference avec ou sansvolatile: https://godbolt.org/z/3bW9PEPWPb) Sauf erreur de ma part, l'incrementation d'un entier n'est pas forcement atomique, semantiquement, cela reste un
fetch; add; store. Sur x86_64, leaddn'est pas atomique par défaut, il faut lui ajouter "lock" pour que cela le soit.Bref, si ici Rust est plus verbeux, c'est aussi parce que la solution "naive" en C est très certainement fausse. En C il faudra utiliser des atomic aussi (si disponible dans ta version de C) ou differentes primitives qui font principalement des barrier memoire.