• Axe Parser 5 1
Currently:  

Author Topic: Axe Parser  (Read 534909 times)

0 Members and 1 Guest are viewing this topic.

Offline mrmprog

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 559
  • Rating: +35/-1
    • View Profile
Re: Axe Parser
« Reply #1980 on: September 25, 2011, 09:24:26 pm »
I actually wouldn't mind having that, even if it took extra space. Since I have an 84 se, space isn't really an issue for me. I know that it is for some people though. Perhaps two different AXE versions could be made, one being the normal, and the other having this and other memory hogging features.

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 Parser
« Reply #1981 on: September 25, 2011, 09:26:43 pm »
Yeah my issue is mainly those with lots of programs or who got a regular 83+. If they have Doors CS and Axe, right now they already only have 5 pages left.
Ashbad, good to see you again!

Que

The problem is that some people do not have a computer at all (or any suitable access to one). JustCause comes to mind.

But then he can't distribute it anyways, so no problem there.

Well if he could sign on-calc, he could send the game from calc to calc.
« Last Edit: September 25, 2011, 09:29:17 pm by DJ_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: Axe Parser
« Reply #1982 on: September 26, 2011, 04:59:09 pm »
Two Axe releases in two days?? That must be a record!! O.O

Nice update though and I'm glad bugs are slowly getting narrowed down.

Offline squidgetx

  • Food.
  • CoT Emeritus
  • LV10 31337 u53r (Next: 2000)
  • *
  • Posts: 1881
  • Rating: +503/-17
  • rawr.
    • View Profile
Re: Axe Parser
« Reply #1983 on: September 26, 2011, 05:14:49 pm »
SO the new feature in 1.0.5...speedy fast less optimized compile..Is this referring to the actual time it takes to compile, or does this mean the executable is larger but faster? If it's the second, that's pretty cool. If it's the first, that's pretty cool too (I was about to ask why is that useful but then I realized for testing small changes in large projects etc.) Nice update...I still have 1.0.3 XP (gotta fix that)
« Last Edit: September 26, 2011, 05:14:59 pm by squidgetx »

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Axe Parser
« Reply #1984 on: September 26, 2011, 05:22:46 pm »
The new speedy compile option disables peephole optimizations. This should result in the parsing of average code being about two times faster while producing compiled code that is about 1-5% larger. It's very useful for recompiling large projects after making small changes for testing purposes, but remember to compile the slow way for your project releases!

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 Parser
« Reply #1985 on: September 26, 2011, 05:24:32 pm »
Hmm interesting, i didn't know this was implemented. It must be helpful when we are debugging and aren't willing to wait 30 seconds everytime XD.

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: Axe Parser
« Reply #1986 on: September 26, 2011, 05:34:23 pm »
Yeah, all the new zoom option does is disable the peephole optimizations, which makes it both slower and larger (but only slightly).  As Runer suggested, its really only for testing purposes in large programs that otherwise take a really long time to compile.

I'm just getting started with the more major peephole optimizations.  Some optimizations, like for instance 2->A:{A+L1}->B now automatically optimize to {2->A+L1}->B , which should help make code more readable.  The fact that finding optimizations like this is getting significantly harder to do in the disassembly means that Axe is inching closer and closer to the ASM limit.
« Last Edit: September 26, 2011, 05:41:10 pm by Quigibo »
___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: Axe Parser
« Reply #1987 on: September 26, 2011, 06:13:19 pm »
I'm really looking forward to that speedy compile option :o




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: Axe Parser
« Reply #1988 on: September 30, 2011, 05:38:25 pm »
I've finally figured out how to easily and intuitively allow stack usage for Axe programs that's so easy, even beginners can do it  ;D

Its so simple, I don't know why I didn't think about it before.  The syntax will simply be "keep(EXP1,EXP2)".  All it does is evaluate expression2 and then return expression1.  You might be like "Wait, what?  That seems so pointless, why can't I just do EXP2:EXP1 then?  Isn't that the same thing?"  The answer is no.

Consider this:
Code: [Select]
A->B:B->A
In that example, first, A is stored to B and then B is stored back to A again.  Not useful at all.
But now consider this:
Code: [Select]
keep(B,A->B)->A
What happens now?  You might think that since keep returns the first expression B and then stores it to A that its still the same piece of code. But no!  Keep evaluates B first and then keeps that value until the end of the keep.  So even though B changed value during the 2nd argument, the original B is returned and stored into A.  In other words, this is how you perform an exchange with only 2 variables, and its 4 bytes smaller than using an extra one too!

So where is the original value of B stored then?  That's what the stack is, but you don't need to know that.  All you need to know is that keep is magical and super efficient for this kind of thing.

EDIT: OOOOH, I just realized you can also make recursive function calls with this!  O.O
Code: [Select]
:Lbl FUN
:keep(r1,keep(r2,FUN(r1,r2)->r3)->r2)->r1
:Return r3
« Last Edit: September 30, 2011, 05:42:35 pm by Quigibo »
___Axe_Parser___
Today the calculator, tomorrow the world!

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: Axe Parser
« Reply #1989 on: September 30, 2011, 06:00:03 pm »
Well, two birds with one stone.
and Now we can do the perennial exercise of swapping two vars without creating a third var!
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 Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Axe Parser
« Reply #1990 on: September 30, 2011, 06:21:06 pm »
That seems like a pretty good way to safely implement stack usage. But could there also be commands for more experienced coders that simply equate to push hl, pop hl, and ex (sp),hl? Because your idea is great for casual coders, but crazy people like me like to be able to squeeze every last byte out of code. Something like you suggested here seems to be a good idea for syntax, and calc84maniac suggested a good syntax for ex (sp),hl here. Of course you would want to warn users about the dangers of these commands in the command list, but I don't think it's too dangerous to warrant not adding. There are so many other ways a programmer can crash their calculator with Axe, adding a new one won't really change much.
« Last Edit: September 30, 2011, 06:21:57 pm by Runer112 »

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 Parser
« Reply #1991 on: October 01, 2011, 12:38:09 am »
That sounds really, really useful. Another update? ;D




Offline Binder News

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 785
  • Rating: +46/-3
  • Zombie of Tomorrow
    • View Profile
Re: Axe Parser
« Reply #1992 on: October 01, 2011, 01:04:58 am »
That seems like a pretty good way to safely implement stack usage. But could there also be commands for more experienced coders that simply equate to push hl, pop hl, and ex (sp),hl? Because your idea is great for casual coders, but crazy people like me like to be able to squeeze every last byte out of code. Something like you suggested here seems to be a good idea for syntax, and calc84maniac suggested a good syntax for ex (sp),hl here. Of course you would want to warn users about the dangers of these commands in the command list, but I don't think it's too dangerous to warrant not adding. There are so many other ways a programmer can crash their calculator with Axe, adding a new one won't really change much.

I second that. I've been wanting more access to the stack for a while now.
Spoiler For userbars:







Hacker-in-training!   Z80 Assembly Programmer     Axe Programmer
C++ H4X0R             Java Coder                           I <3 Python!

Perdidisti ludum     Cerebrum non habes

"We are humans first, no matter what."
"Fame is a vapor, popularity an accident, and riches take wings. Only one thing endures, and that is character."
Spoiler For Test Results:





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 Parser
« Reply #1993 on: October 01, 2011, 11:17:52 pm »
Yea!  Awesome idea, Quigibo.  I can't wait for the next update. :D

Offline calc84maniac

  • eZ80 Guru
  • Coder Of Tomorrow
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2912
  • Rating: +471/-17
    • View Profile
    • TI-Boy CE
Re: Axe Parser
« Reply #1994 on: October 01, 2011, 11:34:47 pm »
That seems like a pretty good way to safely implement stack usage. But could there also be commands for more experienced coders that simply equate to push hl, pop hl, and ex (sp),hl? Because your idea is great for casual coders, but crazy people like me like to be able to squeeze every last byte out of code. Something like you suggested here seems to be a good idea for syntax, and calc84maniac suggested a good syntax for ex (sp),hl here. Of course you would want to warn users about the dangers of these commands in the command list, but I don't think it's too dangerous to warrant not adding. There are so many other ways a programmer can crash their calculator with Axe, adding a new one won't really change much.
Directly using pushing/popping can definitely cause problems in the middle of expressions, and in For(const) loops for example. There are too many things subject to change in the implementation of Axe for direct stack access not to be potentially buggy unless you know a lot about the inner workings of Axe. I think Asm() will suffice for crazy hackage.

Edit: Well, I suppose Axe could keep track of all pushes/pops as well as which ones are manual and which ones are internal. It could then error if it tries to internally pop a manual push or manually pop an internal push. That's fairly safe, I guess.
« Last Edit: October 01, 2011, 11:37:32 pm by calc84maniac »
"Most people ask, 'What does a thing do?' Hackers ask, 'What can I make it do?'" - Pablos Holman