Part III: "HL is the Ans of Axe" -Runer112

My favorite optimization trick of all time

graphmastur, I think your expectations of Quigibo and Axe are just a little high... Even the most knowledgeable assembly programmers steer clear of the USB port because very few people know how to use it. I think it's a little too much to ask Quigibo to write arbitrary USB protocols for a system that hardly anyone has even been able to hack together any USB functionality. And the same goes for coding operating systems. The first person to design a programming language that allows users to easily write full operating systems deserves a Nobel prize (or whatever the equivalent is for computer science). Anyways, Axe was built to be a programming language to write programs for the TI operating system. It is in many ways inseparable from the TI operating system, and would instantly fail without it.

The computer compiler, on the other hand, Quigibo already plans to work on. That's what Axe 2.0 will be.

EDIT: Damn it, double ninja'd.

Unless calc84maniac wants to step in here, I'd be happy to test the axiom capabilities with my raycaster (it's not the Axe one, I wrote a whole new one in pure assembly). I also have a bunch of 32-byte math routines I was just waiting to test!

What saves more, this opt or the inData() trick? (assuming that the inData() routine already exists...and that there is only 1 comparison...iirc inData() with 1 comparison is like 12 or 13 bytes)

Also, nice game Fast Crash

I think I made a post about this a while ago...

Ah yes, I did! Here it is. You have to remember that inData() only works with bytes though, not with words like normal equality checks.

That's a nice idea Builderboy, but unfortunately users have to choose to optimize their own code in cases like this. This is because, although If A=B and !If A-B would form identical control structures, they would not return the same values. And the programmer may want to use the value returned. For instance, the following code would no longer work as the programmer planned if this auto-optimization existed:

If A=5
  →B
  .Do stuff
Else
  .Do stuff
End


Runner, that would make the routines a lot larger and I don't think it would be as used often enough to justify the extra size.

I don't know how small you managed to make the current routine, but mow much larger could this make it? The following routine I whipped up would take input in hl, convert into a null-terminated string of hexadecimal characters starting at vx_Hex, and return a pointer to that string. It's only 29 bytes. To display a string you would just call this and then treat the result like any normal string. But you now have the extra advantage of being able to access the generated hex characters.

p_ConvHex:
ex de,hl
ld hl,vx_Hex+4
xor a
ld (hl),a
call __ConvHexByte
ld e,d
__ConvHexByte:
ld a,e
call __ConvHexNib
ld a,e
rra
rra
rra
rra
__ConvHexNib:
or $F0
daa
add a,$A0
adc a,$40
dec hl
ld (hl),a
ret


The "hidden buffer" is MD5Buffer, a 64-byte section of RAM starting at $83A5. I wonder what immediately follows it in RAM, because if there were only a few more byte of safe to use RAM, you could move all the variables there.

Keeping in mind what calcdude84se pointed out about A and B, if either A or B will sometimes be non-boolean values (anything besides 0 and 1), you want to use the two separate if statements. If they will always be booleans, however, compare the following two blocks of code:

If A
  If B
    Do stuff
  End
End


• A is false: 34 t-states
• A is true: 68 t-states

If A and B
  Do stuff
End


• 66 t-states

The second one is only faster if A will be true at least 16/17 of the time.