Shop OBEX P1 Docs P2 Docs Learn Events
This ol' REV just ain't what it used to be.... what else ain't what it used to be? — Parallax Forums

This ol' REV just ain't what it used to be.... what else ain't what it used to be?

Peter JakackiPeter Jakacki Posts: 10,193
edited 2015-10-20 03:56 in Propeller 2
I was a little surprised to find what I thought was a bug with the REV instruction as I expected to work just like the old one. Turns out that this one is "crippled" in that it simply reverses all the bits from the source into the destination. I can't see why we couldn't have it work the way it used to work but are there any other "surprises" out there in P2ville?

Comments

  • rjo__rjo__ Posts: 2,114
    Short answer: no, I think that is about it.

    LONG answer: Because that's the way Chip wants it. Now, get back to work:)
  • Peter JakackiPeter Jakacki Posts: 10,193
    That "bug" threw me off when I was writing some quick Forth code to talk to the serial Flash chip as I would normally to a #24 REV to get the bits in the right order to do a simple test bit 0 and right shift operation for an msb first serial stream. Sure, there are other ways around it but I'm still scratching my head as to the rationale behind this change to REV.
  • Cluso99Cluso99 Posts: 18,069
    Iirc the rotations via C now set the chit as expected, not according to bit 0 or 31 of the source.
  • evanhevanh Posts: 15,915
    I think the big bonus with this version of REV is it copies the data at the same time.
  • Peter JakackiPeter Jakacki Posts: 10,193
    evanh wrote: »
    I think the big bonus with this version of REV is it copies the data at the same time.

    Huh? (as in "bonus")
    The problem is that REVision B does not replace REVision A, it should have been a new instruction in addition to the old.
  • SeairthSeairth Posts: 2,474 
    mov     d, s            ' copy S into D
rev     d, #(32-6)      ' reverse bits of 6 LSBs and zero out the rest

    vs
    rev     d, s            ' reverse S into D
shr     d, #(32-6)      ' shift 6 MSBs to LSBs

    Other than the confusion with the P1 version, I think the P2 version makes more sense. It now does precisely what the mnemonic implies. And I think the P2 code is more clear as to intent.
  • Peter JakackiPeter Jakacki Posts: 10,193
    Seairth wrote: »
    Other than the confusion with the P1 version, I think the P2 version makes more sense. It now does precisely what the mnemonic implies. And I think the P2 code is more clear as to intent.

    Well that is a matter of viewpoint I think because I noticed that you copied your source into the destination before the REV in the P1 version but that is not how I have ever done it so it really was a single operation before and now I need two instructions in the new improved P2 to do what I did in one in the old "inferior" P1.
  • RaymanRayman Posts: 14,640
    I always found the P1 REV non-intuitive...
    New version is better, if we were starting over.

    But, I've become a fan of making it easier to port from P1 to P2.
    So, I guess I'm on the fence for this one...
  • jmgjmg Posts: 15,173
    Seairth wrote: »
    mov     d, s            ' copy S into D
rev     d, #(32-6)      ' reverse bits of 6 LSBs and zero out the rest

    vs
    rev     d, s            ' reverse S into D
shr     d, #(32-6)      ' shift 6 MSBs to LSBs

    Other than the confusion with the P1 version, I think the P2 version makes more sense. It now does precisely what the mnemonic implies. And I think the P2 code is more clear as to intent.

    It does look like 2 opcodes, and the P2 variant is likely smaller and faster, so that may be part of the reason for the change.

    Maybe it needs a new name ?
    A P1-version could be synthesized in the assembler, if there is not silicon room.

  • potatoheadpotatohead Posts: 10,261
    Well trouble is P1 will continue to exist and see active use. It does some things well that P2 does not, like low power, PLL, etc...

    I'm inclined to say we modify the P2 name, and leave it at that, perhaps including a P1 compatable snippet in the docs.

    REVSD for the new one?

  • cgraceycgracey Posts: 14,152
    The barrel shifter was the critical path of the ALU. By removing REV from it, it got a lot faster.
  • Peter JakackiPeter Jakacki Posts: 10,193
    A two instruction P1 style REV is not a bother if this makes the whole ALU path "a lot faster". The problem was with the name plus lack of documentation on these changes. Thanks Chip.
  • ozpropdevozpropdev Posts: 2,792
    cgracey wrote: »
    The barrel shifter was the critical path of the ALU. By removing REV from it, it got a lot faster.
    This seems to correlate with P1V when its clock speed are pushed to 120+ MHz.
    Depending on the FPGA version (IV,V or Max10) it looks like the barrel shifter is the first thing to go erratic.


  • SeairthSeairth Posts: 2,474
    Peter,

    In case you missed it in the other threads, I have started a couple tables/grids to document the differences between P1/P2 (from the perspective of moving from P1 to P2). It's in your GDoc:

    https://docs.google.com/document/d/1O27nO2tMjBTvUNblFFRtEp5DHvcvsSGXcPvH9FaJ9u8/edit#bookmark=id.n1suwwbjxuk4
  • Peter JakackiPeter Jakacki Posts: 10,193
    See that there, nice job. In fact thanks for all your hard work and input, both with testing and with the document.
  • cgraceycgracey Posts: 14,152
    Wow! Good job!
Sign In or Register to comment.