Big update to prettier-extension-monkeyc

Sorry, I used the wrong helper function, and as a result the fix only worked if VALUE1 and VALUE2 weren't defined to be the same thing (both 0 in your case).

v2.0.10 should fix it.

It's OK now, thanks.

Given the quirks of the Monkey C compiler, I just have to ask:

If a global variable is has just one reference in a function, but it is in a loop, is the reference looked up just once for the function, or for each iteration of the loop?

Pretty sure it’s every time. The runtime may have caches to speed that up, but I doubt it, and it would be pretty hard to test

I just ran a quick test, and yes, the function is faster if a local variable is set to the global and then used in the loop.

With the global in the loop, about 2592 us averaged over 2328 function calls.

With a local variable set to the global, about 1841 us averaged over 1974 function calls.

This is on an actual Fenix 7X, not the sim. I don't know if the optimizer makes this change, but if not then maybe something to look at.

The Prettier Monkey C as far as I know (and I use) optimizes for memory size, not performance.

Pretty sure we had this conversation before. Partial Redundancy Elimination would do exactly that, but it can also increase code size (and would in your case). So I went for a version that reduces code size rather than execution path length. I could add a proper PRE implementation, and a flag for speed vs size, but it's not a high priority for me.

With the Fenix 7X being CIQ 5 the garmin compiler is already doing a much better job reducing code size than with previous versions. The space savings are probably minimal vs the code speed up which at 20-30% seems like a decent amount. I didn't actually check for the difference in code size, and it would likely have a much bigger impact on CIQ 1-3 devices. My FR235 doesn't have a profiler on the watch (that the -k option would initiate) so I don't know how I could know. The minimum code vs faster code argument brings us to the nomenclature of "optimizer". Right now it's a minimizer as far as I can tell, as we learn more and get smarter then the next gen might optimize. As we've said previously it is like beauty: No one can say what it is, but we know it when we see it, and of course depends on the eye of the beholder.

The minimum code vs faster code argument brings us to the nomenclature of "optimizer". Right now it's a minimizer as far as I can tell

Are you claiming that reducing code size is not "optimization"?

gcc and the monkey c compiler would beg to differ:

gcc.gnu.org/.../Optimize-Options.html

https://postimg.cc/MMz7y6Q0

https://postimg.cc/hzM9skLk

developer.garmin.com/.../

https://postimg.cc/xkvGJJcT

Note the use of words optimize/optimizing/optimization to refer the reduction of code size, as well as decreasing execution time / increasing performance.

Maybe you should ask Garmin and the gcc maintainers to change their nomenclature as well. Just because your definition of "optimization" apparently only includes optimization for speed, doesn't mean that everyone else shares that definition.

And just because an optimizer is designed to optimize for size and not performance doesn't mean it's not an optimizer. It's just not the kind of optimizer you are looking for.

as we learn more and get smarter then the next gen might optimize

This is a super condescending thing to say to the author of a free third party monkey c optimization tool, especially when you're asking him to add a new feature. The use of "we" is especially hilarious: are you contributing to development of this tool, other than testing and reporting bugs?

As he said right in the comment you're replying to, his tool optimizes for size and not speed by design, not because he needs to learn more and get smarter. Based on his comment, he knows exactly how to optimize for speed, but that's not how he's chosen to allocate his time for this free project.

As we've said previously it is like beauty: No one can say what it is

Are you serious lmao