[M3devel] M3CG loophole operator is not LOOPHOLE (but what?)

[Jay K]

I don't recall...but it doesn't look like M3C handles this specially,but indeed m3cc has special logic for loophole and floats. Ugh.It makes a temporary.

I'll have to experiment.

The right thing to do, really, is take the address of a float, loopholethat into an address of another type, and dereference that.Not in the backend, but in the Modula-3 code.

Never to loophole to or from a float value.And hardly ever loophole values at all.Loopholing between pointers and same-sized integers, ok.Or pointers and other pointers, ok.

I don't know if it called loophole, but between varying sized/signedness integers also ok.(really that is chop or extend)

We should considering changing m3front to honor these rules.That is how you write semi-portable C to dissect floats.Or via unions.

There are intrinsics in some compilers for doing better.Visual C++ for non-x86 platforsm (ARM and CE) has it right, with stuff like_CopyDoubleToInt64, _CopyInt64ToDouble, _CopyInt32ToFloat, CopyFloatToInt32.You can argue the names, but really those are the exact 4 intrinsics you want.Leaving it to the compiler to know if it can do a register move or must go through memory.But the portable way requires going through memory.

And, really, put all the float dissection into C anyway.

 - Jay


> Date: Thu, 10 Dec 2015 12:15:48 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?)
> 
> I have just discovered the hard way that the following comment, from M3CG_Ops.i3:
> 
>    loophole (from, two: ZType);
>    (* s0.two := LOOPHOLE(s0.from, two) *)
> 
> is not true.
> 
> The front end can produce M3CG loophole ops in which the two types do not have
> the same size.  For example, the front end passes a small exception argument
> to RaiseEx by value as CGType.Addr, whose size is native word size, and if
> the argument has a different stack size (e.g. REAL is 32-bit, even on a native
> 64-bit machine), then it first converts it using the M3CG loophole operator.
> 
> Almost the same thing can happen for an explicit LOOPHOLE in M3 source code.  On a
> 64-bit machine, compiling libm3/src/geometry/Transform.m3, M3 source code
> equivalent to:
> 
>    LOOPHOLE (REALvariable, BITS BITSIZE(REAL) FOR [-16_7fffffff-1 .. 16_7fffffff])
> 
> (translated by CastExpr.m3:286) produces almost the same M3CG loophole operator,
> because the stack size of the subrange is 64-bit, even though its memory size is
> 32.  So the loophole comes out converting REAL to Int64.  (Note that BITS has no
> effect, since the type is not used as a field or array element).
> 
> Since loophole takes its operand off the abstract stack and puts its result back
> there, the stack size is the right one to use here, for both from-type and to-type.
> 
> But what are the complete rules about loophole?   Apparently some combinations
> really are bitcasts, but which ones?  Exactly those where the sizes match?  What
> is the actual conversion for other combinations?  32-bit REAL to 64-bit integer
> or address is particularly unclear.
> 
> If anybody has any knowledge about this, it would be helpful.  There is quite a
> bit of code to vet, otherwise.  15 different places in the front end generate
> loophole.
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20151211/10a19274/attachment-0002.html>