How much of the pi does Risc OS utilise?

Just wondering how much of the Broadcom chip is actually utilized by Risc OS and what is actually not used. How much of the gpu functionality is utilised? Is there any intention to add some sort of opengl driver to risc os.

How are floating point operations performed with Risc OS?

Is Risc OS likely to improve in the future as such features are integrated into it?

How much of the gpu functionality is utilised?

Not a lot. The internals of the GPU are still closed. For Linux, there’s a binary blob. For RISC OS….nothing.

Is there any intention to add some sort of opengl driver to risc os.

I’m sure many would agree this is a good idea. We just need access to detailed documentation of the GPU, people with time to make it happen, and the knowledge that their source code would likely need to remain closed (so he who starts it must maintain it).

How are floating point operations performed with Risc OS?

Depends upon what you mean by “floating point”.

I rather suspect a lot of our traditional FP [this] is emulated still. While the RISC OS world has had access to FP hardware since the ARM7500FE, our traditional view of FP functionality is a design that predates both VFP and Neon. If I remember correctly, the FP mechanism works by installing an exception handler so it can trap invalid instructions and perform the emulation. In this way, if hardware FP provides the required instructions then they will be executed native. So the question is, how much does VFP resemble the original FP instruction set? If “quite a bit” or “not at all”, there is your answer. A brief look at the ARM ARM suggests significant differences (registers F0-F7 don’t exist, for a start, then there’s the instruction set…).

For the newer FP (VFP and Neon), I don’t believe that RISC OS itself makes much use of these yet but there are facilities built in to RISC OS to allow them to be used – look here: https://www.riscosopen.org/forum/forums/3/topics/2172 and also note that the BASIC assembler supports VFP.

The final answer? As technology evolves, so will RISC OS (in some manner), but then, so must the applications that run upon it.

Just wondering how much of the Broadcom chip is actually utilized by Risc OS and what is actually not used. How much of the gpu functionality is utilised?

Barely scratching the surface.

Is there any intention to add some sort of opengl driver to risc os.

Ah the regular question, or variant of it. The answer, as always is “So much to do and so few coders.”
All help is gratefully received by the ROOL guys, just avoid including any GPL.

Is Risc OS likely to improve in the future as such features are integrated into it?

RO is improving with the availability of new hardware elements making new features possible.
Wish lists are long and the list of coders is short, so the development times are correspondingly long.
More coders, more work done, shorter times.

If there is anything you can do, writing documents, testing, or even producing some simple code for something that doesn’t yet exist then do join in.

As pointed out in
https://www.riscosopen.org/forum/forums/11/topics/2991
Charm (http://riscos-charm.yolasite.com/) supports VFP. The Charm distribution lets Raspberry Pi owners easily recompile Charm to use VFP rather than the traditional FPE. Inspection of the Charm sources show how VFP is implemented, and I have no doubt others could copy.

RiscLua 7.50 does not use any FP at all, but does offer fixed point numbers of arbitrary size through its bc library. RiscLua is based on Lua 5.2. Lua 5.3 is currently in process of emerging as a result of discussion about how to cope with numbers. Should one coerce (int → fp, fp → int) and pretend that users do not understand the difference between integers and floats or should one maintain a rigorous distinction between the two types? My own preference would be for the latter, but the former is the route that Lua has traditionally taken. There seems to be little point in upgrading RiscLua to be based on Lua 5.3 until the RISC OS uptake of VFP, Neon etc has progressed further.

Why can’t Charm be used to compile a module, whereby the VFP can be accessed from other Risc OS languages?

Charm […] supports VFP.

I stand to be corrected, but I think Charm only provides the standard arithmetic operators, so it is relatively ¹ straightforward to use VFP. The FPA/FPE provides a fairly rich set of operators, including the trancendental functions such as SIN and EXP, which are not available with VFP. There is also the matter of precision; FPA can do extended double, and this is used internally, whereas VFP can only do double.

With a view to one day including fast double precision floats to Basalt, I investigated where all this led back in January. The new BASIC assembler was invaluable, and I produced my Float module, as yet unregistered. I initially made the VFP instructions available through SWIs, but discovered that the speed advantage of VFP was swamped by the overheads. By providing a direct jump table to the code I found that the remaing overheads were more-or-less insignificant. So this is one route to using VFP without having to get involved in writing your own assembler.

I should also point out that Float should make handing the context easier and that it works with VFP when that is available, or FPA/FPE as a fallback. It also does the full range of operations that FPA has, plus some handy conversions for BASIC 5-byte floats.

I would really like some feedback and suggestions.

¹ Relatively – provision has to be made for creating and preserving context, so it is not just a matter of substituting VFP instructions for FPA ones.

Steve, the link to your Float module is badly broken, not just because it begins with htp, but more because once fixed it redirects to “Kappa.me is for sale”.

Mea culpa. Link fixed.