Unfortunately, I just realized that there is going to have to be one additional restriction.  Each Axiom will have a maximum number of subroutines (but still unlimited replacements).  The number right now is 32.  I can increase this number in the future if I reduce the number of total Axioms allowed per program but I think this limit is acceptable as it is.   To give some perspective, the entire parser currently has 29 built-in subroutines which includes all the typical functions as well as all the operations such as multiplication and division.

LOL!  That would be awesome if you could have the companion cube

If you subtract all the extra app header stuff, it leaves 16189 Bytes of executable code available with unlimited data storage (once I get reading from archive working).  A typical large game has anywhere from 20%-80% data which includes sprites, maps, text, music tracks, and things like that.  So really it should be possible to have multi-paged apps eventually if I can get all that stuff done before the contest deadline.  Reading from other app pages is relatively simple since its just a form of reading from archive.  Executing data on those pages however is much more difficult, but not impossible.

I'm almost certain that they're ignored, but I haven't actually tried that yet.

In addition, your idea doesn't make any sense.  How could you use an inline command to store data?  The regular methods for Axe data storage involves moving data to the end of the program and gives you a pointer but the assembly is inserted directly at the place you put it.  Its like saying you would rather use Asm(Data) to store your data instead of [Data] since both store hex values into the program.  The difference is that the first one executes the data and the later is just storage.  Although technically its possible to store data in Axioms, its much less efficient and requires difficult assembly to make it usable as data.  Such assembly would be against the rules anyway.

This is for all assembly programmers who want to develop Axioms for Axe, you can post your questions, related bugs, and other concerns here.  Although I have not actually finished the Axiom feature, I have finished a template for the format I am most likely to use.  It is possible that there could be some very minor changes, but you will easily be able to compensate for those.  I just want to release this now so people can start writing their routines in preparation for this feature.

I included the SDK as well as an example Axiom that shows how some of the current functions could be written as Axioms.  Unfortunately, I realized that it will not be possible to redefine the token names as I was planning since the hook would take too long to search through the program to figure out which Axioms are used in that source and then search through those appvars every time a token is displayed in the editor.  The slowdowns would be too great especially for larger libraries.

Anyway, happy programming!

@ztrumpet, I hope so.  I plan to eventually have external Axe libraries which is basically almost exactly what you're talking about, however, it is very difficult.  Much more so than Axioms.

I have reset the poll since I finished interrupts which are really awesome are surprisingly simple to use in Axe.  You're all going to be so spoiled [old man voice] becasue back in my day, we had to are our interrupts in assembly, and the tutorials were wrong and misleading, and I spent weeks before I realized I forgot to save the IX register, and get off my lawn you crazy kids! [/old man voice] .  I have replaced it with geometry drawing so please vote once again!