• Features Wishlist 5 1
Currently:  

Author Topic: Features Wishlist  (Read 253537 times)

0 Members and 1 Guest are viewing this topic.

Offline parserp

  • Hero Extraordinaire
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1455
  • Rating: +88/-7
  • The King Has Returned
    • View Profile
Re: Features Wishlist
« Reply #2790 on: December 07, 2011, 11:25:18 pm »
Okay, I've mentioned this before, and I'm not sure if it's in 1.0.5 cause I'm still using 1.0.3, but I would really like to say support for appvar absorption, where the source needs the appvar, but the executable doesn't. So, like when you absorb a Pic from TI-OS into an axe program, you go [Pic1]->POINTER, I'd like to see something like [appvANAPPVAR]->POINTER. Does that make sense?
like, when compiling, it takes a copy of the appvar and puts it in the executable?
ticalc.org | Cemetech | TI-Freakware | casiocalc.org

Spoiler For inactive:
Serving an LDS (Mormon) mission from Dec 2014 - Dec 2016

Offline epic7

  • Chopin!
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2200
  • Rating: +135/-8
  • I like robots
    • View Profile
Re: Features Wishlist
« Reply #2791 on: December 07, 2011, 11:27:45 pm »
Oh, I get it.
* epic7 thinks of how he could use that...

Offline LincolnB

  • Check It Out Now
  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1115
  • Rating: +125/-4
  • By Hackers For Hackers
    • View Profile
Re: Features Wishlist
« Reply #2792 on: December 09, 2011, 09:53:12 am »
Yeah, Parser, it's the equivalent of going like this:

Data(1ST_BYTE_OF_APPV,2ND_BYTE_OF_APPV,3RD_BYTE_OF_APPV,etc)->GDB1
Completed Projects:
   >> Spacky Emprise   >> Spacky 2 - Beta   >> Fantastic Sam
   >> An Exercise In Futility   >> GeoCore

My Current Projects:

Projects in Development:
In Medias Res - Contest Entry

Talk to me if you need help with Axe coding.


Spoiler For Bragging Rights:
Not much yet, hopefully this section will grow soon with time (and more contests)



Offline Happybobjr

  • James Oldiges
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2325
  • Rating: +128/-20
  • Howdy :)
    • View Profile
Re: Features Wishlist
« Reply #2793 on: December 10, 2011, 10:26:44 pm »
Big request.  Hopefully easy.

Would there be any chance for an optimized #/A*A command?
That could be super useful to me, and should speed up many sprite routines.
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: Features Wishlist
« Reply #2794 on: December 10, 2011, 10:31:28 pm »
This can already be done in the form #-(^A).

Offline jacobly

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 205
  • Rating: +161/-1
    • View Profile
Re: Features Wishlist
« Reply #2795 on: December 10, 2011, 10:32:09 pm »
#-(#^A)... optimized! ;D

Edit: Wow... ninja'd with a better response :(
« Last Edit: December 10, 2011, 10:33:45 pm by jacobly »

Offline calcdude84se

  • Needs Motivation
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2272
  • Rating: +78/-13
  • Wondering where their free time went...
    • View Profile
Re: Features Wishlist
« Reply #2796 on: December 10, 2011, 10:33:22 pm »
Jacob, the second occurrence of "#" is unneeded ;)
"People think computers will keep them from making mistakes. They're wrong. With computers you make mistakes faster."
-Adam Osborne
Spoiler For "PartesOS links":
I'll put it online when it does something.

Offline Happybobjr

  • James Oldiges
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2325
  • Rating: +128/-20
  • Howdy :)
    • View Profile
Re: Features Wishlist
« Reply #2797 on: December 10, 2011, 10:33:26 pm »
i feel stupid :P
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 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: Features Wishlist
« Reply #2798 on: December 10, 2011, 10:50:15 pm »
Can SortD() be expanded like it in in TI Basic?  For instance, "SortD(Ptr1,Size,Ptr2)" would sort the data at Ptr1 and also sort the data at Ptr2 by the data in Ptr1.  If that doesn't make any sense, here's an example in Basic:

Code: [Select]
{3,2,4,1}->L1
{4,3,2,1}->L2
SortD(L1,L2)
Then L1 and L2 would equal:
Code: [Select]
L1 = {4,3,2,1}
L2 = {2,4,3,1}

I actually needed this in a program I wrote a while back and had to write it myself in Axe, which was actually really, really hard.

This could be expanded to sort up to four lists by each other or so.  I'm not sure what the upper bound here should be.

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: Features Wishlist
« Reply #2799 on: December 12, 2011, 03:25:35 am »
I am going to suggest a very simple change to one of the least used commands to make it more useful.

Problem:
I suspect very few people are using *^ which returns the upper 16 bits of an unsigned multiplication.  The regular * just returns the lower 16 bits.  Actually, the * command computes both of these quantities at the same time but only returns one of them.  So if you have to get the upper and the lower bits of a multiplication, you end up calling the same multiplication twice!

Solution:
I propose that in addition to *^ returning the high bits, it also stores the low bits in another location, for instance r6.  Even more ideally, I feel like it should do the opposite:  return the low bits (identical to regular multiplication) store the high bits to r6.

Issues:
r6 seems like the best option, but no matter what location I pick it could lead to incompatibility.  If I make it return the low bits and store the high bits this will definitely lead to an incompatibility, but optimizes better and is more useful I think.


Consensus?  Especially if you use or ever have used this operation.
« Last Edit: December 12, 2011, 03:25:58 am by Quigibo »
___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: Features Wishlist
« Reply #2800 on: December 12, 2011, 03:44:47 am »
I use that command for some of my more advanced physics, it can be quite useful ^^ This does pose an interesting conundrum though, and I feel the best solution would be to introduce some sort of optional syntax to choose a specific storage location.  Something like 8*^(r1)A->B.  Which would compute 8*^A, store the ordinary part into B, and store the extra part into r1.  It does look a bit messy, but it is a fairly advanced operation

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: Features Wishlist
« Reply #2801 on: December 12, 2011, 04:36:22 am »
Alternatively, I could add access to Axe's temporary buffer through some new token and store it there.  The temporary buffer is an 8 byte buffer used in a few commands that create more data than can fit in an Axe variable such as Pt-Get() and RotC().  All commands so far that use this buffer also return it so it's location hasn't needed to be directly accessed yet.
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline jacobly

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 205
  • Rating: +161/-1
    • View Profile
Re: Features Wishlist
« Reply #2802 on: December 12, 2011, 09:17:16 pm »
Here's an example of how I use it.
Code: [Select]
:r₁∗r₃+(r₂∗^r₃)➔r₁:r₂∗r₃➔r₂

So, my idea is to change the syntax to something like.
Code: [Select]
:r₁∗r₃+(r₂∗^r₃)➔(r₁,r₂) .Basically store high word (plus r₁∗r₃) to r₁, and the low word (not affected by the add) to r₂.
This has the added advantage that ➔( doesn't seem to mean anything in the current version (also, it causes an invalid token error). To compare with what Quigibo suggested, ➔(A,B) would be equivalent to ➔A(or B):<undecided token>➔B(or A), with the advantage of not using another token, and being more intuitive.

Code: [Select]
:r₁∗r₃+(r₂∗^r₃)➔r₁ .This would also work, storing just the high word (plus r₁∗r₃) to r₁, just like before.
:r₁∗r₃+(r₂∗^r₃)➔(r₁,) .maybe same as the last last line, but returns low the low word of the multiplication, rather than the value of r₁?

Spoiler For Implementation:
Use memory:
   Axe.inc:
      axv_Extra        =;MD5Temp, axv_SpriteBuff+6, axv_Y3t, OP1+0..64, whatever
      ; If you are wondering about the axv_SpriteBuff+6, I was thinking that it would be
      ; cool if there were an alternate ▸Dec that put the 5+1 byte string in axv_SpriteBuff.
      ; The leading zeros could even be removed this way (by the routine or in Axe).
      ; The routine/Axe code would just increment the pointer past the leading zeros...
      ; Anyway, my point is that even this wouldn't interfere with axv_SpriteBuff+6,
      ; only the sprite routines would affect it.
   Compiling:
      exp1∗^exp2 compiles to:
         ; load hl and de
         call sub_MulFull
         ld (axv_Extra),hl ; or better yet, put these in MulFull
         ld h,c ; especially if you take Runer's suggestion to break
         ld l,a ; Mul88's reliance on MulFull.
      ➔(var1,var2) compiles to:
         ld (°var1),hl ; only if var1 present?
         ld hl,(axv_Extra) ; always?
         ld (°var2),hl ; only if var2 present?
A cool thing I just noticed, is that both left to right parsing and the old functionality of sub_MulFull are preserved, and as far as I can tell, compatibility is 100% preserved (even with the few Asm( hacks I can think of!) 8)


Or a more optimized idea – use registers:
   Compiling:
      exp1∗^exp2 compiles to:
         call sub_MulFull
         ex de,hl ; or better yet, put these in MulFull
         ld h,c ; especially if you take Runer's suggestion to break
         ld l,a ; Mul88's reliance on MulFull.
      ➔(var1,var2) compiles to:
         ld (°var1),hl
         ld (°var2),de
But of course this is probably way too volatile to be user friendly. (although with peephole... :))
Oh, especially since my Axe code example above wouldn't work!

In the future, this syntax could definitely be useful for new commands that return more than one value.

Lol, I used Axe syntax in assembly :P

On an unrelated note, I just 2nd+Off on the Axe error screen, and now free mem = 0. Shouldn't B_CALL(_GetKeyRetOff) be used here? Unless zStart had something to do with it...

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Features Wishlist
« Reply #2803 on: December 12, 2011, 09:28:38 pm »
The problem with that is such lines of code like:

Code: [Select]
A*^B-5+9/42-{L1+B}->C
You can't override the -> operator because by the time the line reaches that point, it is difficult to tell exactly what should be done with the second number.

Offline jacobly

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 205
  • Rating: +161/-1
    • View Profile
Re: Features Wishlist
« Reply #2804 on: December 12, 2011, 09:50:04 pm »
The number is stored it a "safe" place until it is recalled ;)
It doesn't even have to ever be used.