.< and .> would be cool.

I'm glad I did some Axe today, otherwise I wouldn't have reminded of this possible new feature

Um, i think every single one of those is incredibly difficult to do.  USB support isn't well understood, and has very very complicated linking that might bloat code and i dont even know how fast it would be.  OS support, IMHO should not be something Axe is ever allowed to do, because of the new potential for every Axe user to brick their calc.  Not to mention you need complete control over the calculator in order to write an OS, which would require a whole host of new commands to write to flash and swap pages and the like, and it would be a whole project in its own.  Computer compiler has already been discussed an has been worked on by Quigibo, and he stated that it will not be addressed until after 1.0.0 comes out.

I don't want to sound like i am saying those are all bad ideas, i just think that ideas such as those should be completely up to Quigibo, and not to make him feel like he has to enable Axe to write OS's or support advanced features.

graphmastur, I think your expectations of Quigibo and Axe are just a little high... Even the most knowledgeable assembly programmers steer clear of the USB port because very few people know how to use it. I think it's a little too much to ask Quigibo to write arbitrary USB protocols for a system that hardly anyone has even been able to hack together any USB functionality. And the same goes for coding operating systems. The first person to design a programming language that allows users to easily write full operating systems deserves a Nobel prize (or whatever the equivalent is for computer science). Anyways, Axe was built to be a programming language to write programs for the TI operating system. It is in many ways inseparable from the TI operating system, and would instantly fail without it.

The computer compiler, on the other hand, Quigibo already plans to work on. That's what Axe 2.0 will be.

EDIT: Damn it, double ninja'd.

If by OS you mean porting Axe to another OS, I think Sir or someone else was planning to port 1.0 to KOS when it comes out, but do not expect that to happen in short terms.

As for USB, the doc about it is limited. SirCmpwn asked TI for it a few times and TI didn't want to give it to him.

.< and .> would be cool.

I'm glad I did some Axe today, otherwise I wouldn't have reminded of this possible new feature

Good idea! It would be very sufficient indeed to have multi line comments. 

ow! how stupid am I today! perhaps I'm working too much for the contest, and sleeping too little

could you also add port reading in the future? I do not mean the I/O port etc, but ports like these: All ports by Address

EDIT:
another feature for the next Axe version after 1.0.0:
the Function command, for labels to be used as commands like subs. I'll explain what I mean with an example:
normally, when you want to use a subroutine, you do:

Code: (Axe) [Select]

sub(SUB,1,2,"HELLOL"
Return

Lbl SUB
Exch(L3,L6,768)
Text(r1,r2,r3)
Exch(L3,L6,768)
Return
but the idea of Function is that this could be done:

Code: (Axe++) [Select]

Text(1,2,"HELLOL")r
Return

Function Text(3)r
Exch(L3,L6,768)
Text(r1,r2,r3)
Exch(L3,L6,768)
Return
this is some kind of Axiom thing, but than in Axe itself, right?
could this be added in Axe++?

this feature request has been somehow forgotten, but my wish hasn't changed...
I would really like to see implemented this. Here is a better description of what I tried to say in the above quoted post: access to serveral ports/pins of the processor, so anyeone can write his/her own routine for for example USB linking.

This has probably been already asked before, but how about a 'break' function?

Also, it would be nice if I could do something like 'BreakIf A' similar to the already existing 'ReturnIf A'

Continue() and Break() would be nice (maybe without the parens)

This has probably been already asked before, but how about a 'break' function?

Also, it would be nice if I could do something like 'BreakIf A' similar to the already existing 'ReturnIf A'

That and Continue would be nice.

And this is a request that has been posted before: Goto LBLIf CONDITION syntax (which could save us a few bytes ).