Author Topic: Documentation of the Speed and Size of (Almost) Every Axe Command  (Read 22344 times)

0 Members and 1 Guest are viewing this topic.

Offline ZippyDee

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 729
  • Rating: +83/-8
  • Why not zoidberg?
    • View Profile
Re: Documentation of the Speed and Size of (Almost) Every Axe Command
« Reply #30 on: March 30, 2011, 04:52:10 pm »
But what causes it to not be usable at 15MHz?
There's something about Tuesday...


Pushpins 'n' stuff...


Offline Munchor

  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 6199
  • Rating: +295/-121
  • Code Recycler
    • View Profile
Re: Documentation of the Speed and Size of (Almost) Every Axe Command
« Reply #31 on: March 30, 2011, 04:53:08 pm »
But what causes it to not be usable at 15MHz?

Its assembly code, somehow. Runer must have tried to optimize the code in a way that makes it impossible to 15MHz I guess.

Offline ZippyDee

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 729
  • Rating: +83/-8
  • Why not zoidberg?
    • View Profile
Re: Documentation of the Speed and Size of (Almost) Every Axe Command
« Reply #32 on: March 30, 2011, 05:01:20 pm »
I know it's assembly. I understand that some optimization makes it impossible with 15MHz. But what's different at 15MHz than 6MHz?
There's something about Tuesday...


Pushpins 'n' stuff...


Offline Freyaday

  • The One And Only Serial Time Killing Catboy-Capoeirista-Ballerino
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1970
  • Rating: +128/-15
  • I put on my robe and pixel hat...
    • View Profile
Re: Documentation of the Speed and Size of (Almost) Every Axe Command
« Reply #33 on: March 30, 2011, 05:06:11 pm »
The screen needs a delay of about 10microseconds between inputs, otherwise it shows garbage (not the band, sadly). @6MHz the processor is slow enough that this isn't a problem, but @ the higher speed it's faster than that.
In other news, Frey continues kicking unprecedented levels of ass.
Proud member of LF#N--Lolis For #9678B6 Names


I'm a performer at heart; I stole it last week.
My Artwork!

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: Documentation of the Speed and Size of (Almost) Every Axe Command
« Reply #34 on: March 30, 2011, 11:16:32 pm »
The screen needs a delay of about 10microseconds between inputs, otherwise it shows garbage (not the band, sadly). @6MHz the processor is slow enough that this isn't a problem, but @ the higher speed it's faster than that.

Yeah. Basically there is a delay included in the routine, and it's long enough in 6 MHz mode, but the 15 MHz processor goes through the delay too quickly.




Offline ZippyDee

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 729
  • Rating: +83/-8
  • Why not zoidberg?
    • View Profile
Re: Documentation of the Speed and Size of (Almost) Every Axe Command
« Reply #35 on: March 31, 2011, 12:17:33 am »
Is there no way to tell which mode it's in and only have it delay if it's at 16MHz?
« Last Edit: March 31, 2011, 12:18:23 am by ZippyDee »
There's something about Tuesday...


Pushpins 'n' stuff...


Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Documentation of the Speed and Size of (Almost) Every Axe Command
« Reply #36 on: March 31, 2011, 12:18:44 am »
In the next version of Axe, Quigibo will releasing a fix that puts the calculator in 6MHz mode before running the DispGraph routine and then returns it to the CPU speed it was previously running at when it finishes.
« Last Edit: March 31, 2011, 12:19:50 am by Runer112 »

Offline ZippyDee

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 729
  • Rating: +83/-8
  • Why not zoidberg?
    • View Profile
Re: Documentation of the Speed and Size of (Almost) Every Axe Command
« Reply #37 on: March 31, 2011, 01:05:14 am »
Awesome :D That sounds like it'll make it much easier.
There's something about Tuesday...


Pushpins 'n' stuff...


Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Documentation of the Speed and Size of (Almost) Every Axe Command
« Reply #38 on: May 16, 2011, 08:43:25 pm »
Updated for Axe 0.5.2. As usual, the updated file is attached to the first post. I'm also going to start a more detailed changelog, in case people are interested in knowing what exactly changed between versions of Axe. [NEW] denotes new Axe commands, [CHG] denotes changed Axe commands, and [FIX] denotes commands that haven't changed but have corrected information.

Changes:
  • [FIX] Header size information
  • [FIX] Added notes specifying that most 2-byte backwards loading commands are broken
  • [CHG] Negative 8-bit constant equality checking (e.g. =⁻42) now works
  • [NEW] Trivial comparisons ≥0, >65535, ≤65535, and <0
  • [CHG] Constant unsigned comparisons ( > <) are smaller and faster  —  ~2 bytes smaller, ~8 cycles faster
  • [CHG] >VAR and <EXPR optimized for size  —  1 byte smaller, 5 cycles slower
  • [NEW] Optimizations for bitwise logic operations with constant operands
  • [NEW] Optimized For() loops if the upper bound is a constant  —  1 byte smaller, 17 cycles faster
  • [CHG] Nibble reading commands changed as a result of a bug fix and are now big-endian
  • [NEW] Routine for preserving CPU speed and interrupt status before display commands
  • [CHG] Adjusted all buffer display commands for the addition above
  • [FIX] Speed estimates for commands that access the LCD
  • [CHG] Full is smaller and faster  —  1 byte smaller, 3 cycles faster
  • [CHG] All GetCalc() routines properly handle pointers to real and complex float variables
  • [CHG] Archived variable locating routine optimized for size  —  5 bytes smaller
  • [CHG] Pt-Mask() bug fix to work properly for aligned sprites
« Last Edit: May 16, 2011, 08:47:32 pm by Runer112 »

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Documentation of the Speed and Size of (Almost) Every Axe Command
« Reply #39 on: May 16, 2011, 08:46:48 pm »
Nice, thanks for this :D

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Documentation of the Speed and Size of (Almost) Every Axe Command
« Reply #40 on: May 17, 2011, 05:43:40 pm »
Just wanted to mention one other thing to add to the list; I turned the DispStrApp and TextStrApp inline routines into subroutines.
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Documentation of the Speed and Size of (Almost) Every Axe Command
« Reply #41 on: May 17, 2011, 06:01:29 pm »
Ah, so you have. I checked for that because I know I had suggested that change, but after a quick glance and not seeing any returns on the end I figured they hadn't changed. I didn't think to look for the conditional returns in the middle of the routines.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Documentation of the Speed and Size of (Almost) Every Axe Command
« Reply #42 on: May 28, 2011, 01:06:16 pm »
Updated for Axe 0.5.3. As usual, the updated command information document is attached to the first post.


Changelog:
[NEW] denotes new Axe commands, [CHG] denotes changed Axe commands, and [FIX] denotes Axe commands that haven't changed but have corrected information. Red denotes a bug. Green denotes a change that I deem to be awesome.

  • [CHG] All 2-byte big-endian loading and storing commands now work
  • [FIX/0.5.2 CHG] Added trivial math operations +0, -0, *0, *1, *65535, /0, /1, //0, //1, ^1, ^65535        (If you're reading this Quigibo, did I miss any?)
  • [FIX/0.5.2 CHG] Added notes specifying that //0 and ^65535 are mathematically incorrect
  • [CHG] Any of the trivial math operations listed above that result in no compiled code cause a crash during compiling
  • [NEW] Increment and decrement operators ++ and --
  • [CHG] Nibble storing routine adjusted to access nibbles in big-endian format, like the nibble reading routines
  • [FIX/0.5.2 CHG] The routines to draw strings in applications converted into subroutines
  • [FIX] Adjusted the cycle estimates for p_NewLine, p_ClearScreen, and p_SaveToBuffer
  • [CHG] Optimized p_FastCopy  —  1 byte smaller, 1548 cycles faster
  • [CHG] Optimized p_DrawAndClr  —  2 bytes smaller, 1548 cycles faster
  • [CHG] Optimized p_DispGS  —  ~5000 cycles faster
  • [CHG] Speed-optimized p_Disp4Lvl and improved grayscale quality  —  3 bytes larger, ~7500 cycles faster
  • [FIX] Adjusted the cycle estimate for p_DKeyExpr
  • [FIX] Adjusted the cycle estimate for p_Div
  • [FIX] Adjusted the cycle estimate and notes for p_SDiv
  • [NEW] 8.8 fixed point reciprocal command -1  —  29 bytes, ~1349 cycles
  • [CHG] Division and signed division have a bug that will cause them to always return 0 if the divisor is greater than 255
  • [CHG] Speed-optimized p_Sqrt  —  15 bytes larger, ~5500 cycles faster
  • [FIX] Added a note mentioning that p_FlipH can produce a garbage sprite
« Last Edit: May 28, 2011, 01:12:19 pm by Runer112 »

Offline Munchor

  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 6199
  • Rating: +295/-121
  • Code Recycler
    • View Profile
Re: Documentation of the Speed and Size of (Almost) Every Axe Command
« Reply #43 on: May 28, 2011, 03:18:22 pm »
Nice Runer112, cool you keep us updated :D

Also, is there a chance this can be released with Axe?
« Last Edit: May 28, 2011, 03:18:37 pm by Scout »

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Documentation of the Speed and Size of (Almost) Every Axe Command
« Reply #44 on: May 28, 2011, 03:36:27 pm »
If Quigibo wanted to release this with Axe, he'd either have to keep it up to date himself or give me new versions of Axe about a day in advance so I can update the file and give it back to him. Supposedly we're very close to Axe 1.0.0 though, for which he may or may not want a file like this being packaged into the sort of "final" version.