I imagine it is getting harder to choose the tokens.

It is, when I suggest him new features via chat, he often comes up with "I would like to add this, but I would need to figure out a good token to use "

just read the high bit, which carries the sign, and then differentiate between positive and zero.

DJ, you can substitute your own addresses instead of L1 - L6 if you want.  L1 - L6 are just numbers after all.

DJ, you can substitute your own addresses instead of L1 - L6 if you want.  L1 - L6 are just numbers after all.

Bits not bytes Yeah I cant wait for this either It will make a few things quite usefull.

You can also do it with some loops or lookuptables coupled with AND and OR commands, but its a hassle

Just curious, would it be useful to set and get exact bits in the 2 byte number?  Like "get the 11th bit" and "set the 2nd bit" or is it more useful to have the Nth bit with N being variable?  Unfortunately, these routines with variable bits are kinda big.  Big enough where they wouldn't be inline like the constant bit checking and I would make it a subroutine to save space.

I might be able to do both, but I'll have to come up with some clever syntax.

By the way, I just coined a new term: "Axe Hax" for clever exploits of Axe commands.

You could optimize the AND/OR that will reset/set a single bit to a simple 2-byte RES/SET opcode. That way you won't even need extra tokens for constant bit commands.

Those commands are still there, but they've just changed syntax.  It makes the code more readable too because now you're using and/or/xor as single character operators just like addition, subtraction, multiplication, and the others.