@Artrag: interesting! added reading that paper to my to-do list. Thanks a lot for the link! Also btw, which text editor you use? I added those screenshots, since theNEstruo uses VSCode and he added support for that, but I use Sublime, so I ported his script to Sublime. But it should be pretty easy to adapt to other editors. The Sublime script is basically 3 lines of text 
( https://github.com/santiontanon/mdlz80optimizer/blob/master/... )
@Metalion, yes! speed optimizations are coming soon! my to-do list before the "v5" release is basically (1) finish a few compatibility issues with asMSX, (2) add and verify 5 more optimization patterns and (3) track and report time savings. So, that's coming to the optimizer soon! :)
Too bad i have only Java 7 on my work computer, where I do most of my MSX development (don't tell my employer!). And since it's my work computer, I'm not allowed to update to a newer Java version.
Ah... Java 7. The last good Java! 
Keeping multiple Java versions has always been a problem because intrusive Oracle's installer... Fortunately, GraalVM Community can be downloaded as a simple zip Even more: you can keep the JRE folder only and ditch the JDK if disk space is an issue!
ah, Java versions
Going down to Java 7 might be possible, but there is a couple of places where MDL uses lambda expressions for convenience, and those would have to be replaced by traditional code. I wish there was an easy way to bundle a minimal JRE into a jar without making the jar automatically go from 900KB to 50MB
I just uploaded a new release (alpha v5), with lots of updates (https://github.com/santiontanon/mdlz80optimizer/releases)
The main ones are:
- Better support for different assembler syntax (still not 100%, but these assemblers are not partly supported): Glass, asMSX, sjasm, tniasm (thanks to theNestruo!)
- Improved optimizer: it can now track time in the optimizations, there are more optimization patterns, and the patterns are a bit more flexible.
An example of how the time optimizations are reported can be seen in this image from sublime:
I don't know if this can be useful to others, but I'm super excited about it, since it has already helped me quite a lot in my current projects! :)
In the next release, I'd like to start focusing on more complex optimizations like register usage, etc. Let's see how far can it go :)
Wohoo! Great to hear! 
(and thanks for the 4 new patterns you just added in that pull request 
)
In addition to the improvements to the optimizer I mentioned, I'd like to start trying to parse sdcc output, which should not be too hard, and given the examples we saw above, the output of sdcc seems like it can be optimized significantly (not sure if the current version of MDL will optimize much for now, but we'll get there )
Oh, I just tried it and you are right! The current optimization pattern says:
pattern: Replace ld b,n; ld c,m with ld bc m+n*256 0: ld b,?const1 1: ld c,?const2 replacement: 0: ld bc,?const2 + 256 * (?const1)
In the particular case you mention above, it gets the wrong value. Instead of #fff9, it loads #fef9 into bc. So, the safe way should be this:
pattern: Replace ld b,n; ld c,m with ld bc m+n*256 0: ld b,?const1 1: ld c,?const2 replacement: 0: ld bc,(?const2 % 256) + 256 * (?const1)
I'll make the update right away! And now that I think about it, the problem is not just with negative numbers, if ?const1 is >= 256, that will interfere with B unles we add the module operation. Good catch!