Re: [9fans] ARM compiler shortcoming?

Re: [9fans] ARM compiler shortcoming?

[erik quanstrom]

; 9diff com64.c
/n/sources/plan9//sys/src/cmd/cc/com64.c:275,281 - com64.c:275,280
  		case OAS:
  		case OIND:
  		case OLIST:
- 		case OCOMMA:
  			return 1;
  		case OADD:
  			a = nodaddv;

- erik

[9fans] ARM compiler shortcoming?

[Lucio De Re]

My guess is that the ARM compiler does not like 64-bit values in
conditional expressions.  The following C snippet:

	typedef unsigned long long	uvlong;

	uvlong uvinf    = ((uvlong)0x7FF00000<<32)|0x00000000;
	uvlong uvneginf = ((uvlong)0xFFF00000<<32)|0x00000000;

	double u2d(uvlong v);

	double
	__Inf(int sign)
	{
		return u2d(sign < 0 ? uvneginf : uvinf);
	}

compiled with 8c seems OK, but with 5c causes an error:

	% 5c -FTVw /tmp/nan64.c
	/tmp/nan64.c:11 unknown vlong LIST

Using an if statement seems to get rid of the problem.

++L

Re: [9fans] ARM compiler shortcoming?

[Charles Forsyth]

i've got a 5[acl] tucked away that does 64-bit operations, although
i think that particular case can be fixed more simply.

On 29 October 2011 16:29, Lucio De Re <lucio@proxima.alt.za> wrote:
> My guess is that the ARM compiler does not like 64-bit values in
> conditional expressions.  The following C snippet:
>
>        typedef unsigned long long      uvlong;
>
>        uvlong uvinf    = ((uvlong)0x7FF00000<<32)|0x00000000;
>        uvlong uvneginf = ((uvlong)0xFFF00000<<32)|0x00000000;
>
>        double u2d(uvlong v);
>
>        double
>        __Inf(int sign)
>        {
>                return u2d(sign < 0 ? uvneginf : uvinf);
>        }
>
> compiled with 8c seems OK, but with 5c causes an error:
>
>        % 5c -FTVw /tmp/nan64.c
>        /tmp/nan64.c:11 unknown vlong LIST
>
> Using an if statement seems to get rid of the problem.
>
> ++L
>
>
>

Re: [9fans] ARM compiler shortcoming?

[Charles Forsyth]

i've tried this example with a cc that has com64.c unchanged from sources
(ie, without the change erik suggested),
and a 5c that has no relevant changes at all, and it was fine.

On 29 October 2011 16:29, Lucio De Re <lucio@proxima.alt.za> wrote:
> My guess is that the ARM compiler does not like 64-bit values in
> conditional expressions.  The following C snippet:
>
>        typedef unsigned long long      uvlong;
>
>        uvlong uvinf    = ((uvlong)0x7FF00000<<32)|0x00000000;
>        uvlong uvneginf = ((uvlong)0xFFF00000<<32)|0x00000000;
>
>        double u2d(uvlong v);
>
>        double
>        __Inf(int sign)
>        {
>                return u2d(sign < 0 ? uvneginf : uvinf);
>        }
>
> compiled with 8c seems OK, but with 5c causes an error:
>
>        % 5c -FTVw /tmp/nan64.c
>        /tmp/nan64.c:11 unknown vlong LIST
>
> Using an if statement seems to get rid of the problem.
>
> ++L
>
>
>

Re: [9fans] ARM compiler shortcoming?

[Lucio De Re]

> i've tried this example with a cc that has com64.c unchanged from sources
> (ie, without the change erik suggested),
> and a 5c that has no relevant changes at all, and it was fine.

I'm too stupid to reach the right conclusion from what you are saying:
does this mean that I have a dated 5c?  I'm not sure what Erik's
change is intended for, but I doubt it will fix the problem.

++L

Re: [9fans] ARM compiler shortcoming?

[Charles Forsyth]

sorry, i was misleading. i meant a 5c that does vlongs more directly,
not a 5c that does the new arm 64-bit operations. that compiler would
have a different name.

> i've got a 5[acl] tucked away that does 64-bit operations

Re: [9fans] ARM compiler shortcoming?

[Lucio De Re]

> i've got a 5[acl] tucked away that does 64-bit operations, although
> i think that particular case can be fixed more simply.

Will you please upload what you can find somewhere public?

I don't know the ARM at all, but the convergence of Go, Android and
64-bit ARM chips in mobile phones can't be too distant.

++L

Re: [9fans] ARM compiler shortcoming?

[Lucio De Re]

> /sys/src/cmd/cc/com64.c:275,281

The context is:

int
com64(Node *n)
{
	...
		switch(n->op) {
		default:
			diag(n, "unknown vlong %O", n->op);
		case OFUNC:
			n->complex = FNX;
		case ORETURN:
		case OAS:
		case OIND:
		case OLIST:
		case OCOMMA:
			return 1;
		case OADD:
			a = nodaddv;
			goto setbop;
		case OSUB:
	...
}

and it seems to me that a better answer would be to change the error
message to something like:

	"undefined 64-bit operation: %O"

I can't see much reason to stick to vlong when it is clear that 64-bit
handling is involved.

I do wonder why 8c isn't plagued by the same problem.

++L

Re: [9fans] ARM compiler shortcoming?

[Charles Forsyth]

i've just copied across and compiled cc and 5c from sources,and that
code you posted earlier compiled without fuss.

Re: [9fans] ARM compiler shortcoming?

[Lucio De Re]

> sorry, i was misleading. i meant a 5c that does vlongs more directly,
> not a 5c that does the new arm 64-bit operations. that compiler would
> have a different name.

I seem to recall that ARM 64-bit emulation is one of Go's open TODOs.
I think thie plethora of (sub-)architectures is terribly confusing,
but it seems that what you have ought to be available, even if only
for inspection.

++L

Re: [9fans] ARM compiler shortcoming?

[Lucio De Re]

> i've just copied across and compiled cc and 5c from sources,and that
> code you posted earlier compiled without fuss.

Hm, that needs investigating, I know I have messed around with 5[acl]
for the Sheeva, but I expected regular replicas to take care of that.
Mind you, that's bad thinking, as replica does not extend outside the
386 architecture for binaries.

++L