Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: calc84maniac on September 08, 2010, 11:27:43 am
-
I figured it's about time to make a topic about the eventual 8-bit math mode that will be included in Axe. Post any suggestions, ideas, etc.
Here are mine. About the syntax, I was considering the possibility of enclosing 8-bit expressions with single quotes. But then I found out those are currently in used as 'CHAR' constants. So my other idea is using inverted brackets, like so:
]8-bit stuff goes here[
For example, you could have
]A+5->A[
which would compile to
ld a,(var_A)
add a,5
ld (var_A),a
The compiler should keep track of whether the "last answer" is 8-bit or 16-bit, and do a conversion if operating with a different bit length.
For example:
]A+5[->B
would compile to
ld a,(var_A)
add a,5
ld l,a
ld h,0
ld (var_B),hl
Perhaps it could also be possible to force signed conversion, like so (the value will be interpreted as -128 to 127):
]A+5[r->B
which would compile to the following:
ld a,(var_A)
add a,5
ld l,a
rla
sbc a,a
ld h,a
ld (var_B),hl
Using memory read brackets {} in 8-bit mode should force 16-bit mode within the brackets.
Example:
]A+{P+1->P}->A[
Compiled code:
ld a,(var_A)
push af ;save A in case it will get overwritten (seems to be an Axe standard)
ld hl,(var_P)
inc hl
ld (var_P),hl
pop af
add a,(hl)
ld (var_A),a
That's all for now! Direct comments, questions, concerns to your local Netham45.
-
maybe this is really silly because I am a total axe newb but, unless Quibi...(ehr I always forget his name..sorry) plans to implent this anywhere soon why don't you make a axiom out of it? (< not to be rude, just a suggestion) I think it might be quite helpful especially for those who really want to sqeeuze bytes out of their programs...
-
I don't think Axioms allow for things like this. This is something that would need to be supported in Axe itself (and Quigibo has said that he plans to add 8-bit math at some point. I'm just getting the ball rolling :) )
-
I really wish I knew what this is about exactly, like understood it all. What advantage does 8-bit have over 16-bit?
-
I think it might be a bit faster, although for small stuff it might not be very noticeable
-
I believe its also much smaller, so there is a size advantage as well as a speed advantage
-
Hmm, interesting to use 'inverted' brackets. That has got to go against all the language theories but that actually would work which is the interesting part :P
The problem with that though is that I think it would be beneficial to keep the 8-bit mode from line to line so you don't need to keep using the brackets.
]A+1->A[
]B+1->B[
<8bit>
A+1->A
B+1->B
<16bit>
Where <8bit> and <16bit> are some undecided token that indicates a switching of the modes. They can be used inline as well.
This is something that you won't see soon though, probably not until 2.0 (Axe++) because it basically requires me to rewrite an entirely new copy of the math library including new optimizations, conversions, and other technical issues I would have to deal with. I was also thinking of allowing the use of some lowercase letters to correspond to their registers for the lowest possible level of optimization.
-
Yeah at first I found this weird too. ;D . Do you think it could cause problems during parsing? I wonder if there could be another character that could be used if it's the case? (maybe a new token?)
-
register access! that would be really cool!
for the 8bit and 16bit tokens: perhaps RADIAN -> 8bit and DEGREE -> 16bit? or wouldn't the words in the mode menu change when the token names are changed?
-
Direct register access would be interesting... But at that point, it's pretty much straight ASM... Maybe you could have a small inline assembler? No need for label support or anything. That would still be a lot of work, though.
8-bit math would definitely be useful; I'm already thinking of some optimizations I can make to my programs ;D
-
Yeah register access would be nice. It would extend the language so it can do more stuff that only ASM can do normally, while still having some higher level functions similar to TI-BASIC. This is what makes Axe so great IMHO. We can do some basic-like stuff that runs at ASM speed, but we can store stuff where we want in RAM, like ASM
-
Hmmm how would register access work well though? Since there are so many restrictions on what you can add and what you can store to. Like you cant add register b and c with one command. I guess it would be an especially asmers only command?
-
Yep, register access would be great. How about X1T for A, Y1T for F, and so on, so that we have obvious register pairs?
-
We would then need commands to access them (overloading?), and ways to deal with register pairs as a whole (like a way to do "ld (de),a", for example), and also more instructions (like in a,(N) or in b,(c) or even rlc ixh :P)
I'd personally like an inline assembler (w/o labels, as above) but this could work too ;D
-
Or we could always use Asm( ;)
-
I like the way you think Deep Thought ;) IMHO if we are going to be doing such complicated things that we are coding in half asm and half axe at the same time, maybe it would just be easier to code in straight asm or add in some small hex codes for small things
-
Although then it cannot be used in future contests :P (unless they're not pure-Axe-only)
-
The problem with Asm( is that it's difficult to read hex, while reading ASM is much simpler in comparison. Just my opinion ;)
Maybe I should just wait for Mosaic at this point, though mixing Axe and ASM would be nice.
-
Right now, I'm using OTBP to assemble short ASM clips into hex, then using that for Asm(. It actually works pretty well.
-
If native registers were supported, it would only be the most basic use of the registers: loading, adding, subtracting, and shifting, plus maybe a few simple things I'm not thinking about. It would only allow things that are legal in asm so you wouldn't be able to add b and c and store the result in d. Don't forget that part of implementing the 8 bit mode is moving the variables close enough to relative reference with IY so there are more optimizations possible.
By the way, I'm taking an assembly class using MIPS architecture (very similar to ARM) which feels like such a higher level language compared to z80. Those instructions are specifically designed to translate from C compilers and only now do I realize why there haven't been many good assemblers for z80 so far :P.
-
Nice Quigibo! And Yeah, the calc using a 8 bit processor doesn't help much x.x. I heard it was much easier to code in ARM assembly than z80, for example.
-
THose optimizations and features sound great :D Im especially excited for 8 bit mode ^^
-
Hey, I have another idea for register access. How about using Greek letters, like α for register A, β for B, γ for C, δ for D, ε for E, and σ for F (since it kinda looks like a "flag" anyway ;))? If someone's so good with calculators that he wants to use the native registers, he can probably access the restricted tokens pretty well.
-
Those are pretty hard to access, though. It would be best to choose tokens that are available without having to use a 3rd party program, even if it means renaming ANOVA( to A (slightly modified to stand out from the regular A) or the like
-
Maybe he could use the X[NUM]T tokens, but replacing them with the greek letters. In that case, flags could be replaced with that weird serif'd F.