Quote from: Runer112 on January 05, 2011, 06:42:20 pm

Faster buffer inversion routine. 9951 cycles saved.

It's over 9000!!!!
What?!?
9000?
  Yea, I know... I had to...
But seriously dude, all those optimizations are awesome! 

Lol I just actually noticed that

Quigibo, you could probably optimize const->{expr} statements to give a lot of optimization benefits:
;const->{expr}
;Evaluate expr here
ld (hl),const

;const->{expr}r
;Evaluate expr here
ld (hl),const & $FF
inc hl
ld (hl),const >> 8

;const->{expr}rr
;Evaluate expr here
ld (hl),const >> 8
inc hl
ld (hl),const & $FF
These optimizations would still be compatible with code in earlier Axe versions because HL ends up exactly as it used to.

Edit:
These extra optimizations are also possible for storing 0:
;0->{expr}r or 0->{expr}rr
;Evaluate expr here
xor a
ld (hl),a
inc hl
ld (hl),a

So would changing this make the new nibble routines opposite the ones found in .4.6? (or the same?)

Could this possibly be auto-optimized:

pxl-Test(CONST1,CONST2)

to

{CONST2*12+(CONST1/8)+L6}^re(CONST1^8) (except ofc the math is all precalculated during parsing time.)? It saves more than 10 bytes and 200 cycles.

Yay, double post! But it's been almost a day and I have a pretty good question/suggestion. This relates to the screen display commands. This was brought to mind when squidgetx made a post mentioning something I had discovered a while ago when documenting the speed of Axe commands. What he mentioned is that DispGraph^r actually runs faster than DispGraph. Here's a quote of my response to that:

I see you've been reading up on my Commands documentation, eh squidgetx? Yeah, that's an interesting thing I discovered when speed testing the display commands. On calculators like mine with the old, "good" screen drivers, the screen driver delay seems to be pretty low and constant from calculator to calculator. DispGraph could run just as fast or faster than DispGraph^r on these calculators. However, due to inconsistencies with the screen drivers in newer units, the routine may run too fast for the driver on some calculators, causing display problems, so Quigibo had to add a portion of code to pause the routine until the driver says it is ready. However, this pause itself adds some overhead time, making the routine slower.

Quigibo, the DispGraph^r routine doesn't have any throttling system in place, yet no problems have been reported with it on newer calculators. Could you just remove the throttling system from the DispGraph routine and add one or two time-wasting instructions to make each loop iteration take as many cycles as each DispGraph^r loop iteration?


EDIT: Hmm I don't know if Quigibo reads this thread and would see that, so I'm probably going to post that in a major thread he reads or send him a message about that.

The second paragraph is my suggested optimization. The 3-level grayscale routine doesn't have a throttling system, yet there have been no reports of display problems from anybody. Wouldn't this suggest that all the screen drivers can handle routines that have as much delay as this? The data copying loop in the 3-level grayscale routine takes 72 cycles per byte output, so could delays simply be added to the normal screen display routine to make its loop at least 72 cycles?

@squidgetx
I don't think pixel testing points with constant coordinates is common enough to warrant the pixel tester to treat it as a special case.  99% of the time, you're going to be using variable arguments to test pixels.  If not, the code can probably be made more efficient without a pixel test in the first place.

The second paragraph is my suggested optimization. The 3-level grayscale routine doesn't have a throttling system, yet there have been no reports of display problems from anybody. Wouldn't this suggest that all the screen drivers can handle routines that have as much delay as this? The data copying loop in the 3-level grayscale routine takes 72 cycles per byte output, so could delays simply be added to the normal screen display routine to make its loop at least 72 cycles?

Unfortunately that is not entirely true.  There has actually been at least 1 report that the 3-level routine is too fast and causes flickers once in a great while on very new hardware.  If there was a lower bound for clock cycles, I'm right on it.  Although, I could still probably take the safety stuff off the safe copy routine, still have it faster (but not too fast) and still be smaller.  I will look into that.

And I do read most of these threads, I'm just generally too busy to post, but I try to when I have small pockets of free time

I felt bad last time I optimized the constant bit-checking auto optimizations because I left about half of them out, stuck with the 8-byte plain old bit check routine. But thanks to a random revelation I had while lying in bed last night, I have come back for the forgotten ones!

Code: (Original code) [Select] p_GetBit2: .db 7 ;7 bytes, 49 cycles xor a add hl,hl add hl,hl add hl,hl ld h,a rla ld l,a p_GetBit3: .db 8 ;8 bytes, 30/29 cycles bit 4,h ld hl,0 jr z,$+3 inc l p_GetBit4: .db 8 ;8 bytes, 30/29 cycles bit 3,h ld hl,0 jr z,$+3 inc l p_GetBit5: .db 8 ;8 bytes, 30/29 cycles bit 2,h ld hl,0 jr z,$+3 inc l p_GetBit10: .db 7 ;7 bytes, 49 cycles xor a add hl,hl add hl,hl ld h,a add hl,hl ld l,h ld h,a p_GetBit11: .db 8 ;8 bytes, 30/29 cycles bit 4,l ld hl,0 jr z,$+3 inc l p_GetBit12: .db 8 ;8 bytes, 30/29 cycles bit 3,l ld hl,0 jr z,$+3 inc l p_GetBit13: .db 8 ;8 bytes, 30/29 cycles bit 2,l ld hl,0 jr z,$+3 inc l

Code: (Optimized code) [Select] p_GetBit2: .db 7 ;7 bytes, 37 cycles ld a,h set 5,h cp h sbc hl,hl inc hl p_GetBit3: .db 7 ;7 bytes, 37 cycles ld a,h set 4,h cp h sbc hl,hl inc hl p_GetBit4: .db 7 ;7 bytes, 37 cycles ld a,h set 3,h cp h sbc hl,hl inc hl p_GetBit5: .db 7 ;7 bytes, 37 cycles ld a,h set 2,h cp h sbc hl,hl inc hl p_GetBit10: .db 7 ;7 bytes, 37 cycles ld a,l set 5,l cp l sbc hl,hl inc hl p_GetBit11: .db 7 ;7 bytes, 37 cycles ld a,l set 4,l cp l sbc hl,hl inc hl p_GetBit12: .db 7 ;7 bytes, 37 cycles ld a,l set 3,l cp l sbc hl,hl inc hl p_GetBit13: .db 7 ;7 bytes, 37 cycles ld a,l set 2,l cp l sbc hl,hl inc hl