[M3devel] loophole/copysign

[Jay K]

another idea: let's not use bitfield ref for float/double

 - Jay



----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Mon, 5 Jul 2010 11:25:19 +0000
> Subject: Re: [M3devel] loophole/copysign
>
>
> Hm. it seems that it might be important to preserve the "designatorness", like in:
>
> libm3/...RandomReal.m3:
>
>   VAR frac, exp: INTEGER; result: LONGREAL;
>
>     (* Repack as LONGREAL: *)
>     WITH lr = LOOPHOLE (result, LongRealRep.T) DO
>       lr.sign := 0;
>       lr.exponent := exp;
>       lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff),
>                                       -(WordSize - 1 - FractionBits));
>       lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff);
>     END;
>
>
>  - Jay
>
> ----------------------------------------
> > From: jay.krell at cornell.edu
> > To: m3devel at elegosoft.com
> > Date: Mon, 5 Jul 2010 10:42:57 +0000
> > Subject: Re: [M3devel] loophole/copysign
> >
> >
> > Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"?
> >
> >
> > http://www-plan.cs.colorado.edu/diwan/modula3/designators.html
> >
> > An identifier is a writable designator
> > if it is declared as a variable,
> > is a VAR or VALUE parameter,
> > is a local of a TYPECASE
> > or TRY EXCEPT statement,
> > or is a WITH local that is bound to a writable designator.
> > An identifier is a readonly designator if it is
> > a READONLY parameter,
> > a local of a FOR statement,
> > or a WITH local bound to a non-designator or
> > readonly designator.
> >
> >
> >
> > I guess a designator is what I would think of a "variable" or "read only variable"?
> > Something that either is "in memory" or can "reasonably" be put there?
> >
> >
> > 1 + 2 is not a designator.
> >
> >
> > Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables"
> >
> >
> > Anything with a name??? (not functions/modules/generics -- "named data")
> >
> >
> > Anyway, the next questions include:
> >
> >
> > In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"?
> > I realize, probably a deoptimization.
> > I think this lets the backend work.
> >
> >
> > And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more?
> > I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy.
> >
> >
> > I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare..
> >
> >
> > - Jay
> >
> >
> >
> > ----------------------------------------
> > > From: jay.krell at cornell.edu
> > > To: m3devel at elegosoft.com
> > > Date: Mon, 5 Jul 2010 09:24:20 +0000
> > > Subject: [M3devel] loophole/copysign
> > >
> > >
> > > Our codegen is remarkably low level. That is, lower level earlier than C.
> > >
> > >
> > > gcc/m3cg -ftree-dump-all
> > >
> > >
> > > As early as LongFloat.mc.003t.original, the first file dumped, we have:
> > >
> > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y)
> > > {
> > > xreel M3_CtKayy__result;
> > > xreel M3_CtKayy_res;
> > >
> > > xreel M3_CtKayy__result;
> > > xreel M3_CtKayy_res;
> > > M3_CtKayy_res = M3_CtKayy_x;
> > > BIT_FIELD_REF = (word_8) ((int_64)
> > > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255);
> > > = M3_CtKayy_res;
> > > return ;
> > > }
> > >
> > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have:
> > >
> > > copy_sign_f (from, to)
> > > {
> > > float res;
> > > float D.1918;
> > > D.1917;
> > > struct float_t * from.1;
> > > struct float_t * res.0;
> > >
> > > :
> > > res = to_1;
> > > res.0_4 = (struct float_t *) &res;
> > > from.1_5 = (struct float_t *) &from;
> > > D.1917_6 = from.1_5->sign;
> > > res.0_4->sign = D.1917_6;
> > > D.1918_7 = res;
> > > return D.1918_7;
> > >
> > > }
> > >
> > >
> > > See, you know, from gcc's point of view, we don't have any records/structs/unions.
> > > Just integers and offsets from them mostly.
> > >
> > >
> > > The right fix is to build up types.
> > > That way also debugging with gdb will have a chance.
> > > Perhaps not a small amount of work. But maybe not too bad.
> > >
> > >
> > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes.
> > > At least if one type but not the other is floating point.
> > > I don't know if that will work, but maybe.
> > >
> > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or
> > > store volatile.
> > >
> > > - Jay
> > >
> >
>