[Openmcl-devel] trunk unstable. Linux ARM port identified as culprit.

[Brian Mastenbrook]

On 8/6/2010 12:07 PM, Gary Byers wrote:
> On Thu, 5 Aug 2010, Brian Mastenbrook wrote:
>> Is ARMv6T2 a sensible minimum?

(I should have clarified here that I wasn't questioning your judgment, 
but just looking for the reasons behind it, which you've certainly 
supplied.)

> It'd be really great if it was possible to both fully exploit newer,
> higher-end ARM hardware (say, the Cortex A8, A9, and their successors)
> and simultaneously support things like the SheevaPlug and the OpenRD
> boxes. (I have two OpenRD boxes; they're nice little machines. All
> other things being equal, it'd be great if CCL ran on them. I don't
> think that things are equal, and after thinking about fairly hard and
> for a fairly long time, I'm pretty much convinced that the most sensible
> minimum is nearer the higher end of the spectrum.)
>
> The OpenRD and the SheevaPlug (and most other ARMv5 machines) don't
> have the Vector Floating Point (VFP) unit that's present on later
> machines. (They either have some proprietary Marvell FPU or are
> FPU-less). You -might- be able to write a VFP emulator and run the
> same code on an ARMv5 and on a more modern machine, and you might live
> to tell about that if that code didn't do non-incidental FP
> arithmetic. I haven't tried, and don't know whether emulating VFP
> instructions on VFP-less hardware would be at all practical.
>
> Not using VFP instructions for floating-point - because the SheevaPlug
> is Really Neat and cheap and there are probably lots of them out there -
> is another way of solving this problem. (The technical term for this
> approach is "A Really Stupid Idea.")

This is a very good point. With my Ordinary User hat on, floating point 
doesn't concern me all that much, which is why I've forgotten about the 
complete mess in this area on ARM. With a compiler-author hat on wanting 
to use VFP makes complete sense. It's a shame, as the Marvell parts are 
likely to show up in a number of small NAS devices that would otherwise 
be attractive target. Oddly enough they do seem to have a separate 
series of "Discovery" parts that do support VFP, but are otherwise bog 
standard ARMv5TE.

*snip discussion of ldrex/strex/clrex and movw/movt*

> I'm fairly sure that the ARMv6KZ (which is the same class of machine as was
> used in early iPod Touches and iPhones) supports movw/movt; the docs that
> I'm looking at are less clear as to whether clrex is supported. I think
> that it's desirable to use clrex if it's available and necessary.

The technical reference manual for the ARM1176JZ doesn't mention movw 
and movt, but it does support ldrex/strex/clrex.

>> The Marvell processor in the SheevaPlug devices is an ARMv5TE, which
>> would rule it out as well. There are numerous cheap Android tablets
>> coming on the market with ARMv6KZ-or-below processors as well.
>
> There'll be bazillions of Cortex A8s and A9s, too.
>
> GCC on Ubuntu 10.04 defaults to generating Thumb 2 code. The majority
> of the ARM boxes that I have won't run Thumb 2 code; for some reason,
> Canonical didn't ask me what I thought about this and I assume that
> they didn't ask you about this, either. If I had to guess whether
> "they just didn't think about it" or "thought long and hard about
> continuing to support older machines and decided not to", I think that
> I'd probably guess the latter. (I don't know whether compiling CCL
> to Thumb 2 would be better or not; I'm skeptical that code density
> would improve much, but there might be other ways in which it'd be
> better. If it was clearly better ... well, good bye forever pre-T2
> machines.)

Once again I should clarify that I wasn't trying to question your 
decision, and apologies if it came across otherwise!

I think the Ubuntu folks' thought was that the netbook-class hardware 
they were targeting would clearly be using Cortex A[n]-or-better 
processors. Given the speed at which the mobile market moves, it's 
likely that this time next year most existing uses of ARM11-series 
processors will be replaced with Cortex-A5/A8 parts, in which case 
targeting OpenMCL exclusively at ARMv7 would probably not be a bad 
thing. As much as I dislike it, these devices are disposable and usually 
obsolete before the warranty expires or the contract is up.

> Rumors about the system requirements for Android 3 are just that at
> this point. If there's any truth to them, I can probably give up on
> the idea of running Android 3 on my N810. I'd better tell Google
> ... unless they know and don't particularly care.

I think it's safe to give up on the idea of running Android anything on 
those machines, as much as I'd like to be able to bring it up to date 
and keep using it.
-- 
Brian Mastenbrook
brian at mastenbrook.net
http://brian.mastenbrook.net/