Author Topic: Assembly Programmers - Help Axe Optimize!  (Read 155797 times)

0 Members and 1 Guest are viewing this topic.

Offline Happybobjr

  • James Oldiges
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2325
  • Rating: +128/-20
  • Howdy :)
    • View Profile
Re: Assembly Programmers - Help Axe Optimize!
« Reply #105 on: December 20, 2010, 07:05:13 pm »
I would suggest a 2nd version within the folder Developers Tools.
That way some noob won't just find it on his calc.
School: East Central High School
 
Axe: 1.0.0
TI-84 +SE  ||| OS: 2.53 MP (patched) ||| Version: "M"
TI-Nspire    |||  Lent out, and never returned
____________________________________________________________

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Assembly Programmers - Help Axe Optimize!
« Reply #106 on: December 20, 2010, 08:03:06 pm »
There's really no reason to make an alternate version. Users would most likely learn about these new commands from the updates thread or by looking in the commands list, and Quigibo can add warnings to both of those.

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: Assembly Programmers - Help Axe Optimize!
« Reply #107 on: December 21, 2010, 03:07:37 pm »
These will decrease size, but also slightly decrease speed. I believe that Quigibo prefers smaller sizes over slightly slower code.
I think it depends, though. If the slight speed decrease is 0.01 FPS to 0.02 it may not sound like much if executed once but if someone uses something 20 times a loop he will see the difference. Otherwise I think he definitively optimizes for size.

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Assembly Programmers - Help Axe Optimize!
« Reply #108 on: December 21, 2010, 03:29:20 pm »
Hmmmm i wonder if in future versions there might be an option to compile for either speed or size, depending on the optimization you want O.O

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: Assembly Programmers - Help Axe Optimize!
« Reply #109 on: December 21, 2010, 08:54:51 pm »
Wouldn't it make the compiler super large, though? :O

Offline Happybobjr

  • James Oldiges
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2325
  • Rating: +128/-20
  • Howdy :)
    • View Profile
Re: Assembly Programmers - Help Axe Optimize!
« Reply #110 on: December 21, 2010, 10:31:22 pm »
or just have Axe version ?.?.? A  and ?.?.?B

EDIT: post 1000!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
« Last Edit: December 21, 2010, 10:33:36 pm by happybobjr »
School: East Central High School
 
Axe: 1.0.0
TI-84 +SE  ||| OS: 2.53 MP (patched) ||| Version: "M"
TI-Nspire    |||  Lent out, and never returned
____________________________________________________________

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: Assembly Programmers - Help Axe Optimize!
« Reply #111 on: December 21, 2010, 10:45:40 pm »
The problem with a compile setting for size/speed is that generally, you want part of your code to be optimized for size and another part to be optimized for speed.  This could be done with "speed-op" and "size-op" commands or perhaps a prefix for labels like "Lbl +LBL" indicates everything until the next label is optimized for speed and everything else by default is optimized for size.  Any shared subroutines like multiplication are added in the second pass so if multiplication was flagged to be fast in one place, it would be fast everywhere else too since it has to add the huge routine to your code anyway, all the other calls should share it.

It would make the parser a lot bigger, but it has room.  I'm almost full on the first page, but I still have about 10KB of extra room on the second page.  Commands are data in the Axe app so they would go on that page anyway.
___Axe_Parser___
Today the calculator, tomorrow the world!

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: Assembly Programmers - Help Axe Optimize!
« Reply #112 on: December 21, 2010, 10:46:47 pm »
By the way, was there a major change to the way Axe parsed →{BUNCH OF COMMANDS} somewhere between 0.2.6 and 0.4.4? I upgraded and didn't notice it until now :-\

EDIT: 10 KB remaining? Can I make a quick feature request then? Some sort of a way to pack Axioms into the app would be epic, even if we have to do it on the computer. Just a suggestion.
« Last Edit: December 21, 2010, 10:48:28 pm by Deep Thought »




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: Assembly Programmers - Help Axe Optimize!
« Reply #113 on: December 21, 2010, 10:51:50 pm »
Yeah, I don't remember when that was, but it optimizes better that way.  When storing stuff to a constant pointer, it returns the stuff you stored.  If storing to a variable pointer, it returns the pointer itself, or the pointer plus 1 if you're storing 2 bytes at a time.
___Axe_Parser___
Today the calculator, tomorrow the world!

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: Assembly Programmers - Help Axe Optimize!
« Reply #114 on: December 22, 2010, 02:55:40 am »
The problem with a compile setting for size/speed is that generally, you want part of your code to be optimized for size and another part to be optimized for speed.  This could be done with "speed-op" and "size-op" commands or perhaps a prefix for labels like "Lbl +LBL" indicates everything until the next label is optimized for speed and everything else by default is optimized for size.  Any shared subroutines like multiplication are added in the second pass so if multiplication was flagged to be fast in one place, it would be fast everywhere else too since it has to add the huge routine to your code anyway, all the other calls should share it.

It would make the parser a lot bigger, but it has room.  I'm almost full on the first page, but I still have about 10KB of extra room on the second page.  Commands are data in the Axe app so they would go on that page anyway.
That would be a nice idea actually. My worry was effectively about some parts needing to be smaller but others faster. Good luck with whatever you decide. :)

Also I notice Axe is at 70% now ;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: Assembly Programmers - Help Axe Optimize!
« Reply #115 on: December 29, 2010, 04:32:35 am »
You guys won't believe this, but I found an optimization to the general multiplication.  O.O

Code: [Select]
;#####  OLD  #####
p_Mul:
ld b,h
ld c,l
ld hl,0
ld a,16
__MulNext:
add hl,hl
rl e
rl d
jr nc,__MulSkip
add hl,bc
jr nc,__MulSkip
inc de
__MulSkip:
dec a
jr nz,__MulNext
ret
Code: [Select]
;######  NEW  ######
p_Mul:
ld c,h
ld a,l
ld hl,0
ld b,16
__MulNext:
add hl,hl
rla
rl c
jr nc,__MulSkip
add hl,de
adc a,0
jr nc,__MulSkip
inc c
__MulSkip:
djnz __MulNext
ret

Its a small optimization, its the same size as the original but it saves an average of 4 clock cycles per bit of the multiplication.  Since its a 16 bit multiplication, that's an average of 64 clock cycles (11 micro-seconds) and about a 6% increase in speed.  So its not that big of a deal, I was just really shocked I was able to optimize it.
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Assembly Programmers - Help Axe Optimize!
« Reply #116 on: December 29, 2010, 04:44:27 am »
Wow, that's such a common operator I can't even imagine the potential for speed increase in large programs like raycasters O.O

Offline jnesselr

  • King Graphmastur
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2270
  • Rating: +81/-20
  • TAO == epic
    • View Profile
Re: Assembly Programmers - Help Axe Optimize!
« Reply #117 on: December 29, 2010, 02:18:48 pm »
That is actually an amazing increase in speed. Very nice!

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: Assembly Programmers - Help Axe Optimize!
« Reply #118 on: December 30, 2010, 04:04:42 am »
Nice! O.O

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Assembly Programmers - Help Axe Optimize!
« Reply #119 on: January 04, 2011, 12:11:05 pm »
It doesn't look like the optimized p_EQN2 and p_EQN1 routines that I suggested made it into Axe 0.4.7. Did you maybe forget to add them? Or were my routines incorrect?

Also, I think you might have overlooked my footnote in the first equality optimization post mentioning that p_Div32768 can be optimized to be the same as p_SLT0 and p_GetBit0. :P



EDIT: Also, it doesn't look like p_EQNX and p_NENX are being used by the parser. Is this just an accident, or did you intentionally leave them out for now due to the problem of the constant in the source code not equaling the constant that should be inserted?

And along the lines of comparing negative shorts, if you get p_NENX working, it should be the same size and faster for -3 than p_NEN3, so the latter should be removed. And for p_NEN2, can't the first instruction just be inc l instead of inc hl?


EDIT 2: I think I've mentioned this in the past as well, but it looks like you must've missed seeing it/adding it. p_GetBit15 could be optimized to be the same as p_Mod2.


EDIT 3: (Man this is going to be one long post) It was smart of you to make the greater than, greater or equal, less than, and less or equal comparisons with second arguments that are expressions call the opposite routine after popping the first argument into de, thus avoiding any double ex de,hl's. Could something like this also be used for the greater than and less or equal comparisons with the second argument being a variable? A byte could be saved by making these insances use ex de,hl / ld hl,($0000) to load the variable instead of ld de,($0000) and then call the opposite routine.

EDIT 4: Going along the lines of edit 3, p_SIntGt and p_SIntLe could be optimized for variable arguments in the same way. Although no bytes would be saved calling p_SIntLt instead of p_SIntGt, cycles would be.
« Last Edit: January 04, 2011, 05:10:55 pm by Runer112 »