[Caml-list] mips32 backend without floating point hardware

[Caml-list] mips32 backend without floating point hardware

[Nicolas Ojeda Bar]

Hello list,

I am trying to get the mips o32 backend (from 1.*, ~17 years ago!)
working again on machines without *any* floating point hardware.

As suggested in the comments of selectgen.ml I overloaded

method regs_for : Cmm.machtype -> Reg.t array

to store float regs in pairs of int regs.  This works well for the
OCaml side of things, but the C abi dictates that float args should be
passed in even-odd pairs of int registers (i.e., either a0-a1 or
a2-a3).  Unfortunately I lost the Int/Float distinction after
overloading regs_for, so I can't enforce this constraint in
Proc.loc_external_arguments.  Similarly it is not possible to 8-align
extra floats in the stack since the type information is lost.

Any ideas/suggestions how to fit this situation to the existing
backend infrastructure ?

Thanks!

Best wishes,
Nicolas

Re: [Caml-list] mips32 backend without floating point hardware

[Xavier Leroy]

On 21/06/15 04:17, Nicolas Ojeda Bar wrote:
> I am trying to get the mips o32 backend (from 1.*, ~17 years ago!)
> working again on machines without *any* floating point hardware.
> [...]
> This works well for the
> OCaml side of things, but the C abi dictates that float args should be
> passed in even-odd pairs of int registers (i.e., either a0-a1 or
> a2-a3).  Unfortunately I lost the Int/Float distinction after
> overloading regs_for, so I can't enforce this constraint in
> Proc.loc_external_arguments.  Similarly it is not possible to 8-align
> extra floats in the stack since the type information is lost.
> 
> Any ideas/suggestions how to fit this situation to the existing
> backend infrastructure ?

My suggestion is just to forget about soft floating-point altogether.
The back-end hacks that were introduced 10 years ago to support soft
FP on ARM don't quite work in the general case, as you describe above.
In the meantime, hardware FP is now provided by all the processors
that are powerful enough to run OCaml code.  Why bother?

- Xavier Leroy

Re: [Caml-list] mips32 backend without floating point hardware

[Vincent Bernardoff]

On 21/06/2015 11:26, Xavier Leroy wrote:
> In the meantime, hardware FP is now provided by all the processors
> that are powerful enough to run OCaml code.  Why bother?

Hi,

This is not true, for example OpenWRT routers are powerful enough to run
OCaml code, but have no hardware FP at all.

That said, it is probably enough to run non-floating point code on those
platform.

I'm using OpenWRT (on a MIPS platform without hardware FP) to develop an
IoT (internet of things) project, and I would like to use OCaml for it.
I don't need floating point in this project but I'd like to be able to
use a "normal" OCaml ecosystem (OPAM, lwt, etc…) that does not work well
in practice without ocamlopt.

I'm going to give a go to nojb's backend without FP, and see if I use my
usual OCaml libraries with it without too much headache.

Thanks!

-- 
Vincent

Re: [Caml-list] mips32 backend without floating point hardware

[Alain Frisch]

Hi Nicolas,

On 06/21/2015 04:17 AM, Nicolas Ojeda Bar wrote:
> Any ideas/suggestions how to fit this situation to the existing
> backend infrastructure ?

Would https://github.com/ocaml/ocaml/pull/115 be useful for this?


Alain

Re: [Caml-list] mips32 backend without floating point hardware

[Stéphane Glondu]

Le 21/06/2015 12:08, Vincent Bernardoff a écrit :
> I'm using OpenWRT (on a MIPS platform without hardware FP) to develop an
> IoT (internet of things) project, and I would like to use OCaml for it.
> I don't need floating point in this project but I'd like to be able to
> use a "normal" OCaml ecosystem (OPAM, lwt, etc…) that does not work well
> in practice without ocamlopt.

In Debian, we manage to maintain architectures without ocamlopt (mips,
mipsel, ppc64el and s390x at the moment). This is one of the main
challenges when packaging for Debian (but it's not that difficult). We
also handle the special case of ocamlopt without natdynlink (which was
the case of armel for a while).

Some upstream packages do it well from the start. For others, a specific
Makefile target has to be called when ocamlopt is absent (we try to not
patch if possible). Sometimes, upstream sources have to be patched (and
we try to forward patches upstream).

Any effort to make things better would be greatly appreciated. OPAM
packages should be fixed to work without ocamlopt.

At the moment, it seems easier to fix packages so that they work without
ocamlopt than to port ocamlopt to all architectures (especially if these
ports stay unofficial). Moreover, it makes bootstrapping new
architectures easier (for example, we had OCaml packages on arm64 as
bytecode-only before its support was added in ocamlopt).


Cheers,

-- 
Stéphane

Re: [Caml-list] mips32 backend without floating point hardware

[Thomas Gazagnaire]

> Any effort to make things better would be greatly appreciated. OPAM
> packages should be fixed to work without ocamlopt.

If the library expose a specific build target for native code, it's already possible to annotate the opam file to do that, using `ocaml-native`, `ocaml-native-tools` and `ocaml-native-dynlink` predicates (see [1] for an example). It should be possible to run bulk builds for bytecode only to see which packages need their build system to be fixed. I'll try to see what we can do.

Best,
Thomas

[1]: https://github.com/ocaml/opam-repository/blob/master/packages/ocamlfind/ocamlfind.1.5.5/opam#L11

Re: [Caml-list] mips32 backend without floating point hardware

[Richard W.M. Jones]

On Mon, Jun 22, 2015 at 11:30:27AM +0200, Stéphane Glondu wrote:
> Le 21/06/2015 12:08, Vincent Bernardoff a écrit :
> > I'm using OpenWRT (on a MIPS platform without hardware FP) to develop an
> > IoT (internet of things) project, and I would like to use OCaml for it.
> > I don't need floating point in this project but I'd like to be able to
> > use a "normal" OCaml ecosystem (OPAM, lwt, etc…) that does not work well
> > in practice without ocamlopt.
> 
> In Debian, we manage to maintain architectures without ocamlopt (mips,
> mipsel, ppc64el and s390x at the moment). This is one of the main

FYI Red Hat maintain native ppc64 (big endian) and ppc64le backends.
You can find them here:

https://git.fedorahosted.org/cgit/fedora-ocaml.git/log/?h=fedora-23-4.02

 - - -

I discussed this a bit with Mark Shinwell already - I'd dearly like
for these to be maintained upstream, particularly the ppc64le one.

Access to the hardware is tricky unfortunately.  I have remote access
through work, and virtualization is a (slow) option:

https://rwmj.wordpress.com/2015/04/15/virt-builder-fedora-21-ppc64-and-ppc64le-images/

Red Hat and IBM are sponsoring a public server rack in Brno, Czech
Republic:

http://fit-rhlab.blaskovic.sk/category/open-power-hub/

I expect that the hardware will become more readily available over
the next year or two.

Rich.

-- 
Richard Jones
Red Hat