Shop OBEX P1 Docs P2 Docs Learn Events
PASM abuse - R bit — Parallax Forums

PASM abuse - R bit

localrogerlocalroger Posts: 3,452
edited 2010-12-03 16:30 in Propeller 1
I am pursuing a scheme by which PASM code builds a PASM instruction to execute using clues from several sources, in a LMM-like but much more complicated way. Anyway, as we know many instructions do not use the D field to write an output (CMP, WR-BYTE/WORD/LONG, and COGSTOP, for example). In the opcode summary these instructions are shown as having the R bit set to zero.

What I am wondering is this: If I build such an instruction with the R bit set to 1, what happens? My guess would be that the instruction works but might write garbage to D. If this is the case it's acceptable for what I'm doing, but it would be helpful to know that's reliable.

Comments

  • Heater.Heater. Posts: 21,230
    edited 2010-12-03 07:51
    Isn't CMP actually the same instruction as SUB but without the R bit set ?
  • localrogerlocalroger Posts: 3,452
    edited 2010-12-03 08:26
    Yes, that's true of CMP/SUB but it's not true of for example CMPS/SUBS (the flags are set differently). What I'm wondering about are the instructions that simply don't normally return a result at all.
  • jazzedjazzed Posts: 11,803
    edited 2010-12-03 08:31
    localroger wrote: »
    What I am wondering is this: If I build such an instruction with the R bit set to 1, what happens?

    WR-BYTE/WORD/LONG becomes RD-BYTE/WORD/LONG

    Propeller data sheet v1.2 page 22:

    000000 000i 1111 ddddddddd sssssssss WRBYTE ....
    000000 001i 1111 ddddddddd sssssssss RDBYTE ....
  • ericballericball Posts: 774
    edited 2010-12-03 09:20
    This is what I can puzzle out from the manual: 
    R=0	R=1	D impact
WRxxxx	RDxxxx
CLKSET		D and 7
COGINIT		cog number
COGSTOP		D and 7
LOCKRET		D and 7
LOCKSET		D and 7
LOCKCLR		D and 7
JMP/RET	JMPRET
TEST	AND
TESTN	ANDN
CMP	SUB
CMPS		same as SUBS
CMPSX		same as SUBSX
CMPX	SUBX
TJNZ		no change
TJZ		no change
WAITPEQ		?
WAITPNE		?
WANTVID		?
    WAITPEQ & WAITVID look like ADDs, but WAITPNE isn't.
  • localrogerlocalroger Posts: 3,452
    edited 2010-12-03 11:48
    Yes, I'm aware of how RD/WR* use R and how HUBOP uses S. WAITPEQ is a perfect example of what I'm talking about, though. Its INSTR code is %111100. The manual specifies R=0. There is no other instruction with INSTR %111100, so what happens if you execute it with R=1? I am suspecting that it will write garbage to whatever long of Cog RAM is being pointed at by the D field, but it would be kind of nice to know for sure.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-12-03 11:57
    In the case of waitpne, it would be nice if it assigned to D the result of ina & S. That way, one could have a continuously updated compare value for further changes.

    As a side note, it's curious that Chip chose to use the carry flag to select inb for waitpeq and waitpne, rather than the R bit, which is part of the instruction proper.

    -Phil
  • jazzedjazzed Posts: 11,803
    edited 2010-12-03 12:27
    localroger wrote: »
    Yes, I'm aware of how RD/WR* use R ....
    Sorry, but your first post did not communicate that very well at all.
  • stevenmess2004stevenmess2004 Posts: 1,102
    edited 2010-12-03 12:40
    Rayman has something about some of the wait instructions and flags hurried somewhere on his website. Don't know if it is relevant or not.
  • Mike GreenMike Green Posts: 23,101
    edited 2010-12-03 12:56
    Phil,
    The C flag is directly computable while, if the R bit is used to select INB, it's not directly computable. An instruction has to be constructed and executed and some of this code may reside in ROM, not hard to do, but more complex than setting C. Remember that there was a 64 pin Prop 1 planned when the current Prop 1 was designed.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-12-03 13:08
    Mike,

    Understood. But there's no reason that one couldn't use two separate instructions for ina and inb. To me it seems unlikely that the choice of which port to monitor would ever be a parametric one. But if it were, once could simply jump to whichever wait instruction was needed. It's so often necessary to maintain state info in the flags, that dedicating one of the two available as an instruction word expansion trick seems like a huge sacrifice -- especially when it's unnecessary.

    -Phil
  • Cluso99Cluso99 Posts: 18,069
    edited 2010-12-03 15:18
    kuroneko is the specialist with the waitxxx and similar instructions. If he doesn't know the answer yet, stay tuned :)
  • localrogerlocalroger Posts: 3,452
    edited 2010-12-03 15:24
    Sorry Jazzed, I thought it was obvious I was asking about undocumented behavior. In the case of RD/WR* when you set R, you get the RD instruction which generates an output in PASM, which is actually consistent and pretty obvious from the opcode listing.
  • kuronekokuroneko Posts: 3,623
    edited 2010-12-03 16:30
    waitpxx and waitvid are related to waitcnt in that they [post=864343]inherit the primary add function[/post]. While waitvid and waitpeq perform D += S, waitpne conveniently does D += (S+1) for which I finally found a requirement/use in my [post=784536]serial driver[/post] :)
Sign In or Register to comment.