Re: [Caml-list] New experimental ARM backend [was: OCaml maintenance status / community fork (again)]

[Benedikt Meurer <benedikt.meurer@googlemail.com>]

On Dec 14, 2011, at 10:18 , Mark Shinwell wrote:

>> - Support for both softfp and VFPv3-D16 (if present).
>> - Properly supports interworking with Thumb/Thumb-2 code (for both OCaml and C code!)
>> - Supports dynamic linking and large memory models.
>> - Optional support for position-independent code via -fPIC, disabled by default and not required for natdynlink.
>> - Can emit both ARM and Thumb-2 code (currently Thumb-2 is used for ARMv7+ and ARM is used for everything else), with avg. code size savings of 27% for Thumb-2 (quite close the optimal 30% advertised by ARM Ltd.). I may also add support to emit small functions using Thumb-1 (for pre-ARMv7 / armel) in the future to reduce code size.
>> - Supports both AAPCS (armel) as well as extended VFP calling conventions (armhf).
>> - Properly supports backtraces.
>> - Recognizes several special ARM instructions (=> reduced code size and latency).
>> - Does not rely on GCC internals, but uses the standard ARM EABI runtime.
> 
> This looks like an impressive amount of work.  I'd like to suggest that a good
> approach to getting some/all of this merged might be to divide the patch up
> into smaller units each addressing a particular deficiency or implementing
> a particular feature.  In that way it should be more straightforward to
> understand the effects on the whole system of each particular patch and
> maintain stability and compatibility.  I understand that this might cause some
> work and that some of the patches might be intertwined.  (Another approach
> might be to introduce this backend as a second ARM backend with the
> understanding that it may be experimental to a certain extent---but I think
> that's less satisfactory, and less likely to find favour with everyone.)
> 
> Which items from the above list would you most like to see in the core
> distribution?  I would have thought the basic VFP support was fairly high
> up the list.

The port is not in a clean state yet. It's still a bit messy, and I'm going to separate various things first (i.e. select FPU / CPU independent of platform ABI, for example use VFPv3 with softfp EABI, etc. or use Thumb-2 on armel, etc.). I hope to get some more time to work on it during the week. You can follow the work at:

http://github.com/bmeurer/ocaml-arm

Testing and feedback is always welcome, of course.

Concerning your proposal to split the patch into multiple smaller patches:

(a) This would probably result in roughly two patches, the first one to fix the existing armel port, and the second one to add support for FPUs, armhf EABI, Thumb, Thumb-2, etc. (these depend on each other in various ways).
(b) It would be a lot of work for almost no benefit, because it is an almost completely new backend and not simply a set of bug fixes for the existing ARM backend, and must be treated this way. And even if I'd spend my days splitting up the patch, there's still that unresolved OCaml contributions issue (i.e. high probability of wasting my time because that patch set will just idle in Mantis).

> Mark

Benedikt