Shop OBEX P1 Docs P2 Docs Learn Events
BOTONE bug? — Parallax Forums

BOTONE bug?

SeairthSeairth Posts: 2,474
in Propeller 2 
BOTONE  d, #0 wc, wz    ' D = $0000_001F, C=1, Z=0

MOV     s, #0
BOTONE  d, s wc, wz     ' D = $0000_0002, C=0, Z=0

In the second case, I think C is being written to the result. Note, however, that I was expecting the same behavior as TOPONE for this:
TOPONE  d, #0 wc, wz    ' D = $0000_0000, C=1, Z=1

MOV     s, #0
TOPONE  d, s wc, wz     ' D = $0000_0000, C=1, Z=1

Comments

  • SeairthSeairth Posts: 2,474
    Note: this is a disconcerting bug. I was not expecting the behavior to change depending on whether using a register or immediate value. Is this a one-off issue, or do we need to be testing reg-vs-immediate for all of the other instructions as well?
  • 78rpm78rpm Posts: 264
    Seairth wrote: »
    Note: this is a disconcerting bug. I was not expecting the behavior to change depending on whether using a register or immediate value. Is this a one-off issue, or do we need to be testing reg-vs-immediate for all of the other instructions as well?

    Yes, that way a full test coverage is achieved. It may detect problems in the hardware and/or software, ie PNut encoding or other assembler/compiler
  • RaymanRayman Posts: 14,640
    Maybe you could test topone with $FFFF_FFFF and see if it gives the same as botone...
  • ozpropdevozpropdev Posts: 2,792
    The D result is only valid when C=0
  • SeairthSeairth Posts: 2,474
    ozpropdev wrote: »
    The D result is only valid when C=0

    Ok. That would account for the first version of BOTONE, but not the second one.
  • SeairthSeairth Posts: 2,474
    Huh. Now I can't reproduce the second scenario. Maybe I had a bug in my print routine. As for the unexpected $1F, I'll mark it down as "expected" (noting that "C" indicates invalid result).

    @moderators, please close and sink this thread.
  • cgraceycgracey Posts: 14,152
    There should be no difference between S registers and constants with the same value.

    I'll try your example cases out, myself.
  • ozpropdevozpropdev Posts: 2,792
    @seairth
    Are you using RET WC,WZ in your test code.
    I'm seeing an issue here that might explain your strange results.
    See your "CALL" thread.
  • cgraceycgracey Posts: 14,152
    edited 2015-10-22 17:59
    ozpropdev wrote: »
    @seairth
    Are you using RET WC,WZ in your test code.
    I'm seeing an issue here that might explain your strange results.
    See your "CALL" thread.

    I just verified that, indeed, I was storing {Z, C} into stacks and then restoring them as {C, Z}, causing them to become switched. I just fixed this in the Verilog and it will be out in the next FPGA update.

    I had switched the order of Z and C a while back, but didn't remember to update those stack input sections.
  • SeairthSeairth Posts: 2,474
    cgracey wrote: »
    ozpropdev wrote: »
    @seairth
    Are you using RET WC,WZ in your test code.
    I'm seeing an issue here that might explain your strange results.
    See your "CALL" thread.

    I just verified that, indeed, I was storing {Z, C} into stacks and then restoring them as {C, Z}, causing them to become switched. I just fixed this in the Verilog and it will be out in the next FPGA update.

    I had switched the order of Z and C a while back, but didn't remember to update those stack input sections.

    excellent!
  • ozpropdevozpropdev Posts: 2,792
    Thanks Chip!
    That explains some of the "weirdness" :)
Sign In or Register to comment.