[erlang-questions] HiPE on MIPS/MIPS-64

[Jim Thompson]

Mikael Pettersson wrote:

> I had a look at supporting MIPS in HiPE last year, and from what I remember,
> it would be straightforward except for a few issues:
> - MIPS has no condition codes. This makes overflow in arithmetic difficult
>   to detect. I'm not sure if this can be hidden completely in the backend
>   or if it will need some hooks in RTL.

Well, 'addu' is silent on overflow, but 'add' will cause a trap on 
overflow.  The same applies for 'addiu' .vs 'addi', etc, but traps are 
expensive.

However, I think the code is straight-forward.  For add:

	addu t0, t1, t2	/* compute sum */
	xor  t3, t1, t2 /* if operands have opposite signs */
	bltz t3, no_ovf /* then overflow is not possible
	/* operands have same sign */
	xor  t3, t0, t1 /* if sum does not have same sign */
	bltz t3, do_sat /* then add overflowed */
	nop
no_ovf:
	ret

do_sat:
	/* we know overflow has occurred, and we know both operands
	   have the same sign, so we look at the sign of an operand.
	   If its positive, we limit (saturate) to positive full scale.
	   If its negative, we saturate negative full-scale */

	li v0, 0x7fffffff /* positive full scale */
	li t8, 0x80000000 /* negative full scale */
	slt $1, $0, t1    /* check sign of operand */
	movn v0, t8, $1   /* saturate */
	ret

signaling this to the back-end is still 'mystery meat' to me, since I 
don't know that much about HiPE.

You don't need to worry about (integer) multiplies/divides on MIPS, 
because all multiplies are 32 bits x 32 bits and the destination 
register is always a special-purpose 64 bit register.

> - MIPS partitions the memory into 256MB regions, and direct branches can
>   only reach targets in the same region. The consequence is that branches
>   between regions must be routed via trampolines containing indirect jumps.

The branch instructions can only access 18 bits of offset (+/- 128KB). 
  The jump instructions are limited to a given 256MB region.

The jump-register instructions are how you get around this limitation, 
given my understanding.

>   HiPE already uses trampolines on PPC32 and ARM, so this is doable. It
>   does add complexity to the runtime system and the code loader, however.
> - If hardware floating-point is to be used, then you'll need to first
>   port the base BEAM runtime system to use floating-point exceptions.

> HiPE worked just fine on Solaris/x86 and Solaris/amd64
> last time I checked.

My mistake.