Shop OBEX P1 Docs P2 Docs Learn Events
SUBX bug — Parallax Forums

SUBX bug

SeairthSeairth Posts: 2,474
edited 2015-10-20 02:21 in Propeller 2
Peter Jakacki wrote: »
BTW, I found a bug with SUBX too, is there one place where we can report these bugs or observations.

I found the (possibly same) bug as well. SUBX seems to be ignoring C.

Here's my test code:
dat
        org
        
        or      dirb, #$FF

        mov     t1hi, #2        ' 64-bit number: $0000000200000005
        mov     t1lo, #5
        
        mov     t2hi, #1        ' 64-bit number: $0000000100000006
        mov     t2lo, #6

        sub     t1lo, t2lo wc   ' -> $FFFFFFFF, C -> 1
        setbc   outb, #0

        subx    t1hi, t2hi      ' -> $00000001 (should be $0000000)
        cmp     t1hi, #0 wz
        setbz   outb, #1

loop    jmp #loop

t1hi    long    0
t1lo    long    0
t2hi    long    0
t2lo    long    0

GRN1 should be lighting up, since (2-(1+C)) should be zero. If you change t1hi to #1, then it lights up.

Note: ADDX seems to be fine. I have not yet tested SUBSX or ADDSX.

Edit: changed the code to explicitly test t1hi, since Z is dependent on the prior value of Z for SUBX. Bug still exists.

Comments

  • SeairthSeairth Posts: 2,474
    edited 2015-10-20 03:07
    (deleted. for those who saw the comment, I was looking at the wrong truth table.)
  • SeairthSeairth Posts: 2,474
    This looks like an assembler error. It's compiling to opcode %0001110, which is documented to be SUBS. Incidentally, the results seem to be consistent with SUBS.
  • jmgjmg Posts: 15,193
    If you build a SUBX opcode is it then ok ?
  • SeairthSeairth Posts: 2,474
    edited 2015-10-20 03:37
    jmg wrote: »
    If you build a SUBX opcode is it then ok ?

    Yes, it works for all three examples in the P1 truth table.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-10-20 03:50
    Thanks for finding that, I confirmed that all works well by hand compiling this in place of this line: 
    subx	tos1,tos1
    with this: 
    long	$F<<28+%0001101000<<18+tos1<<9+tos1

    The > operator in Tachyon uses this and I also confirmed correct operation 
    TF2$ 7FFF.FFFF 8000.0000 > . -1 ok
TF2$ 7FFF.F000 7FFF.FFFF > . 0 ok
TF2$ 7FFF.F000 8000.0000 > . -1 ok
TF2$ 30 3A > . 0 ok
TF2$ 3A 30 > . -1 ok
TF2$ 3A 3A > . 0 ok
TF2$
  • ozpropdevozpropdev Posts: 2,793
    +1 confirmation 
    		orgh	$1000
		org

asmtest		subs	adra,adrb
		subx	adra,adrb
		long	$f1a3edf7
    returns the following in my disassembler 
    Propeller 2 - Disassembler V1.0
-------------------------------
01000: 1111_0001110_000_111110110_111110111                 SUBS    ADRA,ADRB
01004: 1111_0001110_000_111110110_111110111                 SUBS    ADRA,ADRB
01008: 1111_0001101_000_111110110_111110111                 SUBX    ADRA,ADRB
  • cgraceycgracey Posts: 14,280
    Good find! I was looking through the Verilog last night and I couldn't find anything wrong. I never considered that the assembler was errant. Good idea to try the LONG approach!
  • cgraceycgracey Posts: 14,280
    There were some typos in the '386 code that makes up the P2 assembler in PNut that were causing this problem. I'm surprised the '386 assembler didn't error out.
Sign In or Register to comment.