[erlang-bugs] --enable-hipe on pxa255

[Mikael Pettersson]

On Tue, 5 Dec 2006 00:47:07 +0100, Christophe Romain wrote:
> I'm compiling R11B-2 on XScale-PXA255 rev 6 (v5l), gcc-4.1.1,  
> binutils-2.17.50, libc6-2.5
> Target: arm-linux-gnueabi soft-float
> uname -m -> armv5tel
> 
> when i configure with --enable-hipe, I could not compile erl_bif_info.
> the problem is that erts/emulator/armv5tel-unknown-linux-gnu/ 
> erl_atom_table.h does not contains the last 3 lines (don't ask me why):
> #define am_fconv_constant make_atom(807)
> #define am_inc_stack_0 make_atom(808)
> #define am_arm make_atom(809)

They're not there because ARCH=noarch (see below).

> finally, link stage did not pass.
> the problem is that all erts/emulator/obj/armv5tel-unknown-linux-gnu/ 
> opt/hybrid/hipe_arm*.o are not there.
> 
> the whole problem is I have ARCH=noarch defined into erts/emulator/ 
> armv5tel-unknown-linux-gnu/Makefile instead of ARCH=arm
> 
> correction:
> ARCH is defined by configure, into erts/configure.in we can see:
>      294 ARCH=noarch
>      295 case `uname -m` in
> [...CUT...]
>      310 armv5b) ARCH=arm;;
>      311 armv5teb)   ARCH=arm;;
>      312 esac
> 
> here is the point: armv5tel is not listed
> may "armv5*) ARCH=arm;;" be a safe patch ?

Not at the moment.

> and what about armv4l ? (does hipe support that architecture)

HiPE currently requires ARMv5b, i.e. ARMv5 (or better) in big-endian mode.

Supporting pre-ARMv5 would require generating worse code, something
I really don't want to do unconditionally. There could possibly be
a HiPE compiler target option for selecting ARMv4 output, but that
would also need object code format changes and new checks to verify
object code compatibility before loading it. ARMv4 is ancient so
why bother?

Supporting little-endian would require a mechanism for communicating
the endianess of the target to the compiler. Like ARMv4 it would also
need object code format changes and new compatibility checks in the loader.
I know many ARMs run in little-endian mode, so this change has some merit;
however all my ARMs are big-endian XScales so I wouldn't be able to test it.

/Mikael