SUBX bug

Seairth

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.

Seairth

(deleted. for those who saw the comment, I was looking at the wrong truth table.)

Seairth

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.

jmg

If you build a SUBX opcode is it then ok ?

Seairth

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 Jakacki

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$

ozpropdev

+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

cgracey

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!

cgracey

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.