britlion Wrote:That would explain it.
Zip2 (and Zip1.5 as originally testing post 1) does seem to be quite a lot tighter, finishing BM7 in .46 seconds. (23 frames); as I noted, however. the downside is this is an integer only compiler - but it proves there's a much shorter solution to the integer code compile.
Demo: https://dl.dropboxusercontent.com/u/4903...erTest.z80
And even that fast result has code that a clever compiler could tighten.
E.g. poke 16384,255
Could be
Code:
LD a,255
LD (16384),A
It does:
Code:
LD HL,16384
PUSH HL
LD HL,00000
POP DE
EX DE,HL
LD (HL),E
I can't testing it now, but if ZXBASIC zxbasic is producing such code, then it's mostly a bug. POKE should be a direct LD whenever possible. :?: :?: :?:
britlion Wrote:Which is pretty generic code for the simplest case of set a memory address, but 51 T states. It can make sense if the numbers are calculated - but it does treat all numbers as 16 bit, and just masks to 8 bit where necessary. I can't quite blame it for this - it has to fit inside the zx spectrum, with the basic and also with the compiled result. Space is tight there!
Here's
Code:
LET V=INT(k/2)*3+4-5
Code:
LD HL,(54864) ; Fetch variable k
SRA H
RR L ; Divide
PUSH HL ;save
ADD HL,HL
POP DE
ADD HL,DE ; multiply by 3
INC HL
INC HL
INC HL
INC HL ; Add 4
DEC HL
DEC HL
DEC HL
DEC HL
DEC HL ; Subtract 5
LD (54952),HL ; Store back into v
Aaaagh. Starts well. Goes a bit strange. I think you'd at least optimise +4-5 into -1, and save some hassle. (Though it's bad programming to put +4 - 5 to be fair) I wonder when it stops doing INC and DEC? What if that was -200? or -5000? 
(Simon Goodwin probably says inc is faster for small numbers, and "small" is apparently at least 5)
So I think a /really/ smart compiler, should be faster than this. 
(Easy for me to say, isn't it?)
Hmm. This can also be introduced in ZX BASIC with -O3. Let's try...
