ybou30 a dit:
Si on veut optimiser l'interprétation, on test les calculs et on en tire les règles dont on a besoin, sur le logiciel que l'on utilise.
Sinon, on blinde "l'écriture".
Je n'ai pas dit ça, et tu ne l'as pas formulé initialement de la sorte.
Tu ne parlais pas d'optimisation d'interpretation, mais de l'usage des parenthèses pour ordonner (traiter dans un certain ordre) un calcul dans une instruction ou un lot d'instructions GCODE (c'est du moins ce que j'ai compris).
Pour ce qui est optimiser, je ne vois pas bien: le gcode travaille en mode séquentiel et heureusement, sans rien optimiser (sinon il serait capable de prendre, par exemple, un raccourci pour aller d'un point à un autre!).
L'optimisation se passe AVANT la traduction en gcode (parcours d'outil, contournement).
Et pour revenir à l'ordre de calcul:
- initialement le gcode travaillait de gauche à droite (pas de mémorisation possible car, comme j'ai dit initialement, pas de processeur ni de variables mémorisées empilées).
- puis avec l’avènement des unités de calcul à mémoires, du niveau de parenthèse la plus bas vers le niveau le plus haut.
Et on peut maintenant toujours découper son calcul pour le traiter par ordonnancement séquentiel...
Si on code directement en gcode, on a toujours moyen de le découper en petites instructions séquentielles. ça n'a plus d'impact pour tout ce qui est calcul. ça peut toutefois avoir un impact si on découpe en deux instructions un parcours d'outil initialement codé en une seule instruction: hachage de vitesse de déplacement. Mais là, effectivement, les modules d'exécution du gcode peuvent parfois tenter d'optimiser... ... en bien ou en mal.