Quote:
I haven't really looked at adding a CASE, but I've looked at adding FOR, but am hesitant due to wanting to stick to a C like syntax, and the C FOR loop being more like a while <> do, meaning an inefficient jmp back to the top of the while to test the condition on the last iteration. I guess a FOR loop doesn't have to stick to that structure though.
I modeled my structures mosly after Forth's standard ones (I say "standard" because Forth lets you make your own, in fact you can even define your own operators in Forth) but I figured BASIC's FOR...NEXT kind of syntax would be more readily accepted than Forth's simple but unusual DO...LOOP sytax (if you can even call it syntax, as Forth hardly has any syntax) by non-Forth-speaking people. In DO...LOOP, the internal compiled by DO only runs once, at the beginning of the loop, to prepare the stack, and then the internal compiled by LOOP (at the end of the loop) is what determines whether to go back to the top or not, similar to assembly language. The FOR...NEXT macros assemble the same thing you would do by hand, with for example:
Code:
FOR_X 8, DOWN_TO, 0
<loop contents>
<actions, actions>
<yada yada>
NEXT_X
which assembles:
Code:
LDX #8
TOP: <loop contents>
<actions, actions>
<yada yada>
DEX
BNE TOP
The loop does not get run for the counter value equal to 0 like it would in BASIC, but it's a better transfer to/from assembly where we're subconsciously thinking of the DEX BNE here.
There are so many possible ways to do a FOR...LOOP in assembly thought that I originally thought it would not be feasible, so FOR...NEXT was added a long time after I did the others, and the FOR...NEXT macros are very long for the little code they lay down (which is usually only two or three bytes), because of the many options the macros have to sort out to decide what code to lay down.
I consider the CASE statement to be very valuable, but I have never run into a situation where I've had to nest CASE statements. CASE and my 16-bit FOR...NEXT (which is separate from FOR_X|FOR_Y...NEXT_X|NEXT_Y which are always 8-bit for 6502) are the only ones I have not made nestable.