I have a little conundrum.  As soon as I allow forward referencing of constants, there is immediately going to be a problem with auto-optimizations.  If the constant value is unknown when it gets to a routine that can auto-optimize (lets say for this example multiplication), it won't know which optimization to do because it doesn't know if its *2, *3, *4, etc.  All it can assume is that its some constant.  I can't just skip over this and come back later when the value is known because each auto-opt is a different size and parsing cannot continue unless the future addresses are correct.  So in this case, it would have to assume the worst case and always use the multiplication subroutine, regardless of the value.

This is avoided simply by declaring a constant BEFORE you use it instead of after, but its noteworthy.  I've already been doing this with pointers but you don't notice because pointers have values like "$9EF0" for instance so those never auto-optimize anyway and you never use them in math other than addition and subtraction.  I'm stumped to think of a way around this though, anyone have any ideas?  I suppose its not too big of a deal either way.

EDIT: seems like Zeros() is adding to the program size... 3200-(768*2)=~1700 bytes of code.  Sounds a bit more likely, but i thought Zeros() didn't add on to the program size that much

It adds just as much as any other data.  But if you're using a shell, data won't add to the size limit in Axe 1.0.0, but don't rely on that being out before the contest deadline, I'm hoping it will be though.

Awesome menu by the way!

I run a 5:50 mile, so this seems to work for me. YMMV.

5:50 pace for a marathon!!!    That's really fast, I'm shooting for about an 8:00 mile pace because I think that will be more comfortable/realistic since this is my first marathon.

By the way, I just ran 4 miles today (the most I've ever run without stopping) and I didn't feel that tired.  My first long run will be on Friday on a 7 mile course.

With that much space, I could just store a list of pointers to places that need replacements later and then replace them all once the values are known at the end of parsing.

Alright, I'll answer all of those

1. Yes, that would be be easy.  I remember trying to do this before though and I think there was some problem with it but I don't remember what it was so I'll try it again.  Right now, each symbol is 3 bytes and I'm already using that to store 4 characters via 6-bit compression.  With 26 uppercase, 26 lowercase, 10 digits, theta, and null, that exactly fills up the 64 allowed combinations.  So if there's some other character there I'm forgetting, that may have been the reason, but I guess I could scrap a letter or 2, however confusing that may be...

2. That would be easy, but I'm not sure about that token choice, that would be weird since its currently used in the newline.  I could instead use the pi token since I don't think my previous idea of using it for stack is going to work.

3. Also easy.  I just don't want to encourage them to be used too much though or you'll start to get out of symbols errors.  But I'll definitely implement this if I do the above.

4. I don't think so, there is no single table of all the tokens Axe uses, and when you include multiple Axioms, it would get even trickier.  Also, there's just too many places in the code where a token needs to be instantly recognized as variable, constant, or special character.

5. Love the idea, but I would hate to see someone not be able to compile others' source code just because they don't have an extra ram page.  I guess I can put that up for a poll maybe.  There was point where I was thinking of using extra ROM pages, which both calcs have, since the data is write-once anyway and I already have routines to unlock flash.  I'm pretty sure the 83/84s keep an entire sector open for nothing but temporary swap use, which I could clear and use myself.  That might be better, but I'll have to do more research to make sure its possible.

All these are reverse compatible with the current Axe version though so I could add them any time.  My highest priority right now is fixing things that are not going to be reverse compatible since I want to stop changing those after 1.0.0.

So I've decided to run a marathon!  This will be my first marathon ever and I've never ran more than 3 miles without stopping before so I'm going to be doing a lot of training for these 26 miles (42km).   Its going to be the San Fransisco Marathon on July 31 so I have just a little under 2 months to train which is shorter than recommended, but I'm confident I can do it.  Its a pretty cool course too, it goes across the Golden Gate Bridge at one point.

Has anyone here ran a marathon before?  Any tips for training and such? 

Bit shifting is when you "shift" the number's binary representation left or right.  So the number %00110101 shifted left is %0110101X.  Why did I put an X there?  Each shift/rotate instruction does the same thing and the only difference between them is how it affects the new bit to be shifted in.  A rotate shifts in the bit that just got shifted out, the logical shifts will shift in a zero always (except sll which is undocumented and shifts in a 1 due to a hardware bug), the carry shifts will shift in the carry flag, and the arithmetic shift will keep the bit unchanged.

A logical shift left is equivalent to a multiply by 2, and a logical shift right is equivalent to a division by 2, and an arithmetic shift right is equivalent to a signed division by 2.  So these pop up a lot during math routines.  Another use is when you're reading something or writing something bit-by-bit, you'll generally use carry shifts to shift in each bit until all the bits have been shifted in and you have a result.  Yet another example is drawing things to the screen when your pixels don't line up with one of the whole bytes of the buffer, you have to shift them to align.  There are tons and tons more uses as well, but these are probably the most common.

Nope, all those issues have been fixed.  There are currently no known bugs reported for 0.5.3 (yet) other than a few persistent things that have been around in most versions for a long time.  For anyone using older versions, I would recommend upgrading, since 0.5.3 is currently the most stable version and there won't be any new updated until a couple of weeks.