I would expect compilers to make regular use of the ALTx instructions. Although, my one attempt to get my head around them resulted in confusion about their capabilities, so I'm no expert.
SETx changes the value in cog memory. ALTx changes the value in the instruction pipeline. So they are slightly different.
Yes, I understand that. I think the ALTx instructions were added when it was realized that you couldn't use SETx in hubexec mode. However, it seems like ALTx could handle everything that SETx could in a slightly different way. I guess I've always been nervous about self-modifying code and I'm glad ALTx provides a way to avoid that if you choose.
I was using the SETx instructions to configure an assembly subroutine before calling it.
Don't think you can do that with ALTx...
Interesting. I suppose that is a rather unusual way to pass parameters to a non-recursive subroutine. It would have to be in COG memory though, right? Or will SETx work to hub memory if you use AUGD to provide a full hub address?
Now that I think about it, I suppose I could have used some registers for the parameters and then used ALTx instructions inside the routine to set them.
But, I think the SETx is more direct and maybe saves register space...
Now that I think about it, I suppose I could have used some registers for the parameters and then used ALTx instructions inside the routine to set them.
But, I think the SETx is more direct and maybe saves register space...
ALTx has to be used every time you execute the "modified" instruction so I guess SETx would generate faster code if the modified instruction was in a loop.
alts lmm_w, ##_TABLE_CCCC '\ set next S to offset+table addrs
mov lmm_p, #0-0 '/
Of course this expands into AUGS + ALTS + MOV instructions by the compiler.
BTW Don't forget the "#" in the mov xxxx,#0 instruction!!!
I've added a section to the documentation about this. ALTR/ALTD/ALTS are useful for indirect cog register reading, not hub reading. I'm going to complete that section now.
There's a new section in the documentation called "REGISTER INDIRECTION" that covers the ALTI/ALTR/ALTD/ALTS and SETI/SETD/SETS instructions. It took me a bit to relearn everything ALTI does.
The ALTx instructions pretty much antiquate the need for self-modifying code.
The SETI/SETD/SETS instructions can be used for self-modifying code, but are really useful for setting up ALTI behavior.
This picks up 16 longs in cog RAM, starting at 'w', XOR's them with 'opad' ($5C5C5C5C), then writes them starting at 'opad_key'. It uses the ALTI instruction to indirect and increment pointers for both the D register ('w') and result register ('opad key').
This picks up 16 longs in cog RAM, starting at 'w', XOR's them with 'opad' ($5C5C5C5C), then writes them starting at 'opad_key'. It uses the ALTI instruction to indirect and increment pointers for both the D register ('w') and result register ('opad key').
Your documentation states SETI, not SETR. Personally, I think SETR is more appropriate.
Comments
It works nicely as a indirect register mechanism too.
ALTS now working with hubexec
Don't think you can do that with ALTx...
But, I think the SETx is more direct and maybe saves register space...
And I am hoping for the opposite. On rare occasions self modifying code makes things so much easier.
Note if you are only using SETS/SETD/SETI to set/modify a register, then spacer instructions are not required.
BTW Don't forget the "#" in the mov xxxx,#0 instruction!!!
eg JMP #@$1000 ?
Pnut default is relative.
Use #\ to force absolute address.
I've added a section to the documentation about this. ALTR/ALTD/ALTS are useful for indirect cog register reading, not hub reading. I'm going to complete that section now.
The ALTx instructions pretty much antiquate the need for self-modifying code.
The SETI/SETD/SETS instructions can be used for self-modifying code, but are really useful for setting up ALTI behavior.
There was one snippet of code that translated in kind of a surprising way:
This picks up 16 longs in cog RAM, starting at 'w', XOR's them with 'opad' ($5C5C5C5C), then writes them starting at 'opad_key'. It uses the ALTI instruction to indirect and increment pointers for both the D register ('w') and result register ('opad key').
Your documentation states SETI, not SETR. Personally, I think SETR is more appropriate.
S = source
D = destination
I = instruction
SETR can't affect the result register like ALTR does. It can only fiddle bit fields of stored RAM.