Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Happybobjr on December 04, 2010, 10:39:07 am
-
how can i deal with 3-4 byte numbers in axe?
-
you CAN, but you have to write your own routines to do so.
-
ya, thats why i am asking.
-
well, it's much mroe complicated than you think. basically, you're treating data not in bytes or words, but rather in dwords and 24 bit values. Basically, to do math in this format, you have to check the value of the added number to see how large it is and how many bytes it consumes. so, if it's within one byte, add the number to the very least significant byte and add overflow to the nextmost significant byte (and continue if that overflows too)
for a 16 bit addition, add the least most significant bits, carry overflow, then add the next most next significant byte, then carry overflow etc.
Never really done in axe before, though very possible to do in assembly.
-
how can i deal with 3-4 byte numbers in axe?
What kind of things do you need to do? Things like addition, subtraction, logic, and comparisons are definitely easily doable, but things like multiplication and division are trickier.
-
any information would be great.
i would b using L1 for the byte probably.
-
I think there's a explanation of it in "learn 83+ assembly in 28 days"
-
You want to look here:
http://future_history.freehostia.com/Files/Resources/ASM/ASMin28Days/lesson/day15.html
However, it's ridiculously complex and would be better suited for an Axiom. :)
-
how will that work with axe though?
-
any information would be great.
i would b using L1 for the byte probably.
Let's see... You probably know how to do equality (just check the two byte pairs for equality individually). Greater than/less than is also pretty easy: check the high (most significant) byte pair first, whichever one that is, and if it's equal, check the other byte pair. AND, OR, and XOR should work about the same: just do it on both byte pairs, then compare.
For math, addition and subtraction should be easiest, but the fastest way to do it would involve carries, which would require some messing with Asm(.
You can also do it without ASM (in normal Axe), so here's a quick rundown involving two 4-byte numbers (since it's the easiest to do). By "least-significant byte pair" I mean the two bytes that take up the smallest place value, and the "most-significant byte pair" is the two bytes that are at the highest place value.
Let's say you want to add two numbers together. It's easy if the least significant byte pair doesn't end up overflowing past 65535, since in that case all you have to do is add the least significant byte pair, then the other one. No messing around with anything; just simple addition.
But then if the smaller byte pair overflows, you'll have to add an extra one (carrying) to the other one. We tend to get used to it in real life, so to recap, it's like this:
1
19
+22
41
That extra 1's the carry I'm talking about. So how would you check for it? Well, basically if you add the least significant byte pair and it ends up being smaller than the first number you started with, you know there's a carry (like the 9+2 becoming a 1 above). Just test for this before and after you do the actual addition, and if there is a carry, add one more when you add the most significant byte pairs together.
Subtraction works pretty much the same way, but in the opposite direction: if you subtract two least-significant byte pairs and it ends up being bigger than the one you started with, there's a carry, so subtract one more when you do the other byte pair.
-
thank you much, i am starting too read... ;)
-
No problem, and sorry if it's confusing. I should probably give you more examples, but I gotta go. If anyone else understands it, they can give you any examples.
-
now about square roots?
-
Lol, that'd be hard. Axe doesn't even support that for one or two-byte numbers...
-
axe does support square root for 2 byte numbers.
-
now about square roots?
Well, it involves a few different things. I know of newton's recursive algorithm. It would require two four byte numbers. So, essentially, recursively do this formula: (I think. I could be wrong. Just search newton's method for square roots. Note that there are also better methods for a binary system than this.)
((N/X)+X)/2
-
what are N and X?
-
Why don't you use a bit of Assembly and just make the proper B_calls? The TI-OS routines already work with 9 byte numbers, so you would just need to throw away the guard digits.
And Graph, Newton's method works, but it can be slow to converge.
-
because i have -9000 experiance with assembly.
-
at least he doesn't have < -9000 asm experience...
-
I can help you write a routine if you can give me a better description of what exactly you need to do.
Here is a routine to add the first 2 arguments and store the result in the third. Each argument is a pointer to a little endian 4 byte number.
:Lbl ADD
:{r1}r+{r2}r->r4
:>{r1}r+{r1+2}r+{r2+2}r
:->{r4->{r3}r+1}
:Return
So This:
sub(ADD,oA,oC,oE)
Would do FE = BA + DC
-
Please correct me if I'm wrong, but shouldn't that greater than sign be a less than sign? The addition carried if the 16-bit result is less than a 16-bit input.
Also, I think you need an r modifier on the end of the last line.
Also, optimization: (Me optimizing Quigibo's code? It must be backwards day!)
:Lbl ADD
:{r₁}ʳ→r₅+{r₂}ʳ→r₄
:<r₅+{r₁+2}ʳ+{r₂+2}ʳ
:→{r₄→{r₃}ʳ+1}ʳ
:Return
You could also optimize it a bit more by restructuring the inputs to be in the order of (result,input1,input2):
:Lbl ADD
:{}ʳ→r₅+{r₂}ʳ→r₄
:<r₅+{r₃+2}ʳ+{r₂+2}ʳ
:→{r₄→{r₁}ʳ+1}ʳ
:Return
-
Why don't you use a bit of Assembly and just make the proper B_calls? The TI-OS routines already work with 9 byte numbers, so you would just need to throw away the guard digits.
And Graph, Newton's method works, but it can be slow to converge.
Let's not start with the whole "learn asm" thing. This is very 2004 and is trolling. He asks Axe help so he needs ask help. Telling him to learn ASM is not helping him, unless it was absolutely impossible to do so.
-
Yeah, I know Newton's method is slow to converge, but I figured with 3-4 byte numbers that it wouldn't be that bad. I don't know of any algorithms for square roots of BCD numbers, though.