VFP advice/tutorial

note that unlike e.g. VCGE, the ARMv8 ARM doesn’t list any aliases for these. So I’m not planning on adding any NE|LT|LE|VC aliases to the BASIC assembler

cond […] The condition codes for VSEL are limited to GE, GT, EQ and VS, with the effect that LT, LE, NE and VC is achievable by exchanging the source operands.

Because the nature of VSEL is not the same as VCGE I think it would be a pity not to implement the inverse conditions for BASIC.

I have been to the ARM documents

Link please? The copy of the ARMv8 ARM I’m looking at only has two bits reserved for the condition code, and lots of comments saying “Cannot be conditional” since the instruction does one action if the condition passes and one action if it fails (unlike regular conditional instructions which do no action if the condition fails)

This is where I have been looking:

It is a confusing situation. ;-)

Edit: I am happy to document the instructions either way. Indeed, my first draft does treat them as separate instructions.

I was hoping you’d link to a specific page/section, rather than the entirety of ARM’s documentation website ;-)

Searching for the text you quoted leads me to the Cortex-M docs, where it does indeed say that VSEL has an optional condition code. But I think that must be a typo, since it then goes on to list the 4 condition codes supported by the instruction set, and the 4 inverse codes that can be obtained by swapping the arguments. And in neither of those sets is there an “AL” condition code, so if you were to omit the condition code then there’s no telling what would happen (maybe they’re expecting the assembler to replace the instruction with a simple unconditional VMOV?)

In any case, the armasm docs show that the condition code is mandatory, and they only list the four main codes – no mention of how you (or the assembler) can swap arguments to get four more, suggesting that the assembler doesn’t support that functionality.

I was hoping you’d link to a specific page/section

It uses frames, so tricky. ;-)

if you were to omit the condition code then there’s no telling what would happen

That is the pertinent question, as well as the other unrecognised conditions. Presumably it would be up to the assembler to flag the omission – which is really treating these as separate instructions.

The copy of the ARMv8 ARM I’m looking at only has two bits reserved for the condition code

Those will specify a condition to be matched – what will happen if it is not matched in ASPR? I would assume that will be nothing.

It does look like the ARM documentation is at odds with itself. I will document them as separate in the manual.

The copy of the ARMv8 ARM I’m looking at only has two bits reserved for the condition code

Those will specify a condition to be matched – what will happen if it is not matched in ASPR? I would assume that will be nothing.

As I say in my docs:

Set destination to the first operand if the condition is true (according to the PSR), second operand if the condition is false

Or as the armasm manual states:

The VSEL instruction compares the values in the operand registers. If the condition is true, it copies the value in the first operand register into the destination operand register. Otherwise, it copies the value in the second operand register.

Or as the ARMv8 ARM states:

Floating-point conditional select allows the destination register to take the value in either one or the other source register according to the condition codes in the APSR.

i.e. VSELEQ A,B,C is equivalent to VMOVEQ A,B followed by VMOVNE A,C

I had a look at the armasm manual – it is just not the same as the other. As you point out, it also says:

The VSEL instruction compares the values in the operand registers.

Surely that conflicts with:

according to the condition codes in the APSR

The first of these is similar to the way VAC??/VC?? work, but I do not think that is correct, and it could not generate VS.

Anyway, I know what to do for the SH manual and I will let ARM look after themselves. ;-)

Hmm, well spotted! So it looks like the armasm manual is wrong as well. FWIW the pseudocode in the ARMv8 ARM is:

if dp_operation then
  D[d] = if ConditionHolds(cond) then D[n] else D[m];
else
  S[d] = if ConditionHolds(cond) then S[n] else S[m];

ConditionHolds checks the NZCV flags in the PSR, and ‘cond’ is a usual 4-bit condition code that’s been reconstructed from the 2 bits in the instruction.

The first of these is similar to the way VAC??/VC?? work, but I do not think that is correct, and it could not generate VS.

VS comes from the way that VFP handles comparisons (which I think might not be the same as how FPA handled it).

https://community.arm.com/processors/b/blog/posts/condition-codes-4-floating-point-comparisons-using-vfp

VS comes from the way that VFP handles comparisons

“I knew that!” – at least, I have documented it. ;-)

[VSEL] Set destination to the first operand if the condition is true (according to the PSR)

Just to be certain, in the light of the confusion: APSR not FPSCR.

unlike e.g. VCGE, the ARMv8 ARM doesn’t list any aliases for these [VSEL]

While browsing the ARM docs I found the reference that VCLE and VCLT are, as you say, not instructions in themselves, but aliases of VCGT and VCGE, dealt with by the assembler swapping vectors. The same for VAC. Should this be documented in the manual?

Just to be certain, in the light of the confusion: APSR not FPSCR.

Correct.

While browsing the ARM docs I found the reference that VCLE and VCLT are, as you say, not instructions in themselves, but aliases of VCGT and VCGE, dealt with by the assembler swapping vectors. The same for VAC. Should this be documented in the manual?

Yes, I’d say so. BASIC assembler supports them (and I’d assume ObjAsm too). Just remember that it’s only the two-register versions which have aliases, not the register-and-zero versions.

VFP

-



VRINT<A|M|N|P|R|X|Z>.F64.F64 <Dreg>,<Dreg>

VRINT<A|M|N|P|R|X|Z>.F32.F32 <Sreg>,<Sreg>



Round a floating point value to integer, with specified rounding mode.

Addendum: the R, X & Z forms are conditional instructions. A, M, N & P are unconditional.

I have uploaded version 0.40 of the StrongHelp VFP manual to:

Please let me know of bugs and mistakes.