Author Topic: Axe Parser (Read 555310 times)

Quigibo · « **Reply #2070 on:** December 17, 2011, 11:30:41 pm »

I don't know what you mean by that... but its just a command that takes label names for its arguments. The interrupt command also does this: fnInt(LBL,0) for instance.

alberthrocks · « **Reply #2071 on:** December 17, 2011, 11:39:28 pm »

Quote from: Quigibo on December 17, 2011, 11:30:41 pm

I don't know what you mean by that... but its just a command that takes label names for its arguments. The interrupt command also does this: fnInt(LBL,0) for instance.

Oh.... silly me

I didn't read it quite carefully, and parsed it (get it?) as:

Code: [Select]

Lbl FAKE
Z-Test(r1, 1, 2, 3)
Lbl 1
Lbl 2
Lbl 3
Return

Sorry for my mishap!

The correct example should be this:

Code: [Select]

.SLCTTEST Select-like cmd test
.Should print "Hi!"
MyLbl(0)
Pause 2000
.Should print "Long time, eh?"
MyLbl(1)
Pause 2000
.Should print "Can't wait to!"
MyLbl(2)
Pause 2000
.Should print "Laugh out loud"
MyLbl(3)
Pause 2000
.Should print "It is now Friday"
MyLbl(4)
Pause 2000
Lbl MyLbl
.Just in case...
ClrHome
Z-Test(r1,HI,LTE,CWT,LOL,TGIF)
Return
Lbl HI
Output(0,0,"Hi!")
Return
Lbl LTE
Output(0,0,"Long time, eh?")
Return
Lbl CWTG
Output(0,0,"Can't wait to!")
Return
Lbl LOL
Output(0,0,"Laugh out loud")
Return
Lbl TGIF
Output(0,0,"It is now Friday")
Return

Deep Toaster · « **Reply #2072 on:** December 19, 2011, 01:23:03 pm »

That new progress bar is awesome

And it's great how those really old bugs are now gone all of a sudden.

epic7 · « **Reply #2073 on:** December 19, 2011, 03:29:59 pm »

Ah, Ive found a place where I can use Z-Test

Matrefeytontias · « **Reply #2074 on:** January 04, 2012, 12:44:44 pm »

I try since a little time to define my own token with an Axiom (as you did with Memkit and new(), load() etc), and someone said me that I must use the hook 9BC8 to modify OS tokens' name. But it seems that Axe, with his own hook, erase the current hook, so I can't change tokens like Axe do. Do you think that we'll can define our own tokens with Axioms in your next version ?

kindermoumoute · « **Reply #2075 on:** January 04, 2012, 12:58:31 pm »

Yes, It could be very nice to see token replacements for axioms, because currently it's not intuitive to use commands without any meaning.

Builderboy · « **Reply #2076 on:** January 04, 2012, 01:33:30 pm »

This idea has already been presented and rejected by Quigibo, simply because of speed reasons that would slow down the editing process unfortunately.

Runer112 · « **Reply #2077 on:** January 04, 2012, 01:34:57 pm »

I am fairly certain that it can be done with minimal speed loss if token replacements are somehow cached intelligently. In fact, I'm trying it right now.

Quigibo · « **Reply #2078 on:** January 04, 2012, 08:46:50 pm »

But Axe would also have to parse the original file to find all the axioms each program uses. And I mean an actual parse due to the newly added conditional comments. I could instead require axioms to be at the top of the source but then you would again not be able to use conditional comments on them...

Runer112 · « **Reply #2079 on:** January 04, 2012, 09:07:01 pm »

I think you can safely ignore whether or not the Axiom reference is in a comment. Even if it is, the program probably still uses commands from it somewhere in the source and the token replacement should be used for clarity whether or not it is commented out.

EDIT: And if the programmer is doing crazy stuff like a conditional if-else comment to include only one of two Axioms that replace the same tokens... Well that's a little nuts and I think they can deal with that not being supported.

Freyaday · « **Reply #2080 on:** January 05, 2012, 03:33:51 am »

Quote from: Runer112 on January 04, 2012, 09:07:01 pm

I think you can safely ignore whether or not the Axiom reference is in a comment. Even if it is, the program probably still uses commands from it somewhere in the source and the token replacement should be used for clarity whether or not it is commented out.

EDIT: And if the programmer is doing crazy stuff like a conditional if-else comment to include only one of two Axioms that replace the same tokens... Well that's a little nuts and I think they can deal with that not being supported.

Have you seen optimized Axe code? It is nothing but crazy!
Oh, wait.
(

)

Quigibo · « **Reply #2081 on:** January 05, 2012, 07:02:46 am »

Announcement!

I spent several hours today thinking about the logistics, difficulty, and maintainability of creating an "Axe Shell" and then started to code my ideas. I am pleased to announce that it appears this may become a reality in the next version. I currently have about half the commands working with more to come. I will explain some of the logistic problems I faced later. This will be a beta feature to give me a chance to stabilize potential errors I might have made. It is not recommended to distribute the executable until it stabilizes.

So first of all, what am I talking about exactly? Ion, Mirage, and Doors all have a GUI application to act as a shell but Axe does not and I'm not going to add one either. What I'm referring to, is that instead of copying all the gigantic Axe routines into each program (such as DispGraph, Sprite drawing, Sound, Archive reading, and literally everything non-trivial) the program will use the Axe app itself to find and call the big routines. This of course loses platform independence in a sense, but so do all the other shells. This really isn't a shell though, its more of a framework. Which is why I'm call this the Axe Framework or AXF. With the bulk gone, this can reduce programs by up to 3000 bytes! In general, I'm seeing 10-20% reductions in my testing suite.

Now for some logistics. The way it works is that the program gets the standard ion header plus some extra code to locate the Axe app, show the message "Axe Required" if its not found, and do all the necessarily paging. Its comparable in size to the DCS or App header. This is both so that I don't have to actually create a shell and its small enough for a header anyway. But the looming problem is to map the Axe calls to physical addresses in the app. As I improve and optimize the Axe routines, the addresses will change, causing old executable to need to be recompiled to work. Normally to fix this, the other shells provide a fixed jump table that then jumps from there to whatever moving code it eventually needs to reach. But the problem with Axe is that many routines "hijack" other routines to skip parts of code rendering a fixed jump table unusable. What's worse, the axiom system of replacing absolute and native jumps and calls makes it impossible to execute over it.

To solve both of these, I have a table of subroutine "segments" that have all the code that can be skipped over and then hijack the original routine. Some routines I do have to make complete or partial copies of, but that's alright. In those cases, I leave a bit of buffer for future optimizations and changes. The only other issue I'm worried about is how Axioms will interact with the framework. Most Axioms should work, but a few really complicated ones could fail if they jump into routines past the entry points. But that is super hackish anyway.

Some other things on my mind: I could speed up some routines since the size of the routines no longer matters. Routines like multiplication are easy to unroll, but others like DispGraph are still limited by the screen driver. Also, this framework is just as useful to assembly programmers! I have doubts about how many would actually want to use it though, but nonetheless it is now possible to do that.

Thoughts and suggestions?

thydowulays · « **Reply #2082 on:** January 05, 2012, 07:25:33 am »

This is amazing! I highly doubt you have to worry about anyone not using your stuff Quigbo, especially if it reduces their programs by 3000 bytes. I don't understand all the way though. It uses the Axe app itself to find and call the big routines? Does that mean people won't really notice any difference programming, but there is a huge one? Or there will be a completely new way to program in Axe? Anyways, I definitely support this, and will be getting the executable as soon as it's stable!

TIfanx1999 · « **Reply #2083 on:** January 05, 2012, 08:17:25 am »

That's pretty sweet! If you can manage to make it stable I'm sure programmers will love you for the reduced program size. =)

MGOS · « **Reply #2084 on:** January 05, 2012, 09:20:00 am »

This sounds great so far! I love it when the executeble's size is reduced without having to optimize a lot and make the code unreadable.
But will it be also possible to compile the programs to noshell? Because I like that the executable doesn't need anything else and another app to transfer takes a lot of time. Most of my friends don't understand much about the calculator, they only want to play my games and get confused when they need multiple files ^^ ... Now, it is only one program, they know how to execute it. They don't have watch out to delete accidentally the axe app or so. That was one main reason (beside better speed and graphics) for me to switch from xLib to axe.

Author Topic: Axe Parser (Read 555310 times)

Quigibo

Re: Axe Parser

alberthrocks

Re: Axe Parser

Deep Toaster

Re: Axe Parser

epic7

Re: Axe Parser

Matrefeytontias

Re: Axe Parser

kindermoumoute

Re: Axe Parser

Builderboy

Re: Axe Parser

Runer112

Re: Axe Parser

Quigibo

Re: Axe Parser

Runer112

Re: Axe Parser

Freyaday

Re: Axe Parser

Quigibo

Re: Axe Parser

thydowulays

Re: Axe Parser

TIfanx1999

Re: Axe Parser

MGOS

Re: Axe Parser