544519 - Add ARM_ARCH switch to the cross-compile script

Status: VERIFIED FIXED

(Tamarin Graveyard :: Build Config, defect, P3)

Description

[Brent Baker]

Should have the ability to specify the arm architecture version passed to the compiler in the cross platform configuration script. Currently the arm architecture passed to the compiler is:

armv6 if arm-fpu is enabled 
armv5 if arm-fpu is not enabled

The arm architecture is currently always passed as v5 to the VS arm assembler.

Comment 1

[Brent Baker]

We currently have the following options when compiling with GCC for arm:

--enable-arm_fpu  => -mfpu=vfp -march=armv6
--enable-arm_neon => -mfpu=neon -march=armv7-a

Comment 2

[James Sudduth]

While fixing this bug and bug 537817 (Tamarin doesn't build on Snow Leopard) it became apparent that configure.py and the files it depends on (confguration.py and getopt.py) need to be reorganized. The problem is that, over time, configure.py has been tweaked and modified to solve specific problems, but it appears that no effort has been made to architect this file for esier modification/expansion and more flexible operation. This happened, possibly, because it was time-efficient to just add some specific capability here or there as needed. Also, supporting a limited set of functionality that provided a number of built-in defaults with few command line switches has been adequate and convenient, up to now.

But periodically the issue of configuration not being adaptable enough has come up. When the time comes to add or change functionality it can be difficult to do because of hard-to-foresee side effects and needing to work out not only what's already being done by the logic but what's missing. 

A fix would be to decouple the current set of switches from some of their automatic defaults and add switches to handle what's been decoupled. The number of compiler switches available for GCC and VS on the various platforms is huge and I'm not proposing that we try to support all of those right away - or ever, actually.  We can, I believe, add a few well chosen switches, change some switch handling, and gain a lot of flexibility at not much cost.

Concerning the related bug 537817, the cpu and target switches will be decoupled from SDK choice on Mac when the patch for bug 537817 is pushed. There's more we can do for other platforms around those switches, but bugs need to be written to track that work. As for this bug we can take the steps necessary to add an ARM_ARCH switch and at the same time decouple some fpu, cpu, compiler and other choices. There are several questions that need to be answered first:

- What should the behavior be when no arm_arch parameter is passed? Should we just compile for armv5, or do gcc/VS have a default for -march/-QR (having trouble finding info on this)? What fpu should be selected: vfp for GCC and fpe for VS? That's basically how it works now.

What combinations of arm and fpu do we want to build? For reference a useful page on ARM architecture and versions is: http://en.wikipedia.org/wiki/ARM_architecture. Here's a simple preliminary matrix:

--arm_arch=armv5 	arm_fpu=vfp, fpe, fpa 
--arm_arch=armv6	arm_fpu=vfp, fpe, fpa
--arm_arch=armv7-a 	arm_fpu=vfp, fpe, fpa, neon
--arm_arch=armv8?

- Should we keep soft-float support automatic for the time being?

- Currently float-abi is set to 'softfp' for both vfp and neon - should we keep that as an automatic choice?

Comment 3

[Edwin Smith]

+1 to cleaning up the code in configure.py and its dependents.  In general, its best for refactoring patches to be separate from ones that add new capability, but its fine to group them with the bugs that drive the new capabilities.  (for example in bug 537817, a logical patch sequence would be first to refactor, then to add the new flags).

caution: be sure to understand the vm's feature system as work progresses (see core/avmfeatures.as).

> - What should the behavior be when no arm_arch parameter is passed?

I would expect to get whatever the compiler uses as its own default arch, if nothing was specified explicitly.  ie no flag to configure equates to no flag to the compiler.

> Should we just compile for armv5, or do gcc/VS have a default for -march/-QR (having
> trouble finding info on this)?

I'm fairly certian both have defaults, but I dont know what those defaults are.  For GCC, its default -march is probably based on an option to how GCC was built, and will depend heavily on the toolchain in use.  I have no idea about VS, but my experience (no later than WinMo 6) is they had poor to nonexistant support for ARMABI and VFP.  

> What combinations of arm and fpu do we want to build? For reference a useful
> page on ARM architecture and versions is:
> http://en.wikipedia.org/wiki/ARM_architecture. Here's a simple preliminary
> matrix:
> 
> --arm_arch=armv5     arm_fpu=vfp, fpe, fpa 
> --arm_arch=armv6    arm_fpu=vfp, fpe, fpa
> --arm_arch=armv7-a     arm_fpu=vfp, fpe, fpa, neon
> --arm_arch=armv8?

VFP is the only FPU we "care" about. For the JIT, it's either VFP or soft-float.  The JIT supports runtime detection of VFP and does not have ifdefs to turn it off, so any testing of soft-float on a VFP system would be via comandline args, and any testing of VFP on a softfloat system (via emulation) would not be supported by our JIT.  (but would work for C++ code).  IIRC there is a distinction between VFP versions (VFPv3 is the variant used with NEON) but i have given up trying to memorize what all the acronyms mean.

> - Should we keep soft-float support automatic for the time being?
> 
> - Currently float-abi is set to 'softfp' for both vfp and neon - should we keep
> that as an automatic choice?

For both questions, i think the answer is "yes" but I dont understand what the alternative is.  explicit options with no defaults?

Comment 4

[James Sudduth]

> For both questions, i think the answer is "yes" but I dont understand what the
> alternative is.  explicit options with no defaults?
I didn't express this well. I was just wondering if we want to put soft-float and float-abi under switch control or continue to default them as we do now. Looks like we'll continue the current practice.

Comment 5

[Edwin Smith]

Typically for the VM, if we need to test one way or the other, its because we want to test out the JIT.  Since the JIT can detect softfloat or VFP at runtime, and we can override that with a VM command line switch, I think its fine to leave both as automatic.

If the engineering isn't hard, adding explicit options for softloat would be nice.  As for float-abi, thats less important and can stay automatic for the forseeable future.

Comment 6

[James Sudduth]

Attachment: Adding an arm-arch switch

Ignore the lines in the patch file that look like they were removed then identically replaced - my editor is set to remove extraneous white space at line ends.

If you wish to build for a particular arm architecture you must now use the '--arm-arch' switch. If you don't pass the '--arm-arch' switch you will get whatever architecture the machine you're building on defaults to, if any.

A typical use of the arm-arch switch looks like this for GCC:

	--arm-arch=armv7-a

and like this for VS:

	--arm-arch=arch6

You don't need to specify '-march=' for GCC or '-QR' for VS; the architecture string you pass in will be combined with those flags for you.

Note you can pass any string you like in --arm-arch, so now you will need to know what architecture is appropriate for the fpu/neon switches you're using to avoid unforeseen results. On linux currently we build using 'armv6' paired with '--enable-arm-fpu' and 'armv7-a' paired with '--enable-arm-neon'. On Winmobile we use '--enable-arm-fpu' with both 'arch5' and 'arch6' .

I modified tamarinredux.py with the appropriate --arm-arch switches to make the arm builds come out as they were when the defaults were in force.  But now you can try a few different builds that before would have required you to modify the make file after configure.py generated it.

Comment 7

[James Sudduth]

Attachment: Minor changes to arm-arch argument order.

Also removed all the line ending scruff in the original patch.

Comment 8

[James Sudduth]

Attachment: Fixed a cut-and-paste typo.

Comment 9

[James Sudduth]

Attachment: Fix a missed change in /build/getopt.py

Comment 10

[James Sudduth]

Attachment: Fix a missed change in /build/getopt.py.