@Wuerfel_21 said:
I have a lot of inline ASM that does this
In your emulators? I'm seeing both local uses and COGINIT'd uses, but nothing that seems to be global uses of PTRB within inlined assembly.
In the emulators that would usually be found in the "upper" part. NeoYume has a load_romdata function that transforms various data types on the fly while loading.
Though I am now realizing that in some recent version I essentially got rid of PTRB usage in the very load-bearing LOAD_CROM implementation (loads all the "C" files, in odd/even pairs). It still uses PTRB, but no more indexing, so that one could actually be moved to a different register.
If it is used as a static system variable the way PTRA register is being use, sure.
But there is the intermediate option of reloading it for internal uses. The compiler already uses PA register this way. Either PTRA or PTRB could be chosen to be reused this way. This approach has overhead but not near as much as using neither register.
I use this reloading/sharing mechanism in the SD card driver. It nicely cleans up the multiple instances situation. It got refined more recently with the bug fixes in both v1.2 and v1.4. There was two things I needed to get right:
Pin DIR control is a special resource in that one cog can negatively impact the operation of all other cogs. This needed DIR lowered on all used pins upon end of each transaction - exiting each callback. Which meant equally making sure each pin was appropriately controlled again upon entering each callback.
Cog specific resources like SETSE1/WAITSE1 always get init'd upon entering each callback.
Of note is the sharing mechanism relies on, or at least SETSEx config does, cooperative handling. Pre-emptive handling wouldn't work without also adding a serialising mechanism on top of that. Can't do this sharing with an interrupt routine for example.
EDIT: Hmm, on the other hand, a SETSE1 is probably going to be the IRQ source in that situation. It won't be sharing.
Comments
Err, I should have said static uses instead of global uses but I presume you get the idea.
In the emulators that would usually be found in the "upper" part. NeoYume has a
load_romdatafunction that transforms various data types on the fly while loading.Though I am now realizing that in some recent version I essentially got rid of PTRB usage in the very load-bearing LOAD_CROM implementation (loads all the "C" files, in odd/even pairs). It still uses PTRB, but no more indexing, so that one could actually be moved to a different register.
That's just local temporary use. You're not statically holding a running value in PTRB.
But if the compiler was using PTRB I'd be trashing its value.
If it is used as a static system variable the way PTRA register is being use, sure.
But there is the intermediate option of reloading it for internal uses. The compiler already uses PA register this way. Either PTRA or PTRB could be chosen to be reused this way. This approach has overhead but not near as much as using neither register.
I use this reloading/sharing mechanism in the SD card driver. It nicely cleans up the multiple instances situation. It got refined more recently with the bug fixes in both v1.2 and v1.4. There was two things I needed to get right:
Of note is the sharing mechanism relies on, or at least SETSEx config does, cooperative handling. Pre-emptive handling wouldn't work without also adding a serialising mechanism on top of that. Can't do this sharing with an interrupt routine for example.
EDIT: Hmm, on the other hand, a SETSE1 is probably going to be the IRQ source in that situation. It won't be sharing.