From: alexfrunews@nospicedham.gmail.com   
      
   On Sunday, September 13, 2020 at 9:20:43 PM UTC-7, luserdroog wrote:   
   > I'm trying to fill out my toy forth interpreter and I think I have   
   > a bug in my emulator for the CMP instruction and therefore probably   
   > also SUB and SBB.   
   >   
   > The problem is showing up in my comparator functions   
   > CODE(<,     less,      POP(CX),POP(BX), MOVAXI(0xff,0xff), CMP(,R,BX,CX),   
   JL,2,INC_(R,AX), PUSH(AX))   
   > CODE(>,     more,      POP(CX),POP(BX), MOVAXI(0xff,0xff), CMP(,R,BX,CX),   
   JG,2,INC_(R,AX), PUSH(AX))   
   >   
   > When I test it with   
   >   
   > WORD(test2a,test2a,    enter, one, ten, less, dot,   
   >                               one, ten, more, dot, ok)   
   >   
   > no matter how I permute the arguments -- changing BX and CX in the CMP   
   > instruction, or in the POP order, or in the test script -- the results   
   > never change.   
   >   
   >   0 -1 OK   
   >   
   > Here's the stack trace on the first one.   
   >   
   > ax:ffff cx:000a dx:0000 bx:0001 sp:f000 bp:1ffc si:0e1a di:0000 ip:046d   
   fl:0004 NC NO NS NZ   
   > 3b(073) cmpwt: d9(331) x:1 y:10 ->fffffff7   
   > ax:ffff cx:000a dx:0000 bx:0001 sp:f000 bp:1ffc si:0e1a di:0000 ip:046f   
   fl:0891 CA OV SN NZ   
   > 7c(174) jl: 02(002) <0>   
   > ax:ffff cx:000a dx:0000 bx:0001 sp:f000 bp:1ffc si:0e1a di:0000 ip:0471   
   fl:0891 CA OV SN NZ   
   > ff(377) grp2w: c0(300) INC ->0000   
   >   
   > The CMP produces fffffff7 which seems like the correct subtraction   
   > extended to 32 bits. But the JL isn't taken.   
   >   
   > Are my flags wrong after the cmpwt instruction?   
      
   If you have to ask, it's quite possible.   
   Care to show your code for add/adc, sub/sbb/cmp?   
      
   I don't know why you're sign-extending 16-bit values   
   to 32 bits when performing a 16-bit operation.   
   It may contribute to the problem by itself.   
      
   Before you ask a question like this you should explain   
   your syntax a little bit. For example, in   
      
     CMP(,R,BX,CX)   
      
   I don't know if the operand order is the same as in the   
   intel/AMD x86 manual or the opposite like in the AT&T   
   assembly syntax.   
      
   Supposing the order is like in the intel syntax and you're doing:   
      
     CMP BX, CX   
      
   when BX=1 and CX=0xA, you should get:   
      
     difference = 0xFFF7 (unsigned) or -9 (signed), not stored anywhere   
      
     FLAGS.SF=1 (most significant (AKA sign) bit of the above difference)   
      
     FLAGS.ZF=0 (the above difference isn't 0)   
      
     FLAGS.CF=1 (in unsigned comparison 1 < 0xA holds true)   
      
     FLAGS.OF=0 (mathematical difference: 1 - 0xA = -9, correctly represented)   
      
   JL will jump when SF!=OF. This should be the case here.   
      
   It's very likely that your signed overflow computation is busted.   
   This may help: https://stackoverflow.com/a/8037485/968261   
      
   Alex   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)