This relates to the underlying z80 machine code (or ASM, if you prefer) that Axe generates.

I would love to help with optimization, I can help with virtually everything except messing with archive, writing apps, and advanced sprite routines.

Other than that, I can help with everything else.

Some constant equality checking optimizations. Feel free to extrapolate these optimizations to values that previously weren't optimized because the code would have been too large.

Code: (Current code) [Select] p_EQN256: .db 9 inc h ld a,l or h jr z,$+5 ld hl,255 inc l p_EQN2: .db 10 inc hl inc hl ld a,l or h jr z,$+5 ld hl,255 inc l p_EQN1: .db 9 inc hl ld a,l or h jr z,$+5 ld hl,255 inc l p_EQ0: .db 8 ld a,l or h jr z,$+5 ld hl,255 inc l p_EQ256: .db 9 dec h ld a,l or h jr z,$+5 ld hl,255 inc l

Code: (Optimized code) [Select] p_EQN256: .db 8 inc h ld a,l or h add 255 sbc hl,hl inc hl p_EQN2: .db 8 inc l ld a,l and h sub 255 sbc hl,hl inc hl p_EQN1: .db 7 ld a,l and h sub 255 sbc hl,hl inc hl p_EQ0: .db 7 ld a,l or h add 255 sbc hl,hl inc hl p_EQ256: .db 8 dec h ld a,l or h add 255 sbc hl,hl inc hl

Also, p_Div32768 can be optimized to be the same as p_SLT0 and p_GetBit0.

will this increase speed, decrease size or both?

Concerning optimizations:

I used an Assembly Disassembler to disassemble my game uPong and the code was 1531 lines! It was huge. Hopefully, thanks to Runner's and other members' optimizations, Axe programs can get smaller and smaller

The more assembly instructions available, the more you could optimize programs. But I don't want Axe to just turn into an assembly compiler with a 16-bit math engine and some other pre-built structures on the side. If you want that, you probably know assembly anyways and could just write your program in assembly and grab some of Axe's routines.

However, three instructions that I believe would complement Axe very well without defeating the purpose of its hl-based system are the ex de,hl, push hl, and pop hl instructions.

Quigibo had toyed with the idea of implementing the ex de,hl instruction before, allowing it to be called with either →π or π. They would do the same thing, but it would be a more familiar syntax for programmers used to a variable system in which storing and recalling values are different instructions. And/or he could implement the instruction as the Exch() command with no arguments.

Although there would definitely need to be a warning to only use push and pop if you know how stacks work and know what you're doing, those would be pretty helpful I think. Maybe push hl could be StoreGDB and pop hl could be RecallGDB .


In case Quigibo is reading this, any chance of these happening?

I don't think push and pop are that good of an idea because of the stack thing.  And all of those are only 2 hex characters of the Asm() command anyway.  The exchange I am still thinking about, I'm trying to see how practical it would be and how many commands are actually safe to use and I could change some commands to use bc instead.

Thanks again for the optimizations of the equalities, those are very widely used in programs so its great to see those optimized.  I extended your optimizations to equality comparisons against variables too which actually reduces the number of auto-optimizations I need to do since the general cases are smaller.

very true, I personally love the stack most among most other things, that's one thing I always loved about raw assembly programming.

Then, Axe can appeal to just about everybody