Assembly Programmers - Help Axe Optimize!

[calc84maniac]

And if you ever want a signed high multiplication, I think this routine would work along with that one:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14

p_MulFullSigned: .db __MulFullSignedEnd-1-$ push hl call $3F00+sub_MulFull pop bc xor a bit 7,b jr z,$+4 sbc hl,de or d ret p sbc hl,bc ret __MulFullSignedEnd:

Edit: more optimized

[squidgetx]

Optimizing constant address calls?
Anyway, 5->^oVAR : (^oVAR)() compiles to

Code: Select All | Copy To Clipboard

1 2 3 4

ld hl, 5 push hl call $9D9D

when it could just compile to

Code: Select All | Copy To Clipboard

1 2	call $0005

Right now the only way to call an address that's not a label is using asm(CDXXXX), and that way makes assigning r1-r6 arguments extremely annoying (manual store)

[Xeda112358]

I am not sure if I had an outdated source (1.1.2) but I saw this code and a one -byte optimisation:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

p_NthStr: .db __NthStrEnd-$+1 pop bc pop de push bc ex de,hl __NthStrLoop: ld a,d or e ret z xor a ld b,h cpir dec de jr __NthStrLoop __NthStrEnd:

It took me a second to figure out what you were doing with 'ld b,h', but when I did, I saw that you could just move it outside the loop to save 4 t-states each loop. But then I realised that BC is already large enough since it holds the return address, so you can actually just remove it altogether.

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

p_NthStr: .db __NthStrEnd-$+1 pop bc pop de push bc ex de,hl __NthStrLoop: ld a,d or e ret z xor a cpir dec de jr __NthStrLoop __NthStrEnd:

I hope that actually works!

[calc84maniac]

I'm not so sure that would work, because there's a possible case where you could be running code from an app and finding the Nth string in a large appvar in RAM, for example (which could be more than 16KB in size).

[Runer112]

I am not sure if I had an outdated source (1.1.2) but I saw this code and a one -byte optimisation

You do have an outdated version of Axe, I already added that optimizaion in 1.2.0.

I'm not so sure that would work, because there's a possible case where you could be running code from an app and finding the Nth string in a large appvar in RAM, for example (which could be more than 16KB in size).

Pfft what are the chances of that...

[Xeda112358]

You do have an outdated version of Axe, I already added that optimizaion in 1.2.0.

Darn, I actually do have 1.2.1 in a different folder, I completely forgot about that .__. I am glad that I got something right, though

I'm not so sure that would work, because there's a possible case where you could be running code from an app and finding the Nth string in a large appvar in RAM, for example (which could be more than 16KB in size).

I was worried about that, but I figured that it would be pretty rare. It would definitely be the only scenario that it would fail, too. .__.

[Deep Thought]

Don't know if it's been mentioned before (and maybe there's a reason it's this way), but p_SendByte starts by loading B and C individually where p_GetByte loads them together (saving a byte).

[Runer112]

No reason whatsoever. Good catch.