• Features Wishlist 5 1
Currently:  

Author Topic: Features Wishlist  (Read 669574 times)

0 Members and 2 Guests are viewing this topic.

Offline Zemmargorp

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 115
  • Rating: +7/-2
  • Either programming or thinking of it.
    • View Profile
Re: Features Wishlist
« Reply #3405 on: August 28, 2014, 01:32:24 pm »
No, #Realloc already has an opening parenthesis so #Realloc(0)r would be .org 0 and you could do #Realloc(L3)r if you wanted :)
Then it's fine, #Realloc( is a good token for your idea. And the syntax #Realloc()r could be added to restore the previous origin (before changing to 0 or L3), which should be done automatically at the end of any library/subprogram.
I'm french, that's the reason why my English can be a bit approximate.

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: Features Wishlist
« Reply #3406 on: August 28, 2014, 02:54:00 pm »
We're saying #Realloc() already serves another purpose. It's used to relocate the A-θ vars to another address. For instance, #Realloc()r and #Realloc()rr would probably work.

I've talked to Runer112 about it some time ago, and he said the PC was very hackish in the Axe compiler, so adding those features is very unlikely to happen before Axe 2.0.

Offline Zemmargorp

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 115
  • Rating: +7/-2
  • Either programming or thinking of it.
    • View Profile
Re: Features Wishlist
« Reply #3407 on: August 29, 2014, 09:02:57 am »
We're saying #Realloc() already serves another purpose. It's used to relocate the A-θ vars to another address. For instance, #Realloc()r and #Realloc()rr would probably work.

I've talked to Runer112 about it some time ago, and he said the PC was very hackish in the Axe compiler, so adding those features is very unlikely to happen before Axe 2.0.

Yes, we were talking about using the r modifier, I just said that the token #Realloc( was a good token for this command. Let me guess : PC is calculated from the current position of the data in the compiled program, or at least is linked with it ? Well, it seems that there's a lot of work to do for Axe 2.0...

Something else : as using the r modifier on a variable only use its first byte, we could be able to do For(VARr,MIN,MAX) (or designed another way, probably better : For(VAR,MIN,MAX)r). Maybe also do the same for big-endian, with rr.
I'm french, that's the reason why my English can be a bit approximate.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Features Wishlist
« Reply #3408 on: September 02, 2014, 06:55:10 pm »
Sorry for the lack of responding. I was both physically and somewhat mentally ill for a while, so I ceased basically all activities outside of eating, sleeping, and entertainment. Anyways...


In response to changing the code origin, as you guys have correctly figured out, Axe does indeed calculate PC directly from the offset in the compiled program. Making this user-controllable would probably be tricky from an implementation standpoint. There's also the important goal that I'd like to see Axe become higher-level over time rather than lower-level, an adding manual code origin control is quite contrary to this.

That's not to say this capability cannot be added, though. Since the theoretical Axe 2.0 looks a lot like C in my head, it should support functions. Both function and data definitions could support keywords or something similar that specify origin, which I believe would provide the functionality needed for most uses in a pseudo high-level fashion.

Something else : as using the r modifier on a variable only use its first byte, we could be able to do For(VARr,MIN,MAX) (or designed another way, probably better : For(VAR,MIN,MAX)r). Maybe also do the same for big-endian, with rr.

I've imagined the code for a for loop with a one-byte variable in my head for a bit now and am of the opinion that the general result would probably be larger than a for loop using a two-byte variable. The problem is that Axe has to evaluate the minimum and maximums as two-byte values in HL because that's the only way it knows how to evaluate arbitrary expressions, so the potential savings of using a one-byte value and arithmetic are killed by the conversions between one- and two-byte values. (Side note: it may seem like the For(EXPR)r command has no reason to exist for similar reasons, but the difference is that once the two-byte value is converted to a one-byte value at the start, all following operations are one-byte only)

If both the minimum and maximum were constants, then all the logic could certainly be coded in smaller one-byte operations. But in the case that the compiler is special-casing for loops with constant bounds anyways, there's little point for the alternate one-byte syntax because it could automatically check if both constants are one-byte values and, if so, use one-byte operations.
« Last Edit: September 02, 2014, 06:59:32 pm by Runer112 »

Offline Zemmargorp

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 115
  • Rating: +7/-2
  • Either programming or thinking of it.
    • View Profile
Re: Features Wishlist
« Reply #3409 on: September 03, 2014, 10:43:57 am »
Something else (again) : allow to specify a step in loops, and optimize this when MIN, MAX, and/or STEP are constant. It was maybe not added to Axe because (I suppose) using While correctly instead could be more optimized, but writing For(VAR,MIN,MAX,STEP) is definitely nicer than writing the following code (which can be optimized in some special cases, for instance when (MAX - MIN) is a multiple of STEP  ;)) :

Code: (Quite ugly) [Select]
MIN
While -->VAR < MAX
.INSET CODE HERE
VAR+STEP
End
I'm french, that's the reason why my English can be a bit approximate.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Features Wishlist
« Reply #3410 on: September 03, 2014, 03:57:33 pm »
That should definitely exist, yes. I can't really remember why it doesn't... I guess I can try it at some point.

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: Features Wishlist
« Reply #3411 on: September 03, 2014, 05:12:54 pm »
Sorry to hear about the health issues Runer112. I hope nothing too bad (socially or physically) happened that caused this. D:

Offline Zemmargorp

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 115
  • Rating: +7/-2
  • Either programming or thinking of it.
    • View Profile
Re: Features Wishlist
« Reply #3412 on: September 20, 2014, 10:00:10 am »
Sorry to hear about the health issues Runer112. I hope nothing too bad (socially or physically) happened that caused this. D:
Oh, I didn't pay attention to the beginning of his message ! Runer112, I hope you're better now.

Here's another idea of feature to add to Axe Parser : when it doesn't find a library, it could search for it in groups. That'd be great for people who have a lot of libraries and don't want them to be shown in the program list, or when they're working on a single program from a big project split in multiple programs. Both are often my case  ;D !
I'm french, that's the reason why my English can be a bit approximate.

Offline Zemmargorp

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 115
  • Rating: +7/-2
  • Either programming or thinking of it.
    • View Profile
Re: Features Wishlist
« Reply #3413 on: October 08, 2014, 10:46:29 am »
I was wondering if it would be interesting to do changes in some Axe functions to avoid as much as possible minor problems with the OS. For instance, when I use drawing functions, the graph is not marked dirty, so when after exiting the program I use the graph the curves drawn are mixed with the program's picture.

As, for a lot of reasons, Axe wouldn't be able to determine if the buffer is without fail changed during the program's execution (unless it would add a "mark graph dirty" after each drawing instruction, which is not a good idea), then why not adding a command which would mark the graph dirty ? Maybe rename a token like RecallGDB (which is not used yet) "DirtyGDB".

There might be other small "compatibility issues" like this one with the OS, but I don't have any other example.
I'm french, that's the reason why my English can be a bit approximate.

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: Features Wishlist
« Reply #3414 on: October 09, 2014, 01:03:45 am »
I am unsure if those are really Axe issues, because they are present in ASM too if you aren't exiting from your programs properly, not to mention that some people use such program as sub-routines and might not be willing to see the program clear the graph screen background image for them. I think that for that reason, it is generally assumed that it's the programmer's job to prevent such issues from happening.

I think that making the program require a shell usually helps in certain situations, though.
« Last Edit: October 09, 2014, 01:06:05 am by DJ Omnimaga »

Offline Zemmargorp

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 115
  • Rating: +7/-2
  • Either programming or thinking of it.
    • View Profile
Re: Features Wishlist
« Reply #3415 on: October 09, 2014, 01:23:49 pm »
I am unsure if those are really Axe issues, because they are present in ASM too if you aren't exiting from your programs properly, not to mention that some people use such program as sub-routines and might not be willing to see the program clear the graph screen background image for them. I think that for that reason, it is generally assumed that it's the programmer's job to prevent such issues from happening.

I think that making the program require a shell usually helps in certain situations, though.

Well, indeed, they aren't Axe issues, almost all assembly programs using graphics mess the PlotSScreen memory area (unless they use another memory location, but that's hardly ever the case). But Axe can include a way to fix it.

As you said, it's the programmer's job to prevent this kind of problems from happening, so in the example I made, he would use the DirtyGDB command in Axe, and Axe Parser would add the compiled instruction "mark graph screen dirty" to the compiled program. So when the user comes back to the OS, the full graph will be redrawn, and there'd be no problem such as the cursor moving on the last picture displayed by the program instead of the curve which was drawn before.
However, if he doesn't want the compiled program to mark the screen dirty (because he used the drawing functions in a sub-program), then he should just not use the DirtyGDB command.

I don't see what the problem is ??? , and I'm not sure to have fully understood what you mean, especially your last sentence. Sorry :/ .
I'm french, that's the reason why my English can be a bit approximate.

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: Features Wishlist
« Reply #3416 on: October 09, 2014, 03:37:01 pm »
Oh I meant that DCS and Mirage erases the game graphics  from the screen upon exiting.

Offline Zemmargorp

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 115
  • Rating: +7/-2
  • Either programming or thinking of it.
    • View Profile
Re: Features Wishlist
« Reply #3417 on: October 11, 2014, 10:26:19 am »
Oh I meant that DCS and Mirage erases the game graphics from the screen upon exiting.

I doubt they really mark the graph screen as dirty... Do you know what they exactly do ?
Clearing the current display and/or the text screen ? Clearing the graph screen ? Mark it dirty ?


EDIT : I tried with MirageOS, and just remembered the app itself uses the PlotSScreen area, so indeed, it marks it dirty, whether the program uses it or not ! The downside or compiling your sources for a shell is that you need it shell the program. And if someone uses your program with a Mirage-compatible shell which does not mark the graph screen dirty, then compiling it for MirageOS was a bit useless !

However, people would better add a DirtyGDB instruction to programs that uses the graph screen instead of compiling it for any shell : adding this instruction will only add a few bytes to the compiled program, which won't require any dependency, whereas compiling it for MirageOS adds 37 bytes for the program header, and the shell is required to shell the program !
« Last Edit: October 11, 2014, 10:59:49 am by Zemmargorp »
I'm french, that's the reason why my English can be a bit approximate.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Features Wishlist
« Reply #3418 on: October 11, 2014, 11:59:07 am »
That command definitely makes sense to add. The only thing I'd think about is if there's potentially a token that makes more sense, but none spring to mind.

Offline Zemmargorp

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 115
  • Rating: +7/-2
  • Either programming or thinking of it.
    • View Profile
Re: Features Wishlist
« Reply #3419 on: October 13, 2014, 01:10:23 pm »
That command definitely makes sense to add. The only thing I'd think about is if there's potentially a token that makes more sense, but none spring to mind.

Well, I don't have any other idea either, but this one seems fine to me... Using the RecallGDB token would put the DirtyGDB instruction close to StorePic, RecallPic, and StoreLCD ;), so it's good for programs which use graphics commands. (Otherwise it would also be possible to use DispTable which is just next to DispGraph, but this one is less logical.)

By the way, do you know if there are other cases where Axe instructions can cause some minor issues (but easy to fix) with the calculator's OS ? I thought of this one because I often use the graph screen in my programs, but there may be other cases similar to this one.
I'm french, that's the reason why my English can be a bit approximate.