Blind eye

I think of all the intellectual energy used, and possibly wasted, in RISC OS land. The ambitious projects coded in ARM assembler, the languages ported, or even created from scratch, by dedicated enthusiasts, the hours of refining the documentation; how much has seeped into the sand, never to be used or adopted by more than a handful of devotees. The RISC OS landscape is littered with noble relics; they may have given their creators many hours of happy coding, and taught them valuable lessons, but few, I think, have brought fame or fortune, not that fame or fortune were often sought. Guttorm Vik once wrote poignantly of his efforts with StrongED, but at least StrongED is useful to many.
The new possibilities for RISC OS presented by new platforms, with their more recent ARM cpus (the Raspberry Pi’s ARM11 chip is only a decade old now!) mean that we have some catching up to do. I have in mind BASIC’s assembler, for example. In the old days there was virtually only one platform for software authors to cope with. It is very different now. Castle’s initiative meant the 26/32 bit divide. Now we have the non-aligned load-store complication for the ARMv7 architecture, vfp hard-float foor the Raspberry Pi’s ARMv6 architecture, and a host of new capabilities in the cpu that RISC OS may never exploit. The majority of RISC OS users, who do not themselves write programs, have been turning a blind eye to all this, or, at least, have been shading it with rose-coloured spectacles.
I know of only one application that can take advantage of vfp right now – that is Charm 2.6.3. It does everything from scratch, right down to assembly and linking, with its own formats. I mention this because I suspect that lots of enthusiasts could take advantage of its source code and tools to build their own projects, without necessarily doing any programming in Charm itself. Have a look at Charm.lib.src.fp if you want to see how to exploit vfp on the Raspberry Pi. I suspect that the newer ARM cpus require fairly similar code.

I would recommend writing the code you wish to run on the VFP directly in Charm using the real data type and leaving the compiler to do the tricky part of generating equivalent VFP assembler instructions for you!

I think of all the intellectual energy used, and possibly wasted, in RISC OS land. The ambitious projects coded in ARM assembler, the languages ported, or even created from scratch, by dedicated enthusiasts, the hours of refining the documentation; how much has seeped into the sand, never to be used or adopted by more than a handful of devotees.

Sadly, the likes of SourceForge and GitHub didn’t exist in the hey-day of RISC OS. I cry when I think of so much work that has simply disappeared. I think one poignant tragedy is Impression.

I have always believed that when one has finished exploiting a work (no longer selling it, no longer planning to support it), then what do you have to lose by tidying up the source code (mainly checking to make sure there aren’t any weird comments that might offend!) and then releasing it to the world.
I’m not a fan of GPL (I prefer EUPL), but even GPL is better than nothing at all. Then there’s a chance your software might still live on and be updated by people still using it. A case in point is… um… right here. RISC OS itself.

The RISC OS landscape is littered with noble relics; they may have given their creators many hours of happy coding, and taught them valuable lessons,

The time I spent on a video indexing program that was decided as not being something to bother selling (even at cost price) is unreal. I would have made – I think I calculated – about eight grand if paid minimum wage. A sobering thought. But I learned all sorts of stuff, and it was a way to pass time when I had nothing better to do.
I don’t really play games. I like more intellectual exercises. Programming ticks that box, and there’s the sense of accomplishment when you think “I want to do X” and a little while later you have it done.

but few, I think, have brought fame or fortune, not that fame or fortune were often sought.

I’m certainly not in it for fame or fortune. Furthermore, having been on the periphery of professional coders, all of their knowledge and skill was routinely ignored by management. If management wanted something done and they wrote an ass-backwards specification, that specification was to be followed even if the processor or OS offers a hundred better ways. I enjoy programming. I am taking a break from writing something right now! But if I was in such a soul-destroying position, I would no longer enjoy it, I wouldn’t be able to do things at my own pace or feel free to experiment to see if there’s a better way than the one I thought up first. I would come home from work and view my computer as a mere tool for watching animé or checking the notoriously inaccurate weather report.

but at least StrongED is useful to many.

A lot of hobbyist programmers work on the principle of “scratching a personal itch”. In other words, they write something that resolves a particular problem of theirs.

mean that we have some catching up to do.

Some!?! (^_^)

Castle’s initiative meant the 26/32 bit divide.

Whoa – wait… You might say it was Acorn’s inaction on this too. Once Acorn folded, there was no need to support the anachronism of 26 bit PC+PSR. Newer ARM processors didn’t support it, period. This is why ROL stuck for so long with RiscPC class systems and why cloned RISC OS boxes were supposed to be based around the ARM7500 chip. The simple reason is everybody could see the 26/32 bit problem and everybody went “lalalalala-I can’t hear you” until Castle finally stepped up and got a build of RISC OS running.

In The Register today was an article that the Linux kernel is now officially dumping support for the 80386 with the words “Good riddance”. Times change, things move on. An ARM architecture that only supports up to 64MiB addressing makes no sense whatsoever in today’s world. We had to go 32 bit to survive.

Now we have the non-aligned load-store complication for the ARMv7 architecture,

This should have been a non-issue. I don’t understand why the compiler wanted to load an unaligned word and shift when it is just as many instructions to load an aligned word and shift or mask.

vfp hard-float foor the Raspberry Pi’s ARMv6 architecture,

You know, we aren’t unique in this respect. My PVR runs Debian. One version of the firmware takes SWIs passed by number in the instruction while a different version of the firmware takes SWIs passed in a register (because jumping back to read the instruction to pull apart the SWI number from the opcode trashes the cache and is an expensive operation). Now early programs will apparently work on the later firmware (I’m not sure how…), but this is not the same in reverse.

and a host of new capabilities in the cpu that RISC OS may never exploit.

True.

The majority of RISC OS users, who do not themselves write programs, have been turning a blind eye to all this, or, at least, have been shading it with rose-coloured spectacles.

What you meant to say was:

• The majority of non-programmer RISC OS users neither know, understand, or care.
• The programmer RISC OS users are painfully aware, but we’d rather find reasons not to rewrite the entire operating system.

I know of only one application that can take advantage of vfp right now

That’s probably a good thing. VFP is pretty slow on the Beagle/OMAP3. You would be better off dropping some precision and using the NEON unit instead.

Oh, and for what it is worth, you get all these problems both in ARM and x86 land.

Example: Look at something like MoboPlayer or MXPlayer for an Android phone and notice the collection of associated codecs. My phone has codecs for an ARMv7-NEON. You don’t tend to see this as it happens in the background.

On the PC… AVIDemux. Should it accelerate with MMX? MMX2? MMXEXT? 3DNOW? 3DNOWEXT? SSE? SSE2? SSE3? SSSE3?
I think the program contains the same code written a dozen times, optimised for each different class of media acceleration, and there’s a detection routine that picks the best one.

So the lesson here, perhaps, is if you want to write FP code for RISC OS these days, you ought to do it several times over (let’s see, there’s FPE and there’s VFP and there’s NEON and…?).

Have a look at Charm.lib.src.fp if you want to see how to exploit vfp on the Raspberry Pi.

…which means that non-VFP systems will fail with the code. Is the Beagle and Pi VFP the same? How about OMAP4?

I suspect that the newer ARM cpus require fairly similar code.

I think I ought to bring your attention to the following from Wikipedia (my emphasis):

The VFP architecture was intended to support execution of short “vector mode” instructions but these operated on each vector element sequentially and thus did not offer the performance of true single instruction, multiple data (SIMD) vector parallelism. This vector mode was therefore removed shortly after its introduction,³⁴ to be replaced with the much more powerful NEON Advanced SIMD unit.

Some devices such as the ARM Cortex-A8 have a cut-down VFPLite module instead of a full VFP module, and require roughly ten times more clock cycles per float operation.³⁵ Other floating-point and/or SIMD coprocessors found in ARM-based processors include FPA, FPE, iwMMXt. They provide some of the same functionality as VFP but are not opcode-compatible with it.

I guess it depends a lot on the application. The thing I’m writing now doesn’t need FP ops (most of the maths is integer-based multiply, addition, subtraction, and shift), so it’s a non-issue for me…

Real numbers have always been a ! in the * for computing. The way maths is taught these days very few people ever get to understand what they are. The popularity of the IEEE formats mean that most people forget that, as with all datatypes, there are other possible formats each with their own virtues, faults and compromises.
The multi-precision arithmetic of the bc library, now in RiscLua 5.50 does not use any fp operations and so avoids the problems mentioned above. But that means that it cannot exploit the tricks that serious number-theoretic software uses. But for educational purposes it should be sufficient.

The way maths is taught these days very few people ever get to understand what they are.

It’s simple. Real numbers are actual tangible numbers, like how much petrol costs.
As opposed to fake numbers which is what runs the global economy, or the whole banking crisis.

does not use any fp operations and so avoids the problems mentioned above.

Fixed point maths? It’s a good compromise when you need to deal with non-integers but without going the slow/complicated route.