Get first/second byte of r-variable easily

[defmenge]

I know this is a quite noobish question, but is there an easy way to access the first/last 8 bits of a parameter passed to a subroutine without using {°r2} and {°r2+1}? The reason I need this is that I use 2-byte-variables for position data in my DROD8x project, 1st byte is for X, 2nd is for Y, and using {°r2} and {°r2+1} (with both r2 and r3) several times in a line gets pretty confusing as the project's complexity increases. I'm pretty sure that people had to be able to do this somehow before "°" was introduced to Axe, and it doesn't look like the most optimized way of accessing the bytes.

Thanks in advance,
Defmenge.

[aeTIos]

I answer with some code:

Code: [Select]

r1 → {L1}^r (radians r)
Now the first byte is stored in {L1} and the second in {L1+1}

Correct me if I'm wrong.

[defmenge]

Thank you for the fast reply.

So I guess there is no built-in command for easily accessing the bytes then; the reason I asked this question was that I thought there would be some weird undocumented command for easily doing that, like "{r1r}", or something similar. Actually, my code for the roach AI (which did not work right) became so complicated that I had no other choice but to rewrite it from scratch. Now I'm using the method you described, which does seem to make it easier to read and edit the code, thanks.

[aeTIos]

to avoid confusion at your side in the future: all commands are documented.
Also, have you introduced yourself?

[Ashbad]

I answer with some code:

Code: [Select]

r1 → {L1}^r (radians r)
Now the first byte is stored in {L1} and the second in {L1+1}

Correct me if I'm wrong.

Right, but make sure you remember that one radian denoted little endian, to do big endian you would denote two radians.

[defmenge]

to avoid confusion at your side in the future: all commands are documented.
Also, have you introduced yourself?

You're probably right about the commands, but I've seen some undocumented functions, such as "sub(" returning a value to the caller of the function. The Axe manual/reference only covers the fact that you can call a subroutine with it, but not that (and how) it can return something.
And I haven't really introduced myself because I have no idea what to write about myself ^^'.

[ralphdspam]

It is strongly discouraged that you not use these undocumented features for the fact that they most likely change. 
The value it is "returning" is just whatever was left in register HL at the time.  Since it is an undocumented (and most likely unintentional) feature, further optimizations to the routines may use HL differently. 

[calc84maniac]

It is strongly discouraged that you not use these undocumented features for the fact that they most likely change. 
The value it is "returning" is just whatever was left in register HL at the time.  Since it is an undocumented (and most likely unintentional) feature, further optimizations to the routines may use HL differently. 

That feature is very intentional.

[yrinfish]

Yes, and not using it would be really #$^%%$ thing to do!!

(I'd have to rewrite all my programs, for example)

And even if it was unintentional, it is too useful to remove!

[aeTIos]

I dont think he'll remove it. just because it'll break 1 out of 2 optimizations...

[Ashbad]

Yeah, it is very intentional and getting rid of that will really screw up the rest of the parser.  It's very useful for using lambdas and procs in Axe.

[aeTIos]

explain lambda and procs (I know what a lambda is, but that isnt meant here I think)

[Quigibo]

To answer the original question:

Code: [Select]

r1/256
r1^256
The top one gets the high 8 bits and the bottom one gets the low 8 bits.  Although {^or1+1} is slightly more efficient than r1/256 currently, but it could eventually auto-optimize in later versions.

[AngelFish]

As nice as it is to use HL, when you need to pass parameters back, chances are you'll end up storing it in a variable at some point. If you define a specific set of variables to be used for parameter passing, then your subroutine is no different than an object in OO language.