VFP and Neon on ARMX6

Can someone remind me how to run programs that use the hardware floating point on the new RISC OS hardware including ARMX6? I know I should be doing a search of this forum, but I am short of time and would like to do a demo of programs like FracNEON_Basic and FracVFP_Basic on an ARMX6 this evening at our club.

Good luck. If you find out, here is one Rpi2 owner who would be grateful to share your knowledge.
To exploit NEON and VFP properly we need some tools; most significantly a shared C library and a C compiler that can deal with them. RISC OS users have been without arithmetic in hardware for so many decades that maths has dropped off their map, perhaps?

I would be happy to get hold of themodule or wahtever it was that you had to run first. I think TBA produced it.

…FracNEON_Basic and FracVFP_Basic…

Kuemmels stuff?

AFAIK the VFPsupport module is in the RISC OS ROM, and the BASIC assembler was updated some time back, so it should be “out of the box”. However, it is possible that some of the stuff has changed and code from when it was all experimental may not work on current RISC OS builds, I’m not sure. To be honest, I haven’t looked into this for a while as there’s sadly still very little VFP stuff available. Part of the problem is that the VFP-enabled SharedUnixLib still hasn’t been approved/formally released after, erm, how many years? (something of a bugbear of mine). Thus, the VFP accelerated Lame port can’t be easily supplied, nor the VFP-enabled Mplayer and so on.

The VFP-enabled SharedUnixLib is available “on request” from various forum-folks, and so are the VFP-enabled ports, but we’ve been stuck in no-man’s land for what seems like ages. I remember when I wrote MusicMan2, it had already been stuck in approval for a while, and that’s two, maybe three years ago. The VFP Lame port, for example, was 3-5x faster than the fixed-point Lame port. That makes quite a difference when waiting for files to be MP3’d. Indeed, it takes Lame (makes better quality MP3s) from “barely useable” to “quite acceptable really”.

Rant over. Sorry. I just can’t help feeling that RISC OS could be doing much better with ported software etc if we could take advantage of the hardware we have more effectively.

On a happier note, the Charm programming language (found in the Develop folder on ARMX6) has a fully working VFP version, and clicking the option will re-compile the whole system to run with, and use, VFP. From then on, any Charm program you compile will be VFP-enabled.

Rant over. Sorry. I just can’t help feeling that RISC OS could be doing much better with ported software etc if we could take advantage of the hardware we have more effectively.

Perhaps we need some of this magic dust in the DDE compiler as well?
It is a strange set of affairs to have a machine with lots of SIMD and hardware FP featurs … and RISC OS to be using … emulated FP.

From then on, any Charm program you compile will be VFP-enabled.

How does such a program behave on a non VFP machine? Does it revert to FPE or does it fault?

I use VFP-enabled SharedUnixLib (1.13) and the VFP Lame port without problems on my “ARMX6”. For me it works.
Kuemmels VPN/Neon Basic examples are also working. The only problem is the CPU freq. detection: ((B)eagle or (P)anda)?. Use “any key” not B or P and it will work.