<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>I don't recall...but it doesn't look like M3C handles this specially,<div>but indeed m3cc has special logic for loophole and floats. Ugh.</div><div>It makes a temporary.</div><div><br></div><div><br></div><div>I'll have to experiment.</div><div><br></div><div><br></div><div>The right thing to do, really, is take the address of a float, loophole</div><div>that into an address of another type, and dereference that.</div><div>Not in the backend, but in the Modula-3 code.</div><div><br></div><div><br></div><div>Never to loophole to or from a float value.</div><div>And hardly ever loophole values at all.</div><div>Loopholing between pointers and same-sized integers, ok.</div><div>Or pointers and other pointers, ok.</div><div><br></div><div><br></div><div>I don't know if it called loophole, but between varying sized/signedness integers also ok.</div><div>(really that is chop or extend)</div><div><br></div><div><br></div><div>We should considering changing m3front to honor these rules.</div><div>That is how you write semi-portable C to dissect floats.</div><div>Or via unions.</div><div><br></div><div><br></div><div>There are intrinsics in some compilers for doing better.</div><div>Visual C++ for non-x86 platforsm (ARM and CE) has it right, with stuff like</div><div>_CopyDoubleToInt64, _CopyInt64ToDouble, _CopyInt32ToFloat, CopyFloatToInt32.</div><div>You can argue the names, but really those are the exact 4 intrinsics you want.</div><div>Leaving it to the compiler to know if it can do a register move or must go through memory.</div><div>But the portable way requires going through memory.</div><div><br></div><div><br></div><div>And, really, put all the float dissection into C anyway.</div><div><br></div><div><br></div><div> - Jay<br><br><br><div>> Date: Thu, 10 Dec 2015 12:15:48 -0600<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?)<br>> <br>> I have just discovered the hard way that the following comment, from M3CG_Ops.i3:<br>> <br>> loophole (from, two: ZType);<br>> (* s0.two := LOOPHOLE(s0.from, two) *)<br>> <br>> is not true.<br>> <br>> The front end can produce M3CG loophole ops in which the two types do not have<br>> the same size. For example, the front end passes a small exception argument<br>> to RaiseEx by value as CGType.Addr, whose size is native word size, and if<br>> the argument has a different stack size (e.g. REAL is 32-bit, even on a native<br>> 64-bit machine), then it first converts it using the M3CG loophole operator.<br>> <br>> Almost the same thing can happen for an explicit LOOPHOLE in M3 source code. On a<br>> 64-bit machine, compiling libm3/src/geometry/Transform.m3, M3 source code<br>> equivalent to:<br>> <br>> LOOPHOLE (REALvariable, BITS BITSIZE(REAL) FOR [-16_7fffffff-1 .. 16_7fffffff])<br>> <br>> (translated by CastExpr.m3:286) produces almost the same M3CG loophole operator,<br>> because the stack size of the subrange is 64-bit, even though its memory size is<br>> 32. So the loophole comes out converting REAL to Int64. (Note that BITS has no<br>> effect, since the type is not used as a field or array element).<br>> <br>> Since loophole takes its operand off the abstract stack and puts its result back<br>> there, the stack size is the right one to use here, for both from-type and to-type.<br>> <br>> But what are the complete rules about loophole? Apparently some combinations<br>> really are bitcasts, but which ones? Exactly those where the sizes match? What<br>> is the actual conversion for other combinations? 32-bit REAL to 64-bit integer<br>> or address is particularly unclear.<br>> <br>> If anybody has any knowledge about this, it would be helpful. There is quite a<br>> bit of code to vet, otherwise. 15 different places in the front end generate<br>> loophole.<br>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br>> _______________________________________________<br>> M3devel mailing list<br>> M3devel@elegosoft.com<br>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br></div></div> </div></body>
</html>