Thoughts on PA and PB
TonyB_
Posts: 2,126
CALLPA and CALLPB are really useful instructions, particularly with XBYTE but also generally. So much so that PA and PB should be chosen as two of the main working registers whenever possible. If the P2 instruction set is extended in the future there is very little room for more D,S instructions but plenty of space for D-only, some of which could have an implicit S that is either PA or PB.
It might be possible to have D-only instructions with three operands D,SA,SB where SA,SB are both implicit and are either PA,PB or PTRA,PTRB.
EDIT:
Added 2nd paragraph.
Comments
I've wanted a variant of those two instructions that also branch to immediate encoded lutRAM addresses. Which would of course chew up two more of the precious dual operand encoding slots.
Yea, lining up the CALLPx functions into the middle of the code space is a bit tricky...
Do you mean a JMP version? It's possible to branch to LUT RAM from cog RAM or vice-versa with
CALLPx D,#Sprovided the jump is within range.To be fair this applies to other instructions such as TJxx & DJxx and there's always the register S option if all else fails.
A while back I found CALLPx was rather nice for high level languages as well, as a way to do far branching/calling when running from external memory. You can pass the destination branch address and call a jump handler in COGRAM as well AND it saves the caller's address on the stack for you too.
You do need an AUGD as well for 32 bit constants.
https://forums.parallax.com/discussion/comment/1535144/#Comment_1535144
I should get back into that external memory stuff at some point too and maybe more GCC...
Huh, of course, AUGS does the lutRAM range. But then, for what I wanted, a MOV PA followed by a long CALL does the same.
It might be possible to have D-only instructions with three operands D,SA,SB where SA,SB are both implicit and are either PA,PB or PTRA,PTRB.
Added to first post.