TRSE
TRSE copied to clipboard
Better 6502 asm optimization
procedure Do1() inline; begin asm(" lda $1234 ora #$10 sta $1234 "); end;
procedure Do2() inline; begin asm(" lda $1234 ora #$20 sta $1234 "); end;
calling Do1(); Do2();
produces the following asm: ; ****** Inline assembler section lda $1234 ora #$10 sta $1234
; ****** Inline assembler section
ora #$20
sta $1234
A better-optimized version could be: LDA $1234 ORA #$10 ORA #$20 STA $1234
Another step of optimization could be merging of ORAs into ora #$30. LDA $1234 ORA #$30 STA $1234
I'm aware this can be dangerous when working with SID/TED/VICII/etc. registers or variables modified by an IRQ, we could mark these variables/addresses/pointers with a "volatile" like keyword (or similar another word, never mind).
This one is extremely difficult to optimise, as the internal optimiser isn't at all built for this kind of optimisation. The reason: TRSE doesn't know what STA $1234 contains, if it is a port address (as on the NES) or whatnot - removing this single STA will produce a lot of problems with other systems. This could be fixed if I provide a list of every single "special" address for all the systems - but is a tremendous amount of work to do for such a small optimisation.
Also, I just realised that the current optimiser above (removing the lda $1234) is dangerous - if $1234 contains data that is changing (such as $d012, the raster line), then the above code would fail. Perhaps I need to add support for "live" memory addresses after all (memory addresses that are updated / read independently of the CPU)
This (dangerous to not re-read a chip register or port address) is the very reason why I mentioned the "volatile" keyword of C. If a variable is decorated as volatile, its value will always read, skipping all kinds of optimizations.
Volatile keyword added for the 6502 + help text. Experimental, not fully tested yet