« previous next »
Pages: 1 [2]   Go Down

Author Topic: Axe Optimization Tricks  (Read 14349 times)

0 Members and 1 Guest are viewing this topic.

Offline Deep Toaster

  • So much to do, so much time, so little motivation
  • Administrator
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 8217
  • Rating: +758/-15
    • View Profile
    • ClrHome
Re: Axe Optimization Tricks
« Reply #15 on: July 01, 2010, 09:49:47 pm »
Quote from: ztrumpet on July 01, 2010, 03:23:20 pm
Quote from: LordConiupiter on July 01, 2010, 02:23:45 pm
oh, because it has to be converted to basic type number when you store into Ans?
Yes, and it is also storing to a TIOS variable, making it larger and slower. :)
If you store to an "Axe Var", then you're just changing the content of two, easy to use bytes. :D

Ans takes memory for the exponent and for negation, plus seven bytes of data, many of which are unnecessary since Axe only allows storing 2-byte integers (between 0 and 65535). These are first stored to OP1 (I think), then all nine bytes of data (including seven which would otherwise have been unnecessary) have to be moved to Ans, so it's a lot slower. Storing to an Axe variable location is just that: it simply copies the two bytes over there :)

The only reason I can see for storing to Ans within an Axe program is to make the returned value available to the user (for example, as a subroutine for BASIC programs written in Axe).
Logged



Offline ztrumpet

  • The Rarely Active One
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5712
  • Rating: +364/-4
  • If you see this, send me a PM. Just for fun.
    • View Profile
Re: Axe Optimization Tricks
« Reply #16 on: July 01, 2010, 10:35:10 pm »
Quote from: Deep Thought on July 01, 2010, 09:49:47 pm
Quote from: ztrumpet on July 01, 2010, 03:23:20 pm
Quote from: LordConiupiter on July 01, 2010, 02:23:45 pm
oh, because it has to be converted to basic type number when you store into Ans?
Yes, and it is also storing to a TIOS variable, making it larger and slower. :)
If you store to an "Axe Var", then you're just changing the content of two, easy to use bytes. :D

Ans takes memory for the exponent and for negation, plus seven bytes of data, many of which are unnecessary since Axe only allows storing 2-byte integers (between 0 and 65535). These are first stored to OP1 (I think), then all nine bytes of data (including seven which would otherwise have been unnecessary) have to be moved to Ans, so it's a lot slower. Storing to an Axe variable location is just that: it simply copies the two bytes over there :)

The only reason I can see for storing to Ans within an Axe program is to make the returned value available to the user (for example, as a subroutine for BASIC programs written in Axe).
Almost, but not quite.  For example, in Axe, the number 65535 would be FF FF, but in Ans it looks like $00 $84 $65 $53 $50 $00 $00 $00 $00.  Because the TIOS stores this number so oddly, Axe has to take even more time to convert it. :)
« Last Edit: July 01, 2010, 10:35:39 pm by ztrumpet »
Logged

Offline Deep Toaster

  • So much to do, so much time, so little motivation
  • Administrator
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 8217
  • Rating: +758/-15
    • View Profile
    • ClrHome
Re: Axe Optimization Tricks
« Reply #17 on: July 01, 2010, 10:47:39 pm »
Oh, right, forgot about that. Why does TI store floating-points like that? And what happens if there's a hex-only value there (e.g.
Code: (Z80 Assembly) [Select]
$00 $8D $01 $23 $45 $67 $89 $AB $CD ;notice $AB and $CD don't work as decimal numbers
)?
Logged



Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Axe Optimization Tricks
« Reply #18 on: July 02, 2010, 02:32:09 am »
wow o.o I guess it can be understood since it supports floating points, but darn that is large and confusing x.x

I think I'm gonna be fine with my little 1 byte and 2 byte integers for a while ;D
Logged

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Axe Optimization Tricks
« Reply #19 on: July 02, 2010, 02:46:18 am »
Yeah, it does it that way for precision.  For example, if it was stored in Binary, there would be horrible rounding problems (like how there is no way to represent .1 in Binary accurately) so they use this digit approach which may be slower but so much more precise
Logged

Offline Deep Toaster

  • So much to do, so much time, so little motivation
  • Administrator
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 8217
  • Rating: +758/-15
    • View Profile
    • ClrHome
Re: Axe Optimization Tricks
« Reply #20 on: July 04, 2010, 05:03:44 am »
So what would happen if one of the bytes contained non-decimal data, such as $CA?
« Last Edit: July 04, 2010, 05:04:06 am by Deep Thought »
Logged



Offline calcdude84se

  • Needs Motivation
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2272
  • Rating: +78/-13
  • Wondering where their free time went...
    • View Profile
Re: Axe Optimization Tricks
« Reply #21 on: July 04, 2010, 10:18:25 am »
You'd have to have modified it by hand using, say, CalcSys. As for what happens, it displays garbage and the calculations are somewhat unpredictable, or at any rate abnormal.
Logged
"People think computers will keep them from making mistakes. They're wrong. With computers you make mistakes faster."
-Adam Osborne
Spoiler For "PartesOS links":
I'll put it online when it does something.
Pages: 1 [2]   Go Up
« previous next »