Author Topic: Axe Parser (Read 551670 times)

ztrumpet · « **Reply #2085 on:** January 05, 2012, 09:57:28 am »

This sounds great.

How does it work when running programs from a shell, such as Doors or Mirage? Does it play nice, or does it just RAM Clear?

C0deH4cker · « **Reply #2086 on:** January 05, 2012, 10:33:06 am »

He said that it has an ion header, so will be executed as an ion program, but there is extra asm code included to access the Axe app's routines, so it should be compatible with all ion-compatible shells.

I assume that this will be another option to compile for, like No shell, Ion, MirageOS, DCS, Axe, App, right?
Furthermore, I believe that with custom token replacements, programmers wouldn't mind going into Axe settings and scrolling through a list of Axioms with custom tokens and doing an "Install custom tokens" process. As long as it is relatively simple, it wouldnt be much of a hassle.

An extra field could be added to axioms that include custom tokens to designate it as one that has them. Then, when the user goes into the token settings in the axe app, only the axioms with the token replacement field would be shown. The user could select which axioms to use for token replacement with checkboxes.

This would lessen the hardship of coding it to automatically parse the program and look for Axiom() and looking through each axiom included for token replacements.

What do you think about this option? Is it viable?

Builderboy · « **Reply #2087 on:** January 05, 2012, 03:35:27 pm »

As long as there is still an option to compile programs normally without the Axe dependency I think this is a great idea ^^

Deep Toaster · « **Reply #2088 on:** January 05, 2012, 03:56:48 pm »

AXF sounds like a great idea, especially how it cuts down so much of a program's size. The biggest problem I can see is the confusion this could cause for users who download games made with Axe. There would essentially be two sets of Axe programs, those that require the Axe shell and those that do not, and people could get confused by that.

My suggestion is that AXF be released under a totally different name, even though the language it uses is called "Axe." I think AXF programs should be categorized separately from ordinary Axe programs (such as on ticalc), and if possible to have Axe and AXF games be considered two completely separate types of programs (such as in program descriptions).

ztrumpet · « **Reply #2089 on:** January 05, 2012, 04:07:03 pm »

Quote from: Deep Thought on January 05, 2012, 03:56:48 pm

My suggestion is that AXF be released under a totally different name, even though the language it uses is called "Axe." I think AXF programs should be categorized separately from ordinary Axe programs (such as on ticalc), and if possible to have Axe and AXF games be considered two completely separate types of programs (such as in program descriptions).

I agree with Deep here. The names AXE and AXF are too close to avoid confusion. The shell itself sounds cool, though.

Runer112 · « **Reply #2090 on:** January 05, 2012, 04:54:43 pm »

I've been fantasizing about such a system as this for a long time, as it can be used both to conserve executable size and to allow for the use of larger but faster routines. However, your post wasn't very clear to me regarding one important matter: Will the old compilation style remain?

One thing that always turned me off about some programs is their dependency on a shell, especially when they hardly needed any of the routines in it. Although I always have Axe on my calculator, others may not, and they may not want it. And if you're compiling your code as an app and not right up against the size limit, you can afford to have the routines included in your app.

I think it would be best for Axe users to be able to control exactly how Axe compiles their program: with size-optimized included routines, with speed-optimized included routines, or with speed-optimized external routines. I would then advise programmers to follow logic somewhat like this as a guideline to compile and release their work:

If you are compiling your code to a program
- If you use one or no large routines (e.g. DispGraph, Pt-On())
  - Compile with included routines; optimization style is up to you
- If you use large routines
  - Compile for both included routines (optimization style is up to you) and external routines; include a readme explaining how the two are different and let the user choose
If you are compiling your code to an application
- Compile with speed-optimized included routines
- If the application is too large
  - If speed is important
    - Compile with external routines
  - Compile with size-optimized included routines
  - If the application is too large
    - Compile with external routines

Quigibo · « **Reply #2091 on:** January 05, 2012, 05:33:26 pm »

To clarify, this is simply another option in the shell menu. The ion header is, I feel, the best option for Axe programs because they are compatible with ALL shells and can still be run from the home screen with Asm(). There is not currently a way to use the external routines from an app, although I could add another option for that later. Runer, as much as I agree that that would be ideal for advanced users, its quite complicated to implement and would be confusing to new users. I would like to keep it as simple as possible for the user and have Axe determine these things automatically with common case defaults.

I am actually almost out of space in the Axe app as of now. The first page (all executable code) is completely full and I have to optimize sections of code just to add more features. The 2nd page (all data) only has about 3kb of space which is not a lot for future expansion. I will have to consider paged calls to the 2nd page soon if I can't find more things to optimize.

I have not tested this with Mirage or Doors yet. I assume they will work, but you might have to disable interrupts at the start of the program (or I might have to add that as part of the header).

Quote

I highly doubt you have to worry about anyone not using your stuff Quigbo, especially if it reduces their programs by 3000 bytes.

I was referring to asm programmers not wanting to use it because usually they have different IO preferences and don't like dependencies. But I guess people did use the ion routines so maybe it could still be useful to them.

I guess I could change the name then. I was originally thinking of calling it "Axis" but that has the same issue. How about "Toolbox"? Its kinda related physically since it's a 'box' around an 'axe'. I dunno, does anyone have other ideas for one?

ztrumpet · « **Reply #2092 on:** January 05, 2012, 09:27:21 pm »

Quote from: Quigibo on January 05, 2012, 05:33:26 pm

The ion header is, I feel, the best option for Axe programs because they are compatible with ALL shells and can still be run from the home screen with Asm().

I saw the "ALL" in all caps and I felt the need to point out not all shells work; all major, current shells do, but I'm pretty sure shells like CrunchyOS do not.

Edit: I think it's probably too close, but I just though of the name AxLE - the Axe Language Extender.

TIfanx1999 · « **Reply #2093 on:** January 05, 2012, 09:33:51 pm »

I think AXF is fine IMHO.

Freyaday · « **Reply #2094 on:** January 05, 2012, 10:01:03 pm »

Sounds cool! I really like the idea of having options to compile with Speed ops, size ops, or external commands.
Name Ideas:
Tree
Hatchet
Chainsaw

parserp · « **Reply #2095 on:** January 05, 2012, 10:04:05 pm »

Quote from: Freyaday on January 05, 2012, 10:01:03 pm

Name Ideas:
Tree
Hatchet
Chainsaw

O.o
maybe it could be called umm, ?

Happybobjr · « **Reply #2096 on:** January 06, 2012, 12:14:21 am »

anything on improving speed makes me happy

Deep Toaster · « **Reply #2097 on:** January 06, 2012, 09:38:02 am »

Quote from: Happybobjr on January 06, 2012, 12:14:21 am

anything on improving speed makes me happy

I don't think it would make programs any faster, but I may be wrong. It could make them much smaller though.

kindermoumoute · « **Reply #2098 on:** January 06, 2012, 10:35:13 am »

I don't think I'll use this framework, but it could be nice.
But currently, why not try to use GUI application of DCS7, mirage OS,... when the shell is selected in Axe parser option ?

Metallica · « **Reply #2099 on:** January 06, 2012, 12:13:57 pm »

I agree with Kindermoumoute. That would be a great idea.

Author Topic: Axe Parser (Read 551670 times)

ztrumpet

Re: Axe Parser

C0deH4cker

Re: Axe Parser

Builderboy

Re: Axe Parser

Deep Toaster

Re: Axe Parser

ztrumpet

Re: Axe Parser

Runer112

Re: Axe Parser

Quigibo

Re: Axe Parser

ztrumpet

Re: Axe Parser

TIfanx1999

Re: Axe Parser

Freyaday

Re: Axe Parser

parserp

Re: Axe Parser

Happybobjr

Re: Axe Parser

Deep Toaster

Re: Axe Parser

kindermoumoute

Re: Axe Parser

Metallica

Re: Axe Parser