ARMv7 compatibility list

Jeffrey, do you still have your patches for zip? Looking at why mine fails, it’s the assembler in acorn/match.s that has some decidedly non-ARMv7 operations in it. There’s also acorn/sendbits.s assembler too. According to the Info-Zip forum a fix for this was merged into beta Zip 3.1b, but neither 3.1b or 3.1c have it. The forum has, of course, expired all the attachments in that thread so all the patches are gone (as are the ones on your site).

I /can/ try and get my head around obscure data mangling code, but it would be better to have something tested :) This is the first example I find in match.s (there may be others):

cycle_end
        MOV     ip, r0, LSL #17          ; cur_match & WMASK
        MOV     ip, ip, LSR #17

LDR     r0, [fp, ip, ASL #1]     ; cur_match = prev[cur_match & WMASK]
MOV     r0, r0, ASL #16
MOV     r0, r0, LSR #16

I’ve finally started making changes to the wiki page itself. I’ve completely rewritten the introduction and rejigged the compression section. Hopefully this gives people a good idea of what I’m shooting for.

I’m glad I did some research before I started editing the page, because having a clear idea of all the different circumstances which need to be addressed – which I developed through thinking aloud on this thread – has made things much easier.

If anybody doesn’t like it, now’s a good time to say so!

Jeffrey, do you still have your patches for zip?

Yes, but my patches don’t appear to directly tackle the issue of the assembler files using rotated loads/stores. Neither do Joty’s improved patches (which are in the GCC autobuilder, and the 3.1 beta sources). However it looks like my changes to the GCC makefile to allow the assembler files to be disabled have survived intact, in both the autobuilder and beta sources; if you pass through the NOASM option to make then that should produce a binary that works, although it might be a bit slower than ones that use the assembler code.

Thanks. That’s now committed (and my link is fixed to a new version which does seem to work).

Martin – I’m just taking a look at the compatibility page now, and one thought comes to mind – the “RISC OS ROM date” column in the tables is pretty much redundant now. The initial purpose of the column was to help us to determine what software needed retesting after a bug was fixed in the ROM image. But since we’ve had three years to track down bugs in the ARMv7/OMAP port, and one stable release of the OS for ARMv7, I think it’s safe to say that the column is now redundant, and anyone with common sense will be using at least RISC OS 5.18 rather than a two/three year old development ROM.

Related to the above, there’s also no indication of what machine someone’s tested the software on. Or maybe we can just assume that there won’t be any software that works on ARMv6 but fails on ARMv7? (Off the top of my head I can’t think of any examples of things that would work on one but not the other, but I’d have to check the ARM ARM to be sure)

This also reminds me that one of the things that’s been knocking around my todo list for ages is to make the data abort/prefetch abort errors more descriptive, so that they indicate the specific type of abort (unaligned load/store, unmapped memory, insufficient privileges, etc.). I’ll try and get that done this weekend, as it will make it much easier for people to spot why something is failing.

Martin – I’m just taking a look at the compatibility page now, and one thought comes to mind – the “RISC OS ROM date” column in the tables is pretty much redundant now.

That came to my mind, too, which is why I deleted it in both the compression sections and my earlier attempt at a revamp (see first page of this thread) in the networking section.

(Off the top of my head I can’t think of any examples of things that would work on one but not the other, but I’d have to check the ARM ARM to be sure)

AIUI, the only major changes have been in the floating-point instruction set, which is used by so pathetically few RISC OS applications I think it can be safely discounted. Kuemmel’s demos might be affected, but nothing which can’t be accommodated by the notes column.

I suppose the possibility still remains of an Iyonix-style bug in the Pi, where some instructions which should have faulted appeared to work anyway.

the floating-point instruction set, which is used by so pathetically few RISC OS applications

Acorn never really seemed to embrace the idea of hardware FP, so all FP ops went via the FPEmulator which was good, but since it was an emulator, you’d get faster results coding your own fixed point maths. Essentially, where was the incentive to use FP when the majority of the old-school (26 bit mode) hardware didn’t have real FP?

After weeks of apathy, procrastination and general laziness, I’ve finally had another crack at the page, and this time I’ve got up to the end of ‘Games’. I’ve also updated my progress post, should you care to look at that.

I’ve got down to the end of the ‘Games’ section.

Martin Wuerthner emailed me today, which means the only email which has not yet had a response is the one to CJE, about OHP_Show and Photodesk. I’ve put OHP_Show’s support down as ‘Unknown’ for the time being.

Outstanding issues:

• What is SpellCheck? Who is responsible for it? Is it supported? Compatible?
• DosBox: No idea if the currently available one is supported or not, because Chris Gransden’s just produced a new one, but hasn’t made it available yet.
• I thoroughly tested Chuckie Egg and Dare Devil Dennis (it’s a hard life), and they seem to work, but no idea if they’re supported or not. Another email added to the pile.
• Who on earth do I go to about Twin World?
• And should we keep the ‘Astronomy’ section?

Hi Martin,
2 updates for you, according to Steve Fryatt, PrintPDF 0.87 is NOT V7 safe
Confix is now V1.00 (08 April 2011), can’t help on if it’s now V7 safe.

HTH

according to Steve Fryatt, PrintPDF 0.87 is NOT V7 safe

but 0.88 (on the 8Aug alpha image) is.

Having finally recovered from an unfortunately-timed holiday, and building on what I’ve learned so far, I’m hoping to streamline this process a little. I’m now at the top of the Graphics section, which is the first one with a really large number of ‘Seems OK’s, meaning a lot more work for me.

I’ve prepared a form letter which I’m going to attempt to send to as many people as possible. Note that, if your software is on the list and you’re reading this, you can help me by contacting me about its status (or even just editing the page yourself) before I have to contact you!

*** (Paragraphs marked like this are important.  If you're short on
*** time, all the rest is just background information.)

I am currently in the process of overhauling RISC OS Open's ARMv6/v7
compatibility list, located here:

http://www.riscosopen.org/wiki/documentation/show/ARMv6%2Fv7%20software%20compatibility%20list

The original list was started as a means of testing existing software on
the BeagleBoard and recording which bits seemed to work and which would
need modification in the future.  Now that RISC OS has run on
post-Iyonix hardware for a few years and much software has been updated
appropriately, the need for such a list is vastly diminished, so I am
now switching the focus from a testing database to a central database of
software which *has* been updated.

At present it is a work in progress, so some sections of the page are in
the new format ('Status' and 'Support' columns) and some sections remain
in the old.

The meaning of the 'Status' and 'Support' columns are explained at the
top of the page, but briefly, the ARMv7 OK logo may only be added to a
program's entry with a developer's permission, and the 'Supported' and
'Not Supported' options in the 'Support' column also require permission.

Therefore, I am sending this email out to a number of RISC OS developers
regarding the current status of software they authored which has been
entered into the list.  The aim is to get as many ARMv7 OK logos and
'Supported' entries into the table as possible.

I would be grateful if you could look through the table and reply
telling me what the current status of any software you wrote which
appears in it is.  So far I have discovered:

*** (name of program)
*** (name of another program)
*** (etc)

There may be other software I haven't noticed yet.

*** Are the above program(s) considered ARMv6/v7 safe (works on
*** Raspberry Pi and BeagleBoard) to the best of your knowledge?

*** If any program has been recently updated to make it safe, what is
*** the minimum version you recommend users use?

*** Do you consider the software to be supported - would you be willing
*** to fix any compatibility problems if they are found?

In some cases this seems like a daft question (e.g. programs written in
BASIC are pretty much guaranteed to work), but I don't like to promise
support on somebody else's behalf, and there is an important difference
between 'Seems OK' (its users think it works) and 'ARMv7 OK' (its
developers think it works).

*** Note that it *is* acceptable for a program to be supported, but for
*** you not to know whether it is safe yet, and equally something can be
*** safe without being supported.

*** Finally, if possible, is there any other software you have written
*** which you consider to be either safe or supported?

So, Mr Hodgkinson, about this ‘Seems OK’ next to SwiftJPEG… ;-)

Anyone knows if a good, ARMv7-compatible benchmark is in the works ?
Too bad ARMSi and SICK don’t work on the BB xM

@jerome

There is one called Dhrystone_2.1 and also I have a zipped file with some (BASIC) benchmarks (PD from 1990….), all work well on Raspberry_Pi (I don’t have a BB xM to test)

you can download these benchmarks from HERE

Lame is about 6 times as fast on the BB xM as on the RPC SA 200 MHz. Still not real time, but a nice improvement.

@chris: I can’t download from mediafire, either with Netsurf or Risc OS Firefox (nevermind)

@Jerome

try This then..

@Martin, WimpWorks (now up to v2.38) is ‘ARM v7 OK’ and is ‘Supported’. Since the wiki’s being odd for me, I haven’t updated the Programming table.

Progress report:

• I finally summoned up the energy to plough through the Graphics section – far more ARMv7 logos and Supported tags in there now.
• Originally, I didn’t think it was worth directly contacting SwiftJPEG’s author, assuming that he already knew what I was up to, but now I’ve sent him one of my emails by way of a poke!
• At present I’m ignoring the software which isn’t hyperlinked, like ‘FreeHand’, ‘Ray3d-Pro’, and ‘Shade4’, in the interests of getting the job done quicker. If anybody can shed some light on those programs (or added them to the table themselves) that would be helpful. After I reach the bottom I may go back and Google some of the missing pieces, and insert the necessary links.
• What do I do with all this old, orphaned software?
  • I’ve been holding off sending emails to the authors of obvious abandonware like EXIFinfo and Twin World, but there is the question of whether such software should remain on the page at all.
  • Is it ethical to slap the ‘Not Supported’ status on anything which hasn’t been updated in a long time without asking?
  • And where does one draw the line? Is there still hope for Draw2SVG, last heard from in 2007, which now crashes on startup?

What IS the Problem Twinworld? I have to admit that I just had played it like 45 minutes with AE on and about the same time with AE off before making the entry in the list, so it wasn’t a extensive test. Therefore, I settled for “Seems OK”.

Yes, the patch wasn’t meant specifically for ARMv7 systems. But is so much more different to the “Third Party Support” in Zap?

What IS the Problem Twinworld?

Yes, the patch wasn’t meant specifically for ARMv7 systems.

That is exactly the problem. I know I’m being picky, but I feel that information distributed on RISC OS’s official website ought to have a very high standard of reliability. And until someone can drag out the source code from somewhere, produce an update which isn’t in the form of a patch, get the blessing of whoever the copyright holder is these days and certify their new release as ARMv7 compatible to the best of their knowledge, it can’t have an ARMv7 OK logo or ‘Supported’ status. At present it doesn’t even really qualify for ‘Third Party’ support (which can also allow ARMv7 logos, e.g. Zap), when, unlike Zap, it can only be made to run by hacking the binary.

We all remember that unpleasant business with the distro a few weeks ago. That’s what happens when you’re not careful enough with other people’s software. A unofficial testing database compiled by users is all very well, but I want to make the list more than that.