And how would the parser decide to do that

Oops, necropost, oh well

I don't know if this approach was purposely left out, as it's 15 bytes larger than the current routine and sometimes slower. I'm referring to the square root routine. Whereas the current routine (14 bytes) takes 37n+38 T-states (linear time), where n is the result+1 (1-256), the following routine (29 bytes) takes 5n+800 T-states (near constant time), where n is the number of set bits in the result (0-8). The existing routine is faster for values that would yield results of 0-19, but this routine would be faster for values that would yield results of 20-255, which is a much broader range of the 8-bit spectrum. Also, it would be much more reliable to run at a near constant speed in programs which rely on that to run smoothly themselves. The existing routine would take only a few hundred T-states for low inputs, but would take up to OVER NINE THOUSAND T-states to calculate the square roots for the highest inputs. So it's up to you if this is something you want to use.

p_Sqrt:
.db __SqrtEnd-1-$
ld a,l
ld l,h
ld de,$0040
ld h,d
ld b,8
or a
__SqrtLoop:
sbc hl,de
jr nc,__SqrtSkip
add hl,de
__SqrtSkip:
ccf
rl d
rla
adc hl,hl
rla
adc hl,hl
djnz __SqrtLoop
ld h,0
ld l,d
ret
__SqrtEnd:

Signed greater than comparison:

Code: (Current code) [Select] p_SIntGt: .db 13 ;13 bytes, 48 T-states 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

Code: (Optimized code) [Select] p_SIntGt: .db 12 ;12 bytes, 67 T-states ld bc,$8000 add hl,bc ex de,hl add hl,bc xor a sbc hl,de ld h,a rla ld l,a

You getting all this Quigibo?

Yeah, I'm still reading all of this, even though I'm less active, I still visit just about every day   I've even been able to do a little more progress with Axe even with my busy schedule.

Runer112, are you sure that comparison is correct?  It seems like all it does is just change the high order bit before doing the subtraction.  It needs to check if the parity changed in that bit before and after the subtraction.  I actually already have plans to optimize this since I will be able to use the parity/overflow flag once I get relative jump replacement working with the axioms (so I can carry that feature over to the built-in commands).

Changing the high order bit does work, actually. It changes a comparison in the -32768 to 32767 range to a comparison in the 0 to 65535 range (effectively changing from a signed comparison to an unsigned comparison).

Yup This is the only signed comparison for which this method is better though.

Do all the bit optimizations look correct by the way?



EDIT: If you plan on optimizing the signed comparisons to use the parity/overflow flag, you might want to check into that a bit. I was playing around with signed comparisons and wabbitemu was telling me very strange things. It seemed to tell me that signed comparisons relied on an xor of the p/v and s flags. Which makes no sense, but that's what wabbitemu was telling me. See table below.

hl	de	sbc hl,de	c	p/v	s	hl>>de
2000	6000	C000	1	0	1	0
2000	A000	8000	1	1	1	1
2000	E000	4000	1	0	0	1
6000	2000	4000	0	0	0	1
6000	A000	C000	1	1	1	1
6000	E000	8000	1	1	1	1
A000	2000	8000	0	0	1	0
A000	6000	4000	0	1	0	0
A000	E000	C000	1	0	1	0
E000	2000	C000	0	0	1	0
E000	6000	8000	0	0	1	0
E000	A000	4000	0	0	0	1

It seemed to tell me that signed comparisons relied on an xor of the p/v and s flags. Which makes no sense, but that's what wabbitemu was telling me.

It actually does make a bit of sense. Whether the mathematical (non-overflowed) result of the subtraction is positive or negative should give you the result of the comparison.  However, if there was a signed overflow, it will give the wrong result. So the sign flag needs to be inverted if there was an overflow, and XOR achieves this perfectly.

Actually, the main reason he didn't use the p/v flag is because his routines didn't support absolute jumps. They apparently do now, so some speed-up using these flags might be possible.

Cool, Quigibo added all my optimized auto-optimizations But I think you missed p_GetBit15, which can be optimized to be the same as p_Mod2.

Great! So, it optimizes the Axe script or the Asm conversion?

Like, the following program:

Output(0,0,"Hello World")
Is optimized to:

Output(0,0,"Hello World
Or is it Assembly that is optimized?