Big update to prettier-extension-monkeyc

flocsy said:

So this looks like some serious bug in the compiler, but still what I don't understand is why this happens only when I compile with the prettier optimizer

My guess is that that MyApp/bin/optimized/group005-debug/source/source/test/Test.mc is a stale version of the file? Maybe my extension is finding an old copy via some arcane monkey.jungle rule that only applies to fenix6? if thats the case its probably a bug in how I interpret the jungle file...

No, the "generated" Test.mc is as it should be, exact copy of the original (as it only has empty lines and comment lines).

Also, the problem only happens when I add a Dictionary variable or const to global scope.

Another interesting curiosity: "recursive usage of prettier optimizer": I copied the generated output to the source folder of a new project to test how that compiles, and I accidentally compiled it with prettier which generated different code and bigger data size than without prettier.

And I managed to reproduce the problem:

garbagestr.zip

You'll need to edit run.sh, but the main point is this:

1. you comment out dfminApp.mc#6: 

Opps, I did it again... I'm not used to VSC, and I don't really understand also why are there so many ways to build/run. I am OK with having different shortcuts to go the same, but in VSC I know at least these ways to build, all have slightly different meaning:

Command+Shift+P Prettier Monkey C: Build and Run Optimized project (this is what I usually do)

But there are also the different options from launch.json:

Run App, Build and Run Optimized - Debug, Build and Run Optimized - Release

Can you rename "Prettier Monkey C: Build and Run Optimized project" to "Prettier Monkey C: Build and Run Optimized project - Debug" and add "Prettier Monkey C: Build and Run Optimized project - Release" ?

flocsy said:

I noticed that constants that are Array or Dictionary are kept in the optimized code

So I just took a look at this - and I'm not seeing that. In fact there's a bug - it removes them even if they're initialized by a function.

eg "const foo as Array = [bar(), baz()];" will be removed, even though bar() and baz() may have important side effects.

Did you mean that *variables* don't get removed? Because thats true. For no good reason, I only remove unused constants, not unused variables. But it has nothing to do with arrays and dictionaries...

Also note that "unused" is pretty conservative. If you have a constant named FOO, and somewhere in your program you mention :FOO, it won't remove the constant (because you can access the global FOO as $[:FOO]). Similarly if you have a variable x, and say x.FOO, it won't remove it, because you might have said "x = $;" somewhere. This is all old code that predates my type checker, so I could do much better now; but as I've said a couple of times recently, Im going to rewrite the dead code removal anway...

So - if you have a specific example that fails can you post it?

ok the :FOO thing probably explains what you did not drop it at some phase, though it doesn't explain why it's kept at the end because every other mention of "FOO" is gone because of the constant inlining:

flocsy said:

But there are also the different options from launch.json

The options in launch.json are whatever you put there - including whatever their names are. There are no default launch configurations. I posted mine a while back, and I think you may have copied them.

Also, you can add build configs to tasks.json - but those are less useful except for quick rebuilds to check on sizes, and for customized export settings.

flocsy said:

Can you rename "Prettier Monkey C: Build and Run Optimized project"

I could; but basically I was trying to keep things simple. If you want more complex options, you can create them using launch.json and tasks.json.

Also, it mirrors Garmin's "MonkeyC - Build Current Project" command, which takes the debug/release from your current settings.

flocsy said:

So when both constants are only mentioned in test_me, and test_me isn't used at all (depending on :use_or_not) 

It's not quite clear what you mean by that.

If I try your example, and set use_or_not as an excludeAnnotation, then test_me, TEST_FALLBACK, and TEST_DICT are all gone. If thats not the case for you, its a bug.

On the other hand, if I don't set use_or_not as an excludeAnnotation, and call test_me from somewhere, then test_me and TEST_FALLBACK are indeed gone, while TEST_DICT is still there - but it needs to be, because its used at the point where test_me was inlined.

Finally, if I don't set use_or_not as an excludeAnnotation, and don't call test_me from anywhere, then again, test_me and TEST_FALLBACK are gone, while TEST_DICT is still there. And this is the same problem I've mentioned a few times recently. At the end of the optimization phase, test_me looks like

const TEST_FALLBACK = 12;
const TEST_DICT = {
  26008707 => [null],
  26008205 => [null],
  26008713 => [null],
} as Dictionary<Number, Array>;

(:inline, :use_or_not)
function test_me(h as Number) as Number? {
  var arr = TEST_DICT[h];
  return arr == null ? 12 : arr[0] as Number?;
}

v2.0.51 is out.

The big change in this version is that I've added a post-build optimizer. That takes the .prg file, disassembles the code section, optimizes it, and writes out a new .prg file.

At -O0 or -O1 this saves a lot (Garmin's compiler leaves a lot of dead code at these optimization levels). For me, around 500 bytes on an 11k executable.

At O2 the savings are much less - only 108 bytes for my project. But it depends what you do. If you use try/catch much, it will save you a lot. If you have a lot of global or module scope functions, it will probably save quite a lot. And I have a number of planned optimizations that should make things much better.

For now this is "experimental" so it's off by default. You can turn it on in settings via the "Post Build Optimizer" setting, or you can turn it on in specific tasks or launch configs via the "postBuildOptimizer" field.