I bet I know what's up, qazz. What OS are you running on your nspire?
some OSes are very, very unstable when you run anything with hooks. 1.4 has been the most stable in my experience.

and aww, the ticalc one is only .5.4

I have released Axe 1.0.5 on ticalc.org if anyone is interested. I highly recommend updating if you haven't already, specially if you were using other 1.0.x versions. Here are some notable new features:

Since 0.5.3:

• C-style calling convention: MySub(Arg1,Arg2,...)
  
• Over 2000 Custom named variables up to 5 letters long including lowercase
  
• Inline if statements (ternary operator)
  
• Pass functions as arguments for high-order functionals like 'map'
  
• Lambda expressions to accompany the above
  
• Nearly every drawing command can work on any buffer
  
• Actual short circuit operators (like || and && in C syntax)
  
• Code is peephole optimized for 1-2% size reduction
  

Since 1.0.3:

• Axe generated apps are no longer trial (they won't delete themselves)
  
• Interesting "getSprite" command for cloning sprites on a buffer
  
• Option to ignore peephole opts to compile in half the time (less optimized)
  
• More peephole optimizations for an yet another 1-2% reduction
  

Enjoy Link

Thanks for sharing the update with us, Quigibo, and I'm happy to hear that half of the new updates are related to optimization. Regarding "Over 2000 Custom named variables up to 5 letters long including lowercase ", is that simply 52^5 (which come to think of it is way over 2000) or are there only specific 5-letter variables you can use?

I think that he has the space to store 2,000 label names, and caps each one at five characters.

OK, that sort of makes sense to me, although I'm not sure where he's pulling 10KB of scratch space (or more) from.

I'm using the swap sector since variable addresses are write-once values. Currently only the first page of the swap sector is used, a mere 16kb out of a possible 64kb. I could extend the maximum number of characters per variable, the number of variables allowed, or both, but I'm still not sure if I might actually use the rest of the space for other kinds of optimizations that would otherwise be too memory intensive.

One example is that Axe could theoretically perform a statistical analysis of the program prior to parsing to group the largest and most frequently used series of arbitrary code into their own subroutines automatically. Conservatively, I estimate this could reduce code size 3-6% for most programs but would slightly decrease speed for performance code, so it would have to be optional.

That's a feature I don't see in modern optimizing compilers for some reason, but it seems like a really neat way to reduce code size. And your source can be even more readable since you don't have to make so many mini-subroutines yourself.