CLR required before LDAX?

[Ant]

Hi all,
Just wondering, is is necessary to wipe the accumulator before loading a value with LDAX (or other instructions that take "fresh" data) or is it safe to use without (ie. does it automatically wipe the accumulator first when you use LDAX anyway)?
Cheers,
Ant

[frank]

No need to clear before an LDAX. Actually an LDAX is an RDFX with C=0.

[Ant]

Great thanks Frank.

Slightly off topic, is there a way to load an arbitrary number into the acc without reading from a register? I see with sof that the offset constant "D is not intended to become used for integer arithmetic". I'm trying to save on instructions at points in my code where I already know what value needs to be loaded into the acc without reading it from elsewhere. My current specific purpose is for writing a binary number (essentially three flags) to another register. Is it possible to "cast" the value of D somehow so that the raw binary can be used to represent those three bits or is it more efficient to simply read the value from a register beforehand?

[frank]

Unfortunately the assembler does not allow hex for S.10, I did not write it so not my fault

This should work:
equ alpha %0_11_1000_0000 ; three flags just below sign bit
sof 0,alpha/1023 ; divide by 1023 to make assembler happy

If the ACC is already 0 then use OR

[Ant]

Ah thanks. Is there any reason why we can't just use something like this for values that are going to be used as a bit mask?

alpha EQU %00000000_00000000_0000111

[frank]

Well the bits you set are below the range of a S.10 format number so I believe the assembler would strip them off.

[Ant]

Hmmm. Excuse my ignorance but I'm quite confused by the formats allowed here. For logic operations, the manual specifies a 24 bit mask (I'm aware that I missed a zero in my last post...), so where does the S.10 format come from? Is it something inherent to the EQU statement? This is my first foray into assembly language so I'm used to much more forgiving variable assignments...

[Sweetalk]

In the Spin Asm manual you have it explaned, on the Operand data Types part:

Signed fixed point values are primarily used as coefficients (Operand2) for the multiply portion of an
instruction. Depending on the actual opcode they may be in one of three different formats, "S1.14", "S1.9"
and "S.10".
"S1.14" means that the 16 bit coefficient has one sign bit (MSB), one integer bit left to the binary point
followed by 14 fractional bits right to the binary point. "S1.9" denotes an 11 bit coefficient which differs
from "S1.14" in that it has fewer bits available to represent the fractional portion of the signed fixed point
value (lower resolution). Last but not least the "S.10" format is also a 11 bit coefficient, however in
comparison to the "S1.9" format its higher fractional resolution comes at the expense of lacking the
integer bit (smaller range). Here's a quick overview regarding range and resolution of the three different
coefficient formats.

The S.10 format varies from -1 to 0.9990234375, with a resolution of 0.0009765625. So, it's 11 bits, 1 bit for the integer and the other 10 for the fractional part. From them you can make your mask properly.

[Ant]

Thanks for your reply Sweetalk.
I understand what S.10 etc mean but the manual doesn't explain how to convert a value from one of those to the 24-bit mask that is required. The manual actually explains that a 24-bit mask is reqd for the logic operations, so I presumably need to feed those 24-bit, not 11-bit, operands. Where does this S.10 format come into it? Is that the format reqd for EQU statements? If so, how can that be converted into a 24-bit value without knowing the format of those 24 bits?

[frank]

OK, I missed it was for the bit mask I thought it was for the SOF.

You need to make sure the bits will align so if you use SOF to load the ACC you need to make sure the bits in the mask align with the S.10 number even if it is a 24-bit mask.

I.e if you put %0_00_0000_0111 into ACC with the SOF all bits below this will be 0 so then the bit mask must be %00000000_11100000_0000000 so the bits all align.

[Ant]

Ahhh I see cheers. So just to clarify, I can assign the 24 bit value using the EQU statement, and that will be fine for AND/OR/XOR, but for sof etc the compiler will simply bin the last 13 bits so I need to make sure my flag bits occur within the first 11 bits?

The sof was really just a way that I might be able to get a number into the accumulator. I've come to realise that it's actually easier to simply assign the number using an EQU statement then refer to that value symbolically (ie one fixed EQU statement for each of the eight possible flag arrangements, then another for a FLAGS register that will be updated as the program runs).

[frank]

Ahhh I see cheers. So just to clarify, I can assign the 24 bit value using the EQU statement, and that will be fine for AND/OR/XOR, but for sof etc the compiler will simply bin the last 13 bits so I need to make sure my flag bits occur within the first 11 bits?

That is a good question actually, since I did not write the FV-1 assembler I do not know the order of operations on numbers and the internal representation so it may or may not work trying to pass a 24-bit number to SOF even if the bits are in the right place. This is because we let people mix integer, decimal, etc. in the code.

To be safe set the mask for the SOF using 11 bits and the one for the AND/OR/XOR as 24-bits, just write them over each other in the code to make sure the bits stay aligned:
%00000000_11100000_00000000
%00000000_111

Or just try it and if it fails then we know it is doing any truncation after range checking.

Things like the "_" are just to help make things human readable so you can more it around to make the code clearer.