Compiler Speed Trials

[britlion]

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

14 T states, and move on.

It does:

Code:

LD HL,16384 PUSH HL LD HL,00000 POP DE EX DE,HL LD (HL),E

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?)