Author Topic: Features Wishlist (Read 683550 times)

parserp · « **Reply #2790 on:** December 07, 2011, 11:25:18 pm »

Quote from: buttsfredkin on December 07, 2011, 11:20:50 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?

epic7 · « **Reply #2791 on:** December 07, 2011, 11:27:45 pm »

Oh, I get it.

* epic7 thinks of how he could use that...

LincolnB · « **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

Happybobjr · « **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.

Runer112 · « **Reply #2794 on:** December 10, 2011, 10:31:28 pm »

This can already be done in the form #-(^A).

jacobly · « **Reply #2795 on:** December 10, 2011, 10:32:09 pm »

#-(#^A)... optimized!

Edit: Wow... ninja'd with a better response

calcdude84se · « **Reply #2796 on:** December 10, 2011, 10:33:22 pm »

Jacob, the second occurrence of "#" is unneeded

Happybobjr · « **Reply #2797 on:** December 10, 2011, 10:33:26 pm »

i feel stupid

ztrumpet · « **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.

Quigibo · « **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.

Builderboy · « **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

Quigibo · « **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.

jacobly · « **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:

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...

Builderboy · « **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.

jacobly · « **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.

Author Topic: Features Wishlist (Read 683550 times)

parserp

Re: Features Wishlist

epic7

Re: Features Wishlist

LincolnB

Re: Features Wishlist

Happybobjr

Re: Features Wishlist

Runer112

Re: Features Wishlist

jacobly

Re: Features Wishlist

calcdude84se

Re: Features Wishlist

Happybobjr

Re: Features Wishlist

ztrumpet

Re: Features Wishlist

Quigibo

Re: Features Wishlist

Builderboy

Re: Features Wishlist

Quigibo

Re: Features Wishlist

jacobly

Re: Features Wishlist

Builderboy

Re: Features Wishlist

jacobly

Re: Features Wishlist