I would suggest a 2nd version within the folder Developers Tools.
That way some noob won't just find it on his calc.

These will decrease size, but also slightly decrease speed. I believe that Quigibo prefers smaller sizes over slightly slower code.

I think it depends, though. If the slight speed decrease is 0.01 FPS to 0.02 it may not sound like much if executed once but if someone uses something 20 times a loop he will see the difference. Otherwise I think he definitively optimizes for size.

Wouldn't it make the compiler super large, though? :O

The problem with a compile setting for size/speed is that generally, you want part of your code to be optimized for size and another part to be optimized for speed.  This could be done with "speed-op" and "size-op" commands or perhaps a prefix for labels like "Lbl +LBL" indicates everything until the next label is optimized for speed and everything else by default is optimized for size.  Any shared subroutines like multiplication are added in the second pass so if multiplication was flagged to be fast in one place, it would be fast everywhere else too since it has to add the huge routine to your code anyway, all the other calls should share it.

It would make the parser a lot bigger, but it has room.  I'm almost full on the first page, but I still have about 10KB of extra room on the second page.  Commands are data in the Axe app so they would go on that page anyway.

Yeah, I don't remember when that was, but it optimizes better that way.  When storing stuff to a constant pointer, it returns the stuff you stored.  If storing to a variable pointer, it returns the pointer itself, or the pointer plus 1 if you're storing 2 bytes at a time.

You guys won't believe this, but I found an optimization to the general multiplication. 

Code: [Select] ;#####  OLD  ##### p_Mul: ld b,h ld c,l ld hl,0 ld a,16 __MulNext: add hl,hl rl e rl d jr nc,__MulSkip add hl,bc jr nc,__MulSkip inc de __MulSkip: dec a jr nz,__MulNext ret

Code: [Select] ;######  NEW  ###### p_Mul: ld c,h ld a,l ld hl,0 ld b,16 __MulNext: add hl,hl rla rl c jr nc,__MulSkip add hl,de adc a,0 jr nc,__MulSkip inc c __MulSkip: djnz __MulNext ret

Its a small optimization, its the same size as the original but it saves an average of 4 clock cycles per bit of the multiplication.  Since its a 16 bit multiplication, that's an average of 64 clock cycles (11 micro-seconds) and about a 6% increase in speed.  So its not that big of a deal, I was just really shocked I was able to optimize it.

That is actually an amazing increase in speed. Very nice!

It doesn't look like the optimized p_EQN2 and p_EQN1 routines that I suggested made it into Axe 0.4.7. Did you maybe forget to add them? Or were my routines incorrect?

Also, I think you might have overlooked my footnote in the first equality optimization post mentioning that p_Div32768 can be optimized to be the same as p_SLT0 and p_GetBit0.



EDIT: Also, it doesn't look like p_EQNX and p_NENX are being used by the parser. Is this just an accident, or did you intentionally leave them out for now due to the problem of the constant in the source code not equaling the constant that should be inserted?

And along the lines of comparing negative shorts, if you get p_NENX working, it should be the same size and faster for -3 than p_NEN3, so the latter should be removed. And for p_NEN2, can't the first instruction just be inc l instead of inc hl?


EDIT 2: I think I've mentioned this in the past as well, but it looks like you must've missed seeing it/adding it. p_GetBit15 could be optimized to be the same as p_Mod2.


EDIT 3: (Man this is going to be one long post) It was smart of you to make the greater than, greater or equal, less than, and less or equal comparisons with second arguments that are expressions call the opposite routine after popping the first argument into de, thus avoiding any double ex de,hl's. Could something like this also be used for the greater than and less or equal comparisons with the second argument being a variable? A byte could be saved by making these insances use ex de,hl / ld hl,($0000) to load the variable instead of ld de,($0000) and then call the opposite routine.

EDIT 4: Going along the lines of edit 3, p_SIntGt and p_SIntLe could be optimized for variable arguments in the same way. Although no bytes would be saved calling p_SIntLt instead of p_SIntGt, cycles would be.