Thanks for pointing that out!  Actually, I've already fixed that in the next version.  I've been spending most of this entire week just going through all the math routines and making them more efficent both on the parser side and the code generation.  Also, there were a lot more bugs than I thought (like this one).  I've fixed at least 5 different bugs already, mostly on the parsing side, and it seems to be running much smoother.  I'll be updating in a few hours probobly.

That's a good idea to do seperate high and low comparisons, I'll see if it reduces the size.

Well, I couldn't find a way to do it with high and low comparisons separately.  Here is what I'm using now.  I might be able to optimize it using the parity flag, but I'm avoiding absolute jumps at the moment.

p_SIntGt:
ex de,hl
xor a
ld b,h
sbc hl,de
ld h,a
rra
xor b
xor d
rlca
and 1
ld l,a
p_SIntGe:
xor a
ld b,h
sbc hl,de
ld h,a
rra
xor b
xor d
rlca
sbc a,a
inc a
ld l,a
p_SIntLt:
xor a
ld b,h
sbc hl,de
ld h,a
rra
xor b
xor d
rlca
and 1
ld l,a
p_SIntLe:
ex de,hl
xor a
ld b,h
sbc hl,de
ld h,a
rra
xor b
xor d
rlca
sbc a,a
inc a
ld l,a
BuckeyeDude, do you have a routine smaller than this?  These are 12 and 13 bytes depending on if they need the exchange.

The signed comparison result needs to be an XOR of the V and S flags (since if there was an overflow, you have the wrong sign)