VFP advice/tutorial

I have been looking back through the forum and at many other sites, but I feel that I just do not have enough confidence to use VFP – I do not want to use NEON any time soon.

Firstly, there was mention of the VFP support module a couple of years back, but the link in those early posts no longer works, nor does a site search. The module is listed by *Modules, but is there documentation?

Second, the BASIC assembler was updated to use the new mnemonics, but it does not provide any help. When this was discussed a year or so ago, I produced a trial BASICHelp module with space to include VFP and NEON help. I feel now that I could probably fill in some of those spaces myself, but would be happier if a more knowledgeable person did it. Is this a project worth pursuing, or is there the prospect of the BASIC/BASICTrans modules being worked on soon?

Lastly, there is a scattering of VFP assembler code around, but it is not of a tutorial nature. I would really like some simple BASIC assembler examples to get me going. As VFP does not have the transcendental functions of the FPE, any VPF code that does that would also be very handy.

I have seen that Charm could be used to produce VFP code, but that would need me to learn Charm. ;-)

… a scattering of VFP assembler code around … would really like some simple BASIC assembler examples

Did your search find these? (I can’t remember whether or not they’re BASIC assembler and can’t check now.)

• Mandelbrot Fractal VFP version
• NEON-optimised metaball demo
• Some Updates and a tunnel demo

As for the VFPSupport documentation, has VFPSupport vanished too?

As for the VFPSupport documentation, has VFPSupport vanished too?

The link suggests it does not exist. That does not mean it speaks the truth.

Did your search find these?

More or less. I do not want NEON, nor VFP for vectors, but I would like to see how it compares to the FPE for convenience and speed. The examples use ExtASM; I found them a bit tricky to follow.

As for the VFPSupport documentation, has VFPSupport vanished too?

The link suggests it does not exist. That does not mean it speaks the truth.

I get the feeling those pages vanished because they weren’t linked to from any other wiki pages. Although in the case of the VFPSupport page it took a long time for them to get deleted!

No matter; I should be able to recreate it (and finally split it up into one page per SWI) when I get home.

No matter; I should be able to recreate it

Good job you keep copies/have things committed to memory!

Recreated

It turns out I didn’t have a local copy of the page, so there might be one or two details missing compared to the original (e.g. I think the original mentioned which errors were returned by calls). But I think this new version is a bit more descriptive than the old one.

Hi,

So looking at this – "If a program attempts to execute a VFP/NEON instruction without having a context active then the instruction will abort. – if I wanted to put together a short single tasking program to test various VFP/NEON instructions, I need to wrap it in context SWIs?
What is the least I can get away with? I’m guessing CreateContext in user mode app space, followed by DestroyContext at the end?
What happens if the program errors out in the middle? How do you pick up a dangling context?

Many thanks to Jeffrey in recreating the pages. It still leaves me stuggling a bit, and Rick’s comment echoes my request for some tutorial examples. It is clearly not as ‘simple’ as using the FPA/FPE.

My interest lies in providing double precision floats in Basalt, working within BASIC V. The FPE is very slow for this, but I suspect the context switching might make VFP a bit cumbersome, too.

Any further thoughts on providing BASIC help?

if I wanted to put together a short single tasking program to test various VFP/NEON instructions, I need to wrap it in context SWIs?

Yes.

What is the least I can get away with? I’m guessing CreateContext in user mode app space, followed by DestroyContext at the end?

CreateContext, with user mode flag, letting VFPSupport allocate the memory is probably the simplest (and DestroyContext to get rid of it at the end). That way you won’t have to worry about the application space flag or allocating the context memory yourself.

What happens if the program errors out in the middle? How do you pick up a dangling context?

The same way you should deal with file handles, RMA allocations, network sockets, etc – register environment handlers (or for BASIC use ON ERROR) and make sure your code cleans up after itself.

Ideally the OS would be capable of cleaning up this kind of thing for you, but teaching the kernel about process creation/destruction is a task for another day.

My interest lies in providing double precision floats in Basalt, working within BASIC V. The FPE is very slow for this, but I suspect the context switching might make VFP a bit cumbersome, too.

As you are working within the realm of BASIC itself, would it not suffice to create a VFP context when a program is initialised, and destroy it when the program quits? Not sure how this works with the Wimp re. task switching, but one could argue that managing VFP contexts is a job for this task switcher to do, not the underlying application… [much as how it preserves FP right now – indeed this could be bolted into the existing FP code, couldn’t it?]

Not sure how this works with the Wimp re. task switching

The Wimp will switch VFP contexts automatically (unlike with FP, where you actually need to set a flag to get the FP registers to be preserved over Wimp_Poll!)

Does this work on a Pi?

I wanted to put together some example code, however…

SYS "VFPSupport_CreateContext", ((1<<31)+1), 32, 0, 0 TO cntx%
replies “A requested VFP/NEON feature is unavailable”. I’ve tried various permutations of flags in R0. Same story.

…?

The Raspberry Pi has a VFP2 so only has 16 registers, VFP3 has 32. Try changing the 32 to 16. It should then work on OMAP3 and 4 as well.

I give up.
No matter how I try the FMULS instruction, it keeps throwing an error – apparently it isn’t a real/known instruction? Comment out that line, the rest works.
I have assembled it as an EQUD because I didn’t get any joy with the VFP part of the assembler (having differently named instructions compared to the ARM ARM didn’t help either…).

ON ERROR PRINT REPORT$+" at "+STR$(ERL):END
DIM c% 255 : REM More than enough.

FOR l% = 0 TO 2 STEP 2
P% = c%
[  OPT l%
   ; Set options (non-destructively, preserved in R10)
   VMRS     R10, FPSCR
   LDR      R0, fpscr_data
   VMSR     FPSCR, R0

   ; Set the values for our operation
   ; (4 * 5) = 20
   MOV      R0, #4
   MOV      R1, #5

   ; The first four registers are set to '4'
   VMOV     S0, R0
   VMOV     S1, R0
   VMOV     S2, R0
   VMOV     S3, R0

   ; The second four registers are set to '5'
   VMOV     S4, R1
   VMOV     S5, R1
   VMOV     S6, R1
   VMOV     S7, R1

   ; Multiply 'em ALL in one go ;-)
   ; [ S8=S0*S4 ... S11=S3*S7 ]
   ;VMULS.something   S8, S0, S4
   EQUD     %11101110001000000100101000000010
           ; cond1110pDqr Fn  Fd cp##NsM0 Fm
           ; =AL         |R0||R8|  =S    |R4|

   ; Write 'em back to the ARM side
   VMOV     R0, S8
   VMOV     R1, S9
   VMOV     R2, S10
   VMOV     R3, S11

   ; Restore original SCR
   VMSR     FPSCR, R10

   ; Done
   MOV      PC, R14

.fpscr_data
   EQUD     (3 << 16) ; stride=1, len=4
]
NEXT

SYS "VFPSupport_CreateContext", ((1<<31)+1), 16, 0, 0 TO cntx%
CALL c%
PRINT A%, B%, C%, D% : REM Should say quarce "20".
SYS "VFPSupport_DestroyContext", cntx%, 0

Well, that was the plan. I think I’ll stick with integers. :-/

(having differently named instructions compared to the ARM ARM didn’t help either…)

Use a more recent version which uses the UAL syntax?

Well, that was the plan. I think I’ll stick with integers. :-/

I think part of the problem is that you have stuck with integers. VMOV merely moves data between registers, it doesn’t convert between integer and floating point. You want something like this in the middle:

VCVT.F32.S32 S0,S0
VCVT.F32.S32 S1,S1
VCVT.F32.S32 S2,S2
VCVT.F32.S32 S3,S3
VCVT.F32.S32 S4,S4
VCVT.F32.S32 S5,S5
VCVT.F32.S32 S6,S6
VCVT.F32.S32 S7,S7
VMUL.F32 S8,S0,S4
VCVT.S32.F32 S8,S8
VCVT.S32.F32 S9,S9
VCVT.S32.F32 S10,S10
VCVT.S32.F32 S11,S11

Although even that won’t do exactly what you want, as there are some arcane rules about how vector mode operates, depending on which banks the source and destination registers are in. You will get the output you’re expecting, but it won’t be performing the operation you’re expecting :)

It seems to be tricky. I have not been quite as ambitious as Rick, but using double precision. FMULD (VMULD/VFMULD?) was not recognised. I did get VLDR to be recognised, but VMOV assembles and throws an ‘Undefined instruction’ error. I am, of course, working in the absence of documentation for the BASIC VFP mnemonics, so I could be barking up the wrong tree.

I think I have found an anomaly in the documentation. Do these two statements conflict?

Bit 0: User mode flag (0=user mode access not required, 1=user mode access required)

The flag in bit 0 of R0 controls a security measure that is supported on some systems; if you only require use of VFP/NEON instructions from privileged modes then it is recommended that you set this bit. This will prevent user-mode code from being able to execute VFP/NEON instructions and corrupt your context while it is active.

I unset bit 0, and now things work as expected – so far, that is. ;-)

The key bit in that text is “supported on some systems”. At the moment I haven’t actually implemented support for that flag, so you’ll be able to use the contexts from user mode regardless of the setting. Depending on how lazy I’m feeling that might change in the future :)

It is interesting that when set I have problems that do not occur when unset. I am still working on this.

Use a more recent version which uses the UAL syntax?

I see.
The BASIC assembler supports UAL, the ARM ARM¹ (somewhat) predates this.

Useful cross-reference: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473c/CIHFAHFG.html

I think part of the problem is that you have stuck with integers.

;-) I meant, plain ARM, no FP at all. For me, the FP stuff is ‘not obvious’ (and never will be). Binary ops are more my speed…

I have not been quite as ambitious as Rick,

Hehe – I wouldn’t say “ambitious”, I just wanted to set the system up to multiply four sets of numbers at once. After all, the ARM can do a straight multiply, so for something more exciting, I wanted to do a bunch.
If I was better at maths, I’d do something more interesting, in parallel, because this SIMD stuff is where the power is, and where the benefit of the FP hardware really kicks in. But, it’ll do for a start. It’s only really one instruction. The rest is just setting it all up.

VMOV assembles and throws an ‘Undefined instruction’ error.

Strange – the only thing that failed for me was the multiply. Take that out, the code runs. But, as you spotted, there might be something in the flags. I can’t test with bit 0 = 0 as I have turned my Pi off (got fed up of watching the rain splatter down the window) and anyway I have to write a letter to a new insurer because wonderful Monsieur-le-President Hollande implemented a new law where every employee in certain sectors must have a medical top-up, part paid by the employer. While this is a laudable action (ha ha Obama!), Mr Hollande didn’t include a mechanism for people who thought ahead and already have such a thing of their own volition. It should have sufficed to show my employer that I had coverage in course. The end. But no…
I cancelled my current in August, that was rejected due to not having sufficient reason (I don’t blame them, my company gave me a stupid form letter that any halfwit could bash out on a word processor – <cough>as I did</cough>) and the lovely HR took forever to provide me with the justification paper. So I sent that off, got back a letter at the end of October claiming that my top-up is cancelled as of the beginning of August. (um, guys, haven’t I paid for Aug-Oct?). I am quite disturbed by the utter lack of interest (and, one might suggest, competence) by my company’s HR, and I am a little perturbed by the fact that the new employer (AG2R) would appear to want to be paid from the justifying date. I asked, in May, when HR finally realised I had been forgotten (my reality) / didn’t bother to fill in the paperwork (their reality) if I could run the two and save a lot of bother, to cancel the existing when renewal came. Yes, I could, but without the paper saying I was insured up until such and such a date, I would need to pay AG2R as of the 1st of January. In May. WTF for? So I need to write a letter to highlight the fact that my cancellation as of 1st August was posted on 20th October and it arrived here yesterday, so the date I’m putting to AG2R is 1st November; and unless they plan to reimburse my payments to my previous insurer, they better not expect to be paid as of August. I’m not A, paying twice; and B, paying for something they cannot possibly morally justify – I’m not going to get ill in October, it’s been and gone. But no doubt AG2R will point to the law and say “it’s the law, cough up, bitch!”
Gee, Mr. Hollande… anything else you want to break? Your wealth tax was ruled to be unconstitutional, and your directive that mayors who do not believe in gay marriage must officiate said unions…isn’t going down so well. And, hey, shall we talk about the automated écotaxe for lorry drivers? The Ouest-France newspaper ran with that all week.

But me? A stupid letter for something that should never have concerned me.

And all this must be done in French.

Oh joy.

Anyway, thanks Steve for spotting what might be the problem. But no, I won’t be trying it tonight.

¹ By ARM ARM, I mean this, all 800+ pages of it. It’s a shame there isn’t a published update for the Cortex era, because I much prefer a phone directory to a PDF. (^_^)

I am quite disturbed by the utter lack of interest (and, one might suggest, competence) by my company’s HR

Excuse me? what made you think your nearest HR held the monopoly on that?

what made you think your nearest HR held the monopoly on that?

I didn’t. I was just hoping that mine might have notice……oh, never mind…

Just compiled gcc 4.7.4 for RISC OS to see if i can get it to compile with -mhard-float.
Apparently the linker does not understand hardfloat. It results in error: demo.o uses hardware FP whereas demo uses software FP.

Either gcc is not telling ld to use hard-float or there is no support for hardfloat with ld.
Maybe anyone here can enlighten me?