Idea for floating point across various ARM processors...

I’m well aware that floating point is really, really low on the priority list, but I was thinking about it. Also, I’m no coder, so what I’m suggesting in this post may be completely impractical. Please flame me if it is. :)

I recall reading a comment here that ports to later XScales (and, by extension, some other Marvell chips) could be made difficult by the iwMMXt FPU having some opcode clashes with FPA.

If I’m understanding correctly, floating point on RISC OS currently works like (on everything but an FPA-equipped ARM3, ARM700 prototype, or ARM7500FE):

Program has FPA instruction → CPU detects an invalid opcode → Invalid opcode exception thrown → FPEmulator handles exception, and executes the FPA instruction → Normal execution resumed

Is that correct?

Here’s my idea, that would possibly work around that problem, and might even improve performance.

Program has a floating point instruction that calls a floating point module (or something like that – the idea is what I’m after with this post, not the implementation) → floating point module takes care of it in the way that’s the most appropriate for the processor (and would be built specifically for that processor) → Normal execution resumed

So, on something without any floating point hardware, the floating point module would be a softfloat library.

On FPA, it could in theory translate to FPA instructions. (However, as the newest FPA hardware is 56 MHz…)

On iwMMXt, it could translate to that.

On VFP and NEON, it could translate to those.

Like I said, I know this is FAR from a priority, but still, I do see it becoming a problem, if we want floating point code to perform well across differing FPUs, without recompiling programs. And, if someone else does an FPU that has an opcode clash with FPA, especially if it’s in a chip that’s in something that’s otherwise desirable for a port, it could cause problems if something’s not done before that becomes a problem.

Would be lovely to have a newer version of POV-Ray up and running again… and also useful if it’s possible for RISC OS to talk to a 3D TV display .

Program has FPA instruction → CPU detects an invalid opcode → Invalid opcode exception thrown → FPEmulator handles exception, and executes the FPA instruction → Normal execution resumed

Is that correct?

Yes, that’s correct.

The idea you’re suggesting would work, and would provide a good performance boost compared to code that uses FPEmulator. But for the moment I’d be more interested in seeing an implementation of an LLVM-based system, as it should (in theory) allow programs to achieve the same performance as if they’d been compiled directly for the host architecture. This would be particularly useful for machines lacking FP hardware, as it should allow for the best optimisation of the software floating point routines. Plus it would also protect us from most of the problems that arise each time ARM introduce backwards-incompatible changes to the ARM architecture (which they’re undoubtedly going to continue to do in the future).

Really the issue of FP & architecture compatibility is such a big problem that it needs someone who can focus full-time on finding and implementing a solution. But it seems the RISC OS market is a bit short on spare programmers at the moment :(