Oh no, no!  These aren't custom interrupt routines (im 2)!  These are the OS interrupts (im 1), they don't do much as you can see right now, but they will come in handy when I do add custom interrupt support.

Axe Parser
Beta 0.2.6

---

New Features:

• Instant goto when pressing [prgm] after errors.
• Use Sub() and Asm() inline with math operations.
• Sorting command added.
• Some very basic OS interrupt commands.
• Constant expressions are evaluated pre-compile time.
• Reading and writing to static addresses should be fully optimized now.
• Math and numbers are more flexible.

Changed:

• Reading and writing to static addresses returns the value instead of the address.
• Fixed several bugs.

Made a 3D game for the fun of it.

Axe has supported reading programs for a long time.  Its creating programs that I haven't added yet (but will soon).

The use for this would be if you wanted to make a level editor for your game or something, you could just have the main program read another program that contains nothing but level data.  That way its easy to make your own levels because you can use the built-in TI-BASIC editor.  I think this would definitely be in the spirit of Axe.  Although I do agree, if you add a feature like this, it is much better if the program itself is stand-alone without needing "level packs".  At least include a built in demo level so that the level packs are optional and the single executable alone is still playable.

Hmm, the idea could work.  I like the idea for iPart() as the command, but at the same time, I am also planning to add the Rect() command for drawing filled boxes and I wonder if I can use a modifier to switch between fill black, fill white, and fill invert.  This will come when I get to geometry drawing, but don't expect it for a while.

IMPORTANT UPDATE!

Unfortunately, or fortunately depending on how you look at it, one of the new optimizations will change the way you optimize your code.  When saving to a pointer at a static location, the return value will now be the value stored rather than the address that is being saved to.  This rule does NOT apply to locations with variable addresses like {A} or {B+L1+8}, those will remain the same as before.  Its when you save to pointers like {L1+4} or {Str1-16} that this will affect.   Both 1 byte and 2 byte storage are affected the same way.

The advantages vastly outweigh the inconveniences however.  Realize that after this release, saving to static addresses will have the EXACT SAME efficiency and code size as saving to a regular variable.  {L1+9}^r+1->{L1+9}^r for instance will be the same size code as A+1->A in the executable.  That saves about 4 bytes for every time you read a static pointer and 3 bytes every time you save to one.  The speed increase might be noticeable too if you use these in loops a lot.

If you still want to do tricks like this: Fill(0->{L1},100)  You can still write Fill(0->{L1}^rL1,100) and it should be the same sized code in the executable.  The double byte storage is actually smaller and faster than single byte storage when using static locations by the way.  Just making sure I warn everyone first before anyone panics if their executable doesn't work right in the next version.  This is the second wave of major optimizations and the first REAL look-ahead parsing with actual backtracking and I've still got many more to go.

And when I insert the pic into the program, I added det(12 before Pic#->DispGraph, but it displays some random pixels on the bottom row where the inaccessible row 64 is.  I don't think det(12 WORKS THERE, BECAUSE i'M guessing thats a portion of the next Pic in RAM.  If I'm right, can someone tell how to fix this?

You have to put the det(12) directly after the picture data because the det command is a data command and isn't actual code.

Quigibo, it would be nice to maybe describe what involves pushing/poping and the stack when it comes to Axe code, because it is ASM stuff that isn't referenced in the Axe manual, so it might be confusing to Axe programmers that doesn't know ASM.

As I said before, Axe doesn't allow you do use the stack unless you use your own assembly code, that's why I never mention it.

Runer, are the numbers off by 2 or by a lot?  Try putting it in your other subroutines and see if you narrow down the one that changes it.

@Runer

Axe doesn't have restrictions on this other than the 150 individual label names.  Its more of a hardware limitation.  I think the stack size is like 400 bytes or something although I have no idea really I'm basically making up this number.  Anyone actually know?

It sounds more like you have a memory leak on the programming side than on the parser side.  Double check that all the subroutines end in Return and that you aren't using goto between subroutines or trapping recursive subroutines, I don't know if you're using those.  Also, it could be some other command that is not subroutine related that is causing it to freeze.