From: luser.droog@nospicedham.gmail.com   
      
   On Monday, September 14, 2020 at 1:05:56 AM UTC-5, Alexei A. Frounze wrote:   
   > 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.   
      
   It's a custom macro syntax which targets the "from" forms R selects   
   MOD=3 (register to register) and BX is in the REG field and CX is in   
   the REG/MEM field. So, as correctly surmised below, BX is the   
   Destination and CX is the Source. So the comparison should be the   
   same as the subtraction BX-CX.   
      
   > 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   
      
   Thanks. Yep, it's that stupid overflow again lol.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)