I've been waiting for you to show up in IRC since Friday so I could give you this routine, but since I haven't seen you yet there, here it is! It returns strings like the OS would when displaying numbers on the home screen with the Float setting. It perfectly mimics the OS routine for every reasonable input I've tried, even when using hacked float variables that have exponents above 99. The only thing it doesn't perfectly mimic is hacked floats that contain invalid hexadecimal characters. But that shouldn't happen too often.

Anyway, you said you wanted this for speed. Good news! The OS routine appears to take an average of about 5500 cycles in my tests, whereas my routine takes an average of about 1600 cycles. It'll cost you 244 bytes, but the choice is yours.

And anyone besides Hot_Dog, feel free to grab this routine as well. Note though, that because I made this routine to Hot_Dog's specifications, it has a few weird quirks. The location of the string returned has to be a constant, but you can change that. Right now it's set to OP4. You'll also probably want to get rid of the ld (hl),20 \ inc l at the start of the routine, another weird quirk Hot_Dog said he needed. Also, note that the string returned is a null-terminated string of tokens, not characters. You should be able to change this though by simply changing all the token values in the routine to ASCII values.

Quote from: Runer112 on April 09, 2011, 08:59:14 pm

I would suggest changing the token replacement to Block(). Feeding 1 argument would create a block of the specified size filled with zeroes. Feeding 2 arguments would create a block of the specified size filled with a specified value.

I like that idea. It would make it compatible with previous versions.

That's the idea.

Could you add an option to the options menu for expert users that would turn off the scope checking? Because I can definitely think of times when I wanted to be able to push/pop across multiple lines for extreme optimizations.


EDIT: Also Quigibo, do you want to put up that poll that you had proposed earlier about the GetCalc() functions?

If you're only moving a few bytes, it's best to just move them with individual load/store commands, like:

{L₃}ʳ→X

The reason that's giving you an error, though, is because the degree modifier needs to precede variables.

For that matter, a lot of things could still use optimized immediate value versions. Pretty much every comparison could, as well as a few other operators. For instance, p_BoolOrImm, p_BoolAndImm, and p_BoolXorImm have been sitting in Commands.inc since Axe 0.4.7 and I would love to see them implemented. Constant bit setting and resetting would also be awesome. Unfortunately none of these things can be achieved with an Axiom, or I would be all over this.

I don't notice any speed difference at all. Holding down an arrow key for 2 seconds and then letting go, the sprite moved the exact same number of pixels in both grayscale modes.

And I'm not entirely sure how a general overclocking discussion would be pertinent to the Axe Bug Reports thread.

I assure you that the speed of the Pt-Change() routine, as well as every other Axe routine, is affected only by itself and the arguments passed to it. The simple presence of other routines in your code will not affect the routine.

Also, because I don't really think rapid-fire clock-changing is conducive to a long and happy CPU life, could it be possible to, while compiling, keep track of what speed the clock is set at and change the routine used accordingly?

Changing the clock speed doesn't harm the CPU.