Re: [9fans] kenc vlong double

is there any reason to handle the as single operations instead of breaking it down into separate and operations? that is, is (a = b) always equivalent to (a = a b)? -- cinap

Re: [9fans] kenc vlong double

On 13 September 2015 at 19:55, Charles Forsyth wrote: > On 13 September 2015 at 19:46, wrote: > >> so we really want to have n->type == double/float > > > no, it happens to be wrong for ordinary integers too: > > > int > x(int a, double d) >

Re: [9fans] kenc vlong double

On 14 September 2015 at 13:59, wrote: > is there any reason to handle the as single operations instead > of breaking it down into separate and operations? that is, > is (a = b) always equivalent to (a = a b)? > you then have to fuss whether the evaluation of a has

Re: [9fans] kenc vlong double

thanks. -- cinap

Re: [9fans] kenc vlong double

On 14 September 2015 at 14:18, Charles Forsyth wrote: > 8c is a little more > involved because of the 387's architecture. there probably won't be much > code, > but it's fiddly. > in fact it was easy. i'll collect the changes shortly.

[9fans] kenc vlong double

the following code generates unhandled instructions for the linker on 64 bit simulating archs (8c, 5c): vlong v; double d; v += d; == cgen == ASADD DOUBLE (1) a.c:13 NAME "v" -8 <11> VLONG a.c:13 NAME "d" -16 <11> DOUBLE a.c:13 term% 8c -S a.c ... FMOVD d+-16(SP),F0

Re: [9fans] kenc vlong double

> MOVLv+-8(SP),F0 <- nope. actually, double nope. the move if implemented as written is wrong. we want to move a quad to a float, not a long to a float. - erik

Re: [9fans] kenc vlong double

On 13 September 2015 at 15:23, wrote: > > lets see what charles thinks about this. I thought at first that one had been fixed some time ago, but it was probably just the version with compiled code (eg, amd64). i'll have a look at it.

Re: [9fans] kenc vlong double

the problem is v += d propagates the whole expression to double. so we somehow need to convert v to double, do the then convert back but return the double result. i tried (unsuccessfully) to come up with something like this below in com64, but i dont know what i'm doing and someone who knows

Re: [9fans] kenc vlong double

> --- a/sys/src/cmd/cc/com.cSun Sep 13 13:51:00 2015 +0200 > +++ b/sys/src/cmd/cc/com.cSun Sep 13 19:59:43 2015 +0200 > @@ -182,8 +182,8 @@ > r = new1(OCAST, n->right, Z); > r->type = t; > n->right = r; > -

Re: [9fans] kenc vlong double

On 13 September 2015 at 19:46, wrote: > so we really want to have n->type == double/float no, it happens to be wrong for ordinary integers too: int x(int a, double d) { a += (a += d); return a; } should have the outer += done as int using the result of a += d as

Re: [9fans] kenc vlong double

ah, that makes sense. so the bug is in com.c where we use arith() to figure out the type of the operation (which looks in a table indexed by the types of both sides)? but we should instead just assign the type from the left hand side? just assigning t to n->type fixes the type, but why did it

Re: [9fans] kenc vlong double

On 13 September 2015 at 19:21, erik quanstrom wrote: > isn't the && !mixedasop() added to the condition the problem: > the cast should not be elided if it's a float/double. t > the test is correct, because in mixed-mode assignment, you want to do the calculation in

Re: [9fans] kenc vlong double

On 13 September 2015 at 19:01, wrote: > just assigning t to n->type fixes the type, but why did it > call arith() in the first place? > for P += I, P -= I, and other more straightforward cases of mixed-modes, you need "the usual arithmetic conversions" first.

Re: [9fans] kenc vlong double

> On 13 September 2015 at 19:21, erik quanstrom wrote: > > > isn't the && !mixedasop() added to the condition the problem: > > the cast should not be elided if it's a float/double. t > > > > the test is correct, because in mixed-mode assignment, you want to do the >

Re: [9fans] kenc vlong double

so we really want to have n->type == double/float so the arithmetic is done in the right domain, but com64 needs to check for this special case and convert back and forth and then change n->type to vlong? -- cinap

Re: [9fans] kenc vlong double

On 13 September 2015 at 15:23, wrote: > the problem is v += d propagates the whole expression > to double. so we somehow need to convert v to double, > do the then convert back but return the double > result. > the type of E1 op=E2 is the same as the type of E1 = E1