dschmenk / PLASMA

Proto Language AsSeMbler for All (formerly Apple)
MIT License
189 stars 26 forks source link

New optimisations #19

Closed ZornsLemma closed 7 years ago

ZornsLemma commented 7 years ago

Here are some changes I've been working on to the PLASMA compiler's peephole optimiser. CMD#FF2000 (i.e. the compiled Apple II VM PLASMA code) shrinks from 4060 bytes to 3994 bytes with these optimisations, and I'd expect similar gains to be made on other code. There are no VM changes - this is all in the compiler.

I've refactored my code changes into what I hope are a logical series of commits to make them intelligible, but please let me know if you have any questions.

dschmenk commented 7 years ago

Steve - you're in danger of turning this into a legitimate compiler. That's some pretty significant savings! With these changes, is there any chance to optimize a sequence in the middle of a branch target? Could something like SLW; LABEL: LLW somehow get changed into LABEL: DLW which might not have the same functionality?

ZornsLemma commented 7 years ago

Thanks Dave. :-)

Obviously I could have made a mistake, but I don't believe branch targets are a problem, because they are emitted by emit_codetag() and that does emit_pending_seq() before emitting the label itself. So the optimiser should never see a sequence with a branch label in it.

This is the reason various emit_*() functions have emit_pending_seq() added at the top - they are all functions which are called by the parser to directly emit instructions without building up a sequence, and therefore they need to emit the pending sequence before emitting what the parser is telling them to emit.

I suspect some of those emit_() functions (e.g. emit_const(), but of course not* emit_codetag()) could push their instruction into the pending sequence instead of emitting it - this would potentially give the optimiser more scope for making changes. I didn't do this because I wasn't confident it wouldn't cause problems.

I hope this makes sense, I'm aware it may not... :-)

dschmenk commented 7 years ago

I added the -O flag for ROGUE (can't remember why I didn't earlier). Here are pre -O sizes

-rw-r--r-- 1 dschmenk staff 5279 Jul 28 16:51 ROGUE#FE1000 -rw-r--r-- 1 dschmenk staff 1859 Jul 28 16:51 ROGUECOMBAT#FE1000 -rw-r--r-- 1 dschmenk staff 2064 Jul 28 16:51 ROGUEIO#FE1000 -rw-r--r-- 1 dschmenk staff 7615 Jul 28 16:51 ROGUEMAP#FE1000

and after

-rw-r--r-- 1 dschmenk staff 4393 Jul 28 16:59 ROGUE#FE1000 -rw-r--r-- 1 dschmenk staff 1763 Jul 28 16:59 ROGUECOMBAT#FE1000 -rw-r--r-- 1 dschmenk staff 1813 Jul 28 16:59 ROGUEIO#FE1000 -rw-r--r-- 1 dschmenk staff 6868 Jul 28 16:59 ROGUEMAP#FE1000

Wow.

The downside is that it currently crashes. Rogue working on your side?

I see what happened - missed adding CFFB to AUX mem version of opcodes. All better now

ZornsLemma commented 7 years ago

Thanks Dave, I'm glad it worked, and sorry about missing that AUX case.