I'll think about it.  I'm not sure how often square roots are actually needed and how applicable they are to speed constraints.

Another thing, I'm adding new auto-opts for constants in the comparisons (less than, less than or equal to, greater than, and greater than or equal to).  I have found nice optimizations for powers of 2 and some low numbers, but if anyone wants to try writing some, I could definitely use them.  I probably missed some or may have sub-optimal solutions.

Also I edited the top page poll, because it was left without an edit for far too long.

Hehe, I can take a hint  Added a meaningful poll.

I was thinking of adding ++ as an operator for single byte variables because it could lead to a huge optimization there (but not to the 16-bit variables).  So A++ would translate to:
ld  hl,axv_A
inc (hl)

Which is NOT the same as A+1->A.  This is because here A represents the Axe "A" variable as just a single 8-bit byte and so 1++ becomes 2, but 255++ becomes 0 again.  And similarly, {B+L1}-- becomes:
ld  hl,(axv_B)
ld  de,axr_L1
add hl,de
dec (hl)


I'm personally not for an "Axe Only" competition this summer.  It was nice last time because it was new and unique and gave it an establishing kick into the community.  But instead, I would like to see an ASM category for the next competition which would include axe programs.  I think because development speed for Axe programs is significantly faster than ASM, most entries in such a contest would probably still be Axe programs.  And if Axioms are used the way I'm hoping, then the pure ASM programs would have very little advantage in any game development competition.  This also gets rid of any notion of cheating from using certain Axe commands.

I'm not trying to discourage any plans DJ might already have though, this is just my opinion.

You do realize there was a new command added in 0.5.1 to compare string equality right ?  Equ>String(Str1,Str2) 

In the future, after 1.0.0 is released, I though of an idea of how I could bring Axe to the computer platform officially.

Instead of emulating Axe at the assembly level, I could write a compiler instead that takes z80 source code and converts it to C code or whatever language, compile that, add some fancy GUI stuff and an editor, and poof!  Done.

Low to high level language compilers are easy and don't have to be very efficient.  There is a very limited number of assembly instructions anyway and the actual z80 source only needs to be modified slightly for the different input output standards I would need.

This reminds me, would the new stack commands conflict with operations that implicitly use the stack? For example, A->π B-(π+C) would in theory compile to something like:

Code: [Select]

ld hl,(axv_A)
push hl
ld hl,(axv_B)
push hl
pop hl
ld de,(axv_C)
add hl,de
pop de
ex de,hl
or a
sbc hl,de
Long story short, the pops would happen in the wrong order. How will this be handled?

Ah, but this is exactly my point about scoping!  Because of those extra parenthesis after the subtraction, those stack calls would not be in the same scope and therefore be illegal.  This is one of the reasons I don't want to support an override for the scope checking because it would be very confusing and incompatible with future versions if any of the underlying stack usages in the background of the program change.

The Return^r is a good idea, but that implementation won't work because pointers actually are being added to the code in the first pass for labels.  The second pass just fills in static storage and built-in subroutines.  I might still try to come up with another way though.

I've decided to try to incorporate Axe into zStart. But since Axe is constantly being changed, I can't statically link to addresses within it.

So my request is a call table that's at a static location that outside programs can call. The only two calls I can see needing though are:
-Compile OP1
-Set Axe Hooks

I want the Compile OP1 so I can make a button that compiles an Axe program. Preferably, have it display everything it normally does when compiling a program, and then just return. With enough hacking, this might even allow for an on-computer compiler.

And the set axe hooks would be so that even after ram clears, you have Axe's token set.

Yes, I was definitely planning on adding hooks within Axe for external compiling.  Next update would be a good time to add them.

EDIT:  The only problem though is that Axe uses almost all of the free ram locations when compiling so you'd have to be extremely careful if you want your program to resume after the compile.