Can also use ANDN Counter, #%1<<8 ' remove bit 8 (turn 128 in to 0)
Actually "ANDN Counter,#%1<<8" will turn 256 into 0. "ANDN Counter,#1<<7" will turn 128 into 0. Of course, MOVS will copy the 9 LSBs of the source value to the 9 LSBs of the destination. You would need "ANDN Counter,#3<<7" if you only wanted the 7 LSBs.
That's assuming that bits 31 .. 9 are already zero. To get just the seven LSBs under all circumstances, you can do:
and Counter,#$7f
-Phil
Phil, I was assuming it was used in conjunction with MOVS as in the object we were talking about on the first page of this thread. You are correct that you would need to AND with $7f if you wanted to clear all of the high order bits above the 7 LSBs.
The listing is probably one of the most powerful tools available for understanding code once you know PASM...For my own PASM coding, I use the Propeller DataSheet PASM instruction listing since it is a good summary in all in one place....Starting with the Propeller Manual is very frustrating...
Lots of really great advice in your post. It has already helped a ton. One of the oddest things I've encountered today (and I'm not saying odd is bad!) is the Propeller's particular flavor of self-modifying code. What makes it seem so odd to me is that there aren't separate opcodes and operands in Propeller machine code. It's all just 32-bit chunks of stuff. Hence the MOVI, MOVS, and MOVD instructions.
I went at this whole thing bassackwards. Up to now my only use of these three commands was in the configuring of timers (eg CTRA). Until today I thought that was their only use. Now I realize that it is only an ancillary use. It would seem that their primary use is to fiddle with the aforementioned 32-bit chunks. I'm sure this is obvious to everyone else, but it was a bit of a watershed for me. It seemed so odd to see code operating on a freaking label! I was staring at that apparent nonsensicality when the light suddenly dawned.
Ah yes, out there in "normal" computer land self modifying code is frowned upon. Here in Propeller land it's essential. Hence the MOVI, MOVS etc.
Frowned upon or not, I've always taken advantage of it whenever it was available (whenever execution was in RAM). But here (on the Prop) there are no isolated memory locations to overwrite. There are just 32-bit chunks to tweak, and official tools to do the tweaking. It amounts to the same thing, but it looks a lot different - at least it does today. Overnight my neurons may rewire and all will seem normal.
Lots of really great advice in your post. It has already helped a ton. One of the oddest things I've encountered today (and I'm not saying odd is bad!) is the Propeller's particular flavor of self-modifying code.
Glad it helped. BSTC is my favorite SPIN compiler.
The worst part is having to use it for indirect addressing. The slot delay between modify and execute is also a pain, but one can usually find something useful to insert there. Watch out for that immediate # notation - it still trips me.
A good syntax highlighting and regex search/replace editor for PASM is priceless - I use VIM :-)
in both cases, the RET is really a JMPRET whose address (source) gets filled in by the CALL which is really a JMPRET too like
jmpret my_ret,#my
In the first case, the jmp actually jumps to my_ret, hence the extra 4 system clocks to execute the ret (jmpret). In the second case, the jmp uses the source field of my_ret as its operand (jump address) and jumps directly to the saved address.
Yes the Propellers own assembly flavor is different than any other single assembly. On the flip side I have used a processor that had an assembly that used effects in the same way the Prop does, though that was long enough ago that I can not recall of the top of my head what it was.
Comments
-Phil
Lots of really great advice in your post. It has already helped a ton. One of the oddest things I've encountered today (and I'm not saying odd is bad!) is the Propeller's particular flavor of self-modifying code. What makes it seem so odd to me is that there aren't separate opcodes and operands in Propeller machine code. It's all just 32-bit chunks of stuff. Hence the MOVI, MOVS, and MOVD instructions.
I went at this whole thing bassackwards. Up to now my only use of these three commands was in the configuring of timers (eg CTRA). Until today I thought that was their only use. Now I realize that it is only an ancillary use. It would seem that their primary use is to fiddle with the aforementioned 32-bit chunks. I'm sure this is obvious to everyone else, but it was a bit of a watershed for me. It seemed so odd to see code operating on a freaking label! I was staring at that apparent nonsensicality when the light suddenly dawned.
Frowned upon or not, I've always taken advantage of it whenever it was available (whenever execution was in RAM). But here (on the Prop) there are no isolated memory locations to overwrite. There are just 32-bit chunks to tweak, and official tools to do the tweaking. It amounts to the same thing, but it looks a lot different - at least it does today. Overnight my neurons may rewire and all will seem normal.
The worst part is having to use it for indirect addressing. The slot delay between modify and execute is also a pain, but one can usually find something useful to insert there. Watch out for that immediate # notation - it still trips me.
A good syntax highlighting and regex search/replace editor for PASM is priceless - I use VIM :-)
But here's a tip: the "#" is not necessary if you're JMPing to a RET, and you will save an instruction cycle by not including it.
-Phil
You can have or you can have in both cases, the RET is really a JMPRET whose address (source) gets filled in by the CALL which is really a JMPRET too like In the first case, the jmp actually jumps to my_ret, hence the extra 4 system clocks to execute the ret (jmpret). In the second case, the jmp uses the source field of my_ret as its operand (jump address) and jumps directly to the saved address.
-Phil