REV instruction in P2

3dogpottery

Are these equivalent? Seems like a lot of extra
instructins for the P2 that you can do with only
one in the P1.

P1 Assembly code:

mov value, %1101_1111_0010_1010
rev value, #2

P2 Assembly code to do the same thing as above

mov value, %1101_1111_0010_1010
and value, %0000_0000_0000_0011
rev value
shr value, #14

Electrodude

@3dogpottery said:
Are these equivalent? Seems like a lot of extra
instructins for the P2 that you can do with only
one in the P1.

P1 Assembly code:

mov    value,      %1101_1111_0010_1010
rev    value,      #2  

P2 Assembly code to do the same thing as above

mov     value,       %1101_1111_0010_1010
and     value,       %0000_0000_0000_0011  
rev     value  
shr     value,       #14

(I added triple-backquotes in my quote of your post and fixed the alignment)

What are you trying to do? Neither of your snippets has a clear input - both just assign constants to value and then shuffle some bits around. What's the meaning of those big constants? Neither snippet will compile or work anyway because you have immediate values that are bigger than 9 bits and you left the # off of those binary constants.

SaucySoliton

P1
    rev  value,#2

P2
    rev  value
    shr  value,#2

Looking at the manual, I think on P1 the rev instruction is just a shr instruction with a bit reversed D input. Since the P2 only takes 2 clock cycles to do an instruction, these two instructions take the same number of clocks as the P1 instruction. The only use of the reverse with shift right that I know of is the bit reversed indexing of FFT data.

3dogpottery

" What are you trying to do? Neither of your snippets has a clear input - both just assign constants to value and then shuffle some bits around. What's the meaning of those big constants? Neither snippet will compile or work anyway because you have immediate values that are bigger than 9 bits and you left the # off of those binary constants."

Thanks Electrodude for your response. Yes, you're right in that my example is missing a few important details.

I am trying to adapt some P1 code to run on the P2 and ran into a problem with the REV instruction. It looks like the P1 REV assemble instruction does not do the same thing as the P2 REV instruction. With the P1, you can designate a number of lower bits to reverse and fill all the bits above those with zeros. The P2's REV instruction only reverses all 32 bits. So, lets say that I just wanted to reverse the two lsb bits and zero out all the bits above. You would do this in the P1 with the instruction "rev value, #2". The P2 REV instruction is not the same in that you cannot designate how many lower bits you want to reverse; it reverses all of the bits. So as a workaround, I believe you first have to zero out all of the bits above the ones you want to reverse, and then reverse them. However, this will place the reversed bits at the msb position. To get them back to the lsb position, you would then have to shift them right. In the very poor example that I gave, I was trying to show this process.

Wuerfel_21

@SaucySoliton said:
he only use of the reverse with shift right that I know of is the bit reversed indexing of FFT data.

There's actually a bunch. One that I like: say you have an integer variable that you want to update at fixed time steps such that it overall increments at a fixed rate (such as when moving an object around a screen). For any rate that's an integer N units/step, that's trivial (just add N every step). But if you wanted to have an overall speed of 1.5 units/step, you need to increment by 1 or two based on whether the step is even- or odd-numbered ( 2,1,2,1,2,1...). REV allows generalizing this to any fractional speed:

'' xpos is our integer variable
'' speed is intended speed with 8 fraction bits
'' framect is the frame counter (+1 on every update step)
mov tmp, framect
rev tmp,#32-8
add tmp,speed
shr tmp,#8
add xpos, tmp

3dogpottery

@Wuerfel_21 said:

@SaucySoliton said:
he only use of the reverse with shift right that I know of is the bit reversed indexing of FFT data.

There's actually a bunch. One that I like: say you have an integer variable that you want to update at fixed time steps such that it overall increments at a fixed rate (such as when moving an object around a screen). For any rate that's an integer N units/step, that's trivial (just add N every step). But if you wanted to have an overall speed of 1.5 units/step, you need to increment by 1 or two based on whether the step is even- or odd-numbered ( 2,1,2,1,2,1...). REV allows generalizing this to any fractional speed:

'' xpos is our integer variable
'' speed is intended speed with 8 fraction bits
'' framect is the frame counter (+1 on every update step)
mov tmp, framect
rev tmp,#32-8
add tmp,speed
shr tmp,#8
add xpos, tmp

I believe the “rev” instruction you are using here is for the P1. What I am attempting is to find is an equivalent P2 assembly instruction.

Wuerfel_21

Von already gave you that. REV+SHR combo.

Ariba

I usually do it like that:

P1
    rev  value,#2

P2
    shl  value,#32-2
    rev  value

Andy

3dogpottery

@Ariba said:
I usually do it like that:

P1
    rev  value,#2

P2
    shl  value,#32-2
    rev  value

Andy

Looks like your method will work. Shifting left will eliminate the leading bits, and then reversing the whole shebang will reverse and place the bits you reversed in the proper lsb position. Thanks Ariba!

3dogpottery

@3dogpottery said:

@Ariba said:
I usually do it like that:

P1
    rev  value,#2

P2
    shl  value,#32-2
    rev  value

Andy

Looks like your method will work. Shifting left will eliminate the leading bits, and then reversing the whole shebang will reverse and place the bits you reversed in the proper lsb position. Thanks Ariba!

SaucySoliton

@Wuerfel_21 said:

@SaucySoliton said:
he only use of the reverse with shift right that I know of is the bit reversed indexing of FFT data.

There's actually a bunch. One that I like: say you have an integer variable that you want to update at fixed time steps such that it overall increments at a fixed rate (such as when moving an object around a screen). For any rate that's an integer N units/step, that's trivial (just add N every step). But if you wanted to have an overall speed of 1.5 units/step, you need to increment by 1 or two based on whether the step is even- or odd-numbered ( 2,1,2,1,2,1...). REV allows generalizing this to any fractional speed:

'' xpos is our integer variable
'' speed is intended speed with 8 fraction bits
'' framect is the frame counter (+1 on every update step)
mov tmp, framect
rev tmp,#32-8
add tmp,speed
shr tmp,#8
add xpos, tmp

Cool! Thanks for sharing.

R Baggett

@Wuerfel_21 said:
Von already gave you that. REV+SHR combo.

Daaaang.. I was solving a similar problem the long way around.. and you just kicked it's bum by accident!

Thanks!