[M3devel] loophole/copysign

[Tony Hosking]

A designator is something that can be assigned to as well as read from.  It says nothing about it being in memory.  A value cannot be assigned to.

On 5 Jul 2010, at 06:42, Jay K wrote:

> 
> 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
>> 
>