REV is driving me crazy

Ale

Well,

I'm now testing the FFT on a real propeller, so I wrote some help and test code. All looks good but the decimate routine.

Symptom: The REV instruction is not behaving as I think. Here is the routine:

decimate           mov     fft_ii,#1
                        mov     fft_ll,cnt_k1_1024 'fft_n
ldecimate          mov     fft_jj,fft_ii
                        rev      fft_jj,#10 'BITS_NN
                        
                        cmp     fft_ii,fft_jj   wc
              if_nc    jmp     #ldecimate_5
'                       cmp     fft_jj,cnt_k1_1024    wc
'              if_nc   jmp     #ldecimate_5
                        mov     fft_fr_ii,fft_ii
                        shl       fft_fr_ii,#1
                        add      fft_fr_ii,fft_fr

                        'and     fft_jj,cnt_k1_03ff
                        mov     fft_fr_jj,fft_jj

                        rdword  fft_tr,fft_fr_ii

                        shl       fft_fr_jj,#1
                        add      fft_fr_jj,fft_fr
                        rdword  fft_result,fft_fr_jj
                       'mov      fft_tr,cnt_k1_mask
                        wrword fft_tr,fft_fr_jj
                        wrword fft_result,fft_fr_ii
ldecimate_5       add      fft_ii,#1
                        cmp     fft_ii,fft_ll   wc
              if_c      jmp     #ldecimate
decimate_ret      ret

I hope it is readable.

This should reverse the addresses from 1 to 1023 using the REV instruction.
As it is a REV something, #10 it means that it will not produce any number beyond 1023 (I tested it with some other program using the '><' spin operator, it looked ok).

Well: either with the second comparison or with the commented-out and or without them... I get different results ! This is very wired... And are the input values around 320 to 380 the ones that produce a wrong output (It does not show in spin !?).

Any idea ?

Lee Marshall

take a look at the REV documentation again:

REV
Instruction: Reverse LSBs of value and zero-extend.
REV Value, 〈#〉 Bits
Result: Value has lower 32 - Bits of its LSBs reversed and upper bits cleared.
     •   Value (d-field) is the register containing the value whose bits are reversed.
     •   Bits (s-field) is a register or a 5-bit literal whose value subtracted from 32, (32 - Bits),
         is the number of Value’s LSBs to reverse. The upper Bits MSBs of Value are
         cleared.
  –INSTR– ZCRI –CON–      –DEST–       –SRC–           Z Result       C Result      Result   Clocks
                                                       Result = 0       D[noparse][[/noparse]0]        Written     4
  001111 001i 1111 ddddddddd sssssssss
Explanation
REV (Reverse) reverses the lower (32 - Bits) of Value’s LSB and clears the upper Bits of
Value’s MSBs.
If the WZ effect is specified, the Z flag is set (1) if the resulting Value equals zero. If the WC
effect is specified, the C flag is set equal to Value’s original bit 0. The result is written to
Value unless the NR effect is specified.

-taken from prop manual

specifically this bit:

the lower [b](32 - Bits)[/b] of Value’s LSB

you are reversing the lower 32 - 10 = 22 bits.
replace #10 with #22 to reverse the lower 10 bits(0 to 1023)

Hope this helps.
Lee.

Ale

You are right. I had the idea that it had to reverse the indicated bits, besides I read the documentation AND I implemented it in the simulator (and made it work as I thought I had to work...). I got more confusing because the Spin operator operates differently.

Well, thanks again !

Cluso99

It may be easier to think of the REV instruction as the Destination's upper bits (no of bits equals the Source) are cleared, and the remaining lower bits are reversed.

·· REV data,#upper· ' #upper is the number of upper bits to clear, and reverse the lower remainder bits

lonesock

I imagine the implementation is something like:

Shift left by x
Reverse the entire 32-bit number

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

Mike Green

It's probably more like the opposite: Reverse all 32 bits, Shift that right by x.
The shifter in the Propeller is what's called a "barrel shifter" which does everything
all at once in one clock cycle. Every bit has all the logic to compute all possibilities for
shifts and shift counts.

rokicki

Yeah, rev threw me off initially too; it does not do what I thought it might, but something quite different.

I'm sure there's a good reason for clearing those upper bits. But it kills reversibility, and it makes it more
difficult to use rev to do some bit permutations.

(Indeed, it's a fun puzzle to consider using a variant of rev that *preserves* the upper bits to perform
arbitrary bit permutations; what permutations are the hardest (require the greatest number of
instructions) to obtain? This is known as the "pancake problem" and it was the subject of one of
Al Zimmermann's programming contests. By the way, there is one of the contests going on now on
recmath.org; they are usually a blast to participate in.)