Talk:RTS Trick: Difference between revisions
No edit summary |
(→Self-modifying: main, NMI, and IRQ = 21 bytes) |
||
| Line 7: | Line 7: | ||
* PHA, PHA, RTS requires less bytes than STA, STA, JMP (3 vs. 9). | * PHA, PHA, RTS requires less bytes than STA, STA, JMP (3 vs. 9). | ||
== Self-modifying == | |||
If you use self modifying code and assure that the table has to start at a page border (and store pointers to the routines, without the -1) then you can use a smaller and faster code: | If you use self modifying code and assure that the table has to start at a page border (and store pointers to the routines, without the -1) then you can use a smaller and faster code: | ||
| Line 27: | Line 28: | ||
rts ; 1, 6 | rts ; 1, 6 | ||
; total 11 bytes and 24 cycles | ; total 11 bytes and 24 cycles | ||
--[[Special:Contributions/212.8.208.194|212.8.208.194]] ([[User talk:212.8.208.194|talk]]) | |||
Assuming that by <code>sta smc+2</code> you meant <code>sta smc+1</code> because 6502 is little-endian. But if you're doing any sort of nontrivial work in the NMI or IRQ handler, you would need separate 7-byte self-modifying trampolines in RAM for the main, NMI, and possibly IRQ handlers. And with the NES's 2048 byte RAM, 21 bytes might be a lot, though it's still not as bad as it would be on the Atari 2600. --[[User:Tepples|Tepples]] ([[User talk:Tepples|talk]]) 11:18, 21 May 2013 (MDT) | |||
Revision as of 17:18, 21 May 2013
is there an advantage over using JMP ($0200), where $0200 has been loaded from the same kind of jump-table? that's what I wonder, but I'm not gonna count up the cpu cycles needed for either method right now.
MetalSlime: Not sure. Seems like a pick'em to me. Here are some things that come to mind:
- RTS Trick doesn't require any RAM.
- I personally think the RTS Trick is more readable. If I see a table of pointers in my (or somebody else's) code and they all have a "-1" after them, I immediately know their purpose and how they are used.
- PHA, PHA, RTS requires less bytes than STA, STA, JMP (3 vs. 9).
Self-modifying
If you use self modifying code and assure that the table has to start at a page border (and store pointers to the routines, without the -1) then you can use a smaller and faster code:
tb_opcode_launcher_smc: ; bytes, cycles asl ; 1, 2 sta smc+2 ; 3, 4 smc: jmp (tb_opcode_rts_table) ; 3, 5 ; total 7 bytes and 11 cycles
tb_opcode_launcher: ; bytes, cycles asl ; 1, 2 tax ; 1, 2 lda tb_opcode_rts_table+1, x ; 3, 4 pha ; 1, 3 lda tb_opcode_rts_table, x ; 3, 4 pha ; 1, 3 rts ; 1, 6 ; total 11 bytes and 24 cycles
--212.8.208.194 (talk)
Assuming that by sta smc+2 you meant sta smc+1 because 6502 is little-endian. But if you're doing any sort of nontrivial work in the NMI or IRQ handler, you would need separate 7-byte self-modifying trampolines in RAM for the main, NMI, and possibly IRQ handlers. And with the NES's 2048 byte RAM, 21 bytes might be a lot, though it's still not as bad as it would be on the Atari 2600. --Tepples (talk) 11:18, 21 May 2013 (MDT)
