Assembler Optimizer

Paragon (1831)

28-05-2021, 22:17

Cool! And indeed, in this case MDL will not find it. The problem is that there is a label ("respawn_y_updated") in the middle, so, MDL is not sure if there are other ways to get to that "ld hl,respawn_time" where "hl" might have a different value, hence it does not find the optimization. But this is nice though!!! I'm glad that it was able to inspire another optimization!

Par thegeps

Paragon (1251)

29-05-2021, 00:41

Yep. Unluckily there were few optimization on this critical routine (putsprites) that is hooked to H.TIMI
Just few t-states (less than 20). Most of them were add a,2/add a,-2 instead of inc a inc a/dec a dec a.
I've used dec/inc when, time ago, the code was detecting bullet going out of screen directly at 0/255. So dec/inc would have triggered the carry. Then I've changed exit value to 3/253 using cp instruction and forgot to changed double inc/dec to add a,2/-2.
In other non critical routines there were a lot of "xor a" used to reset the carry in old implementations and forgotten there. There weren't all executed everytime (they were mostly conditionals) so the speed gain is low.

But I'm fine with this. First of all because I've tried MDL (I wanted to do it since you have released it, but I was very busy with Freedom Fighter physical version improvement) and this give me the chance to improve my skills learning some cool coding tricks!
Secondly, I've gained a good amount of bytes too (and I'll use them for the last add I want)
And last, but not least, if there is only few optimization in crucial parts then my code isn't too bad ahah!

Par santiontanon

Paragon (1831)

29-05-2021, 05:09

OH, another thing you can try if you want to see if a few additional bytes or speed can be gained is to run the other optimizer "-ro" instead of "-po speed". This is just trying to eliminate jp/jr/call/ret statements, but some times it finds interesting things

Par santiontanon

Paragon (1831)

30-05-2021, 02:53

It took a while, but I finally have a first version of a new optimizer in the latest release: https://github.com/santiontanon/mdlz80optimizer/releases/tag...

It is a new version of the search-based optimizer, that in addition to generate code, it can be used to optimize existing code! It is super slow for now, and doesn't find many optimizations yet, but I think this will be very cool once it starts maturing a bit more!

The way it works is like this, imagine you have an assembler file/project (my-project.asm), you trigger it like this:

java -jar mdl.jar my-project-asm -so-opt speed

And what it will do is go line by line in the assembler project and take blocks of 2 CPU instructions at a time, and use the search-based optimizer to try to find a better alternative (you can specify the block size via the -so-blocksize flag, but with the default block size 2 it's already quite slow hehe). It has many constraints, and only a subset of the CPU instructions are still supported, so, any use of RAM/stack/jumps/ghost registers and a few other things will make the search-based optimizer to ignore that part of code. Hence, it only finds a very small set of optimizations for now (and it takes about 1
to 2 minutes to optimize a typical assembler project), but still! This is just the beginning! I'm quite excited about this since this is what I imagined MDL would do to begin with (and the other optimizers were just tests to get to this point!).

In any case, it's highly experimental and I would not 100% trust the optimizations it generates just yet, so, use with caution. But I'll be working on it over the next few weeks to try to make it faster and support more and more CPU instructions, so it can find more optimizations!

Par thegeps

Paragon (1251)

01-06-2021, 14:28

mmm, Santi, I think I've found a bug.

I have this output:
INFO: Pattern-based optimization in ffplet.asm#5612: Remove unused xor a (1 bytes, 5 t-states saved)

but MDL doesn't know that in this case "xor a" is to pass a parameter.

	xor	a
	call	PLY_AKG_STOP

maybe is better avoid to remove unused instructions before a call, as they could be parameters

Par santiontanon

Paragon (1831)

01-06-2021, 14:52

Are you sure PLY_AKG_STOP uses "A" in this case? MDL will actually look inside the function to see if it's being used. It might also be that PLY_AKG_STOP uses A in general, but that in this particular call, because of the value of the other registers, its value does not matter.

Par Metalion

Paragon (1628)

01-06-2021, 16:50

It might not use A itself but only the flags values generated by 'xor a'.
I use a similar trick to reset the carry flag before some code with 'and a'.

Par santiontanon

Paragon (1831)

01-06-2021, 17:37

Good point! But that should be taken into account too in this case. The pattern that triggered there is this one:

pattern: Remove unused ?op ?any
0: ?op ?any
replacement:
constraints:
in(?op,or,and,xor)
regsNotUsedAfter(0,A)
flagsNotUsedAfter(0,S,Z,H,P/V,N,C)

Which only triggers if A is not used, and neither are the the S, Z, H, P/V, N and C flags resulting rom that instruction. There are likely patterns where I forgot a safety condition or another, but in this case, I think the pattern is pretty safe. Could you confirm that neither A or any of the flags are actually used by that function @thegeps?

Par thegeps

Paragon (1251)

01-06-2021, 17:38

ok, I've checked. "xor a" not required. I've been mistaken, because "xor a" is required before "call PLY_AKG_INIT", to select the subsong.

both the routine are from arkos AKG player

Par santiontanon

Paragon (1831)

01-06-2021, 18:04

Ah! great to hear! Thanks!

The safety conditions of the optimization patterns are created by hand, so, I am 100% sure that I have forgotten a safety condition here or there. So, this type of reports are good to make sure things work as expected! Every once in a while I go through a few optimizations to make sure they are all correct. But the more eyes looking into it the better!!!