<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yiv9475814017"><div id="yui_3_16_0_1_1450667578303_3181"><div id="yui_3_16_0_1_1450667578303_3180" style="color:#000;background-color:#fff;font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;">Hi all:<br clear="none"><div class="yiv9475814017" dir="ltr" id="yiv9475814017yui_3_16_0_1_1450651276788_6380"><div dir="ltr">I don't like to repeat nor answer myself, but for the benefit of the discussion lets put it as in the below comment UNSAFE LOOPHOLE alternative VIEW in SPIN OS [1]:</div></div><pre class="yiv9475814017" id="yiv9475814017yui_3_16_0_1_1450651276788_6403">A couple of years later, there was an OS project - called, I think, SPIN
- that built the entire OS in Modula-3. They used only a tiny amount of
UNSAFE code. One area that's often full of bit-twiddling and type
munging is network code, where you somehow need to convert a
bag-of-bytes into some typed object. The SPIN team added an interesting
primitive: "Here's a bag-of-bytes with the same size as an object of
type X. View it as an object of type X." This was legal only if every
field in X, recursively, had a type for which any bit pattern was legal.
(I'd guess - but don't know - that you could have enum type values,
with the compiler inserting a check that what was in the buffer as a
enumerated value was actually legal. It may have done this for some
other types as well - e.g., there was a CARDINAL type which was a subset
of INTEGER and consisted only of the non-negative values.)</pre><div dir="ltr" id="yiv9475814017yui_3_16_0_1_1450651276788_6380"><div id="yui_3_16_0_1_1450667578303_3459">Which inadvertently is the Modula-3 language definition but downsized in terms of UNSAFE operations for normal safety, which only lefts pointer arithmetic and DISPOSE memory management for UNSAFE operations.</div><div id="yui_3_16_0_1_1450667578303_3568"><br></div><div id="yui_3_16_0_1_1450667578303_3572" dir="ltr">Now, I wonder given that this is allowed to be safe in SPIN, what is the "UNSAFE" part of casting in Modula-3.</div><div id="yui_3_16_0_1_1450667578303_3570" dir="ltr">I Do rememeber viewing a videotape lecture of James Donahue, and speakign of UNSAFE operations, he said that they were very careful in selecting that as UNSAFE and the other operations.</div><div id="yui_3_16_0_1_1450667578303_3574" dir="ltr"><br></div><div id="yui_3_16_0_1_1450667578303_3578" style="line-height: 1.35; " class="">
<div id="yui_3_16_0_1_1450667578303_3577" style="clear: left; " class="">
<div id="yui_3_16_0_1_1450667578303_3582" style="float: left; padding-right: 0.5em;text-align: right; width: 1em;" class="">[1]</div><div id="yui_3_16_0_1_1450667578303_3576" style="margin: 0 .4em 0 1.5em;" class="">[En línea]. Disponible en: https://www.marc.info/?l=cryptography&m=139784275512662&q=raw. [Accedido: 21-dic-2015].</div>
</div><div dir="ltr">
<span id="yui_3_16_0_1_1450667578303_3585" class="" title="url_ver=Z39.88-2004&ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fzotero.org%3A2&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rft.type=webpage&rft.identifier=https%3A%2F%2Fwww.marc.info%2F%3Fl%3Dcryptography%26m%3D139784275512662%26q%3Draw"></span>
</div></div><div id="yui_3_16_0_1_1450667578303_3571" dir="ltr"><br></div><div id="yui_3_16_0_1_1450667578303_3613" dir="ltr">Thanks in advance<br></div></div><div id="yiv9475814017yui_3_16_0_1_1450651276788_6464"><span></span></div> <div id="yui_3_16_0_1_1450667578303_3426" class="yiv9475814017qtdSeparateBR"><br clear="none"><br clear="none"></div><div class="yiv9475814017yqt0233342668" id="yiv9475814017yqt53511"></div></div></div></div><div class=".yiv9475814017yahoo_quoted"> <div style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"> <div style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"> <div dir="ltr"><font size="2" face="Arial"> El Miércoles 16 de diciembre de 2015 13:02, Rodney M. Bates <rodney_bates@lcwb.coop> escribió:<br clear="none"></font></div> <br clear="none"><br clear="none"> <div class="yiv9475814017y_msg_container">The issue I raised is not with the M3 LOOPHOLE builtin function. The compiler<br clear="none">currently implements it correctly, according to the language definition, as<br clear="none">Tony quoted. The front end verifies the size equality, as required by the<br clear="none">language, then emits an intermediate "loophole" operator, which will be same<br clear="none">size, and thus well-defined as equivalent to LOOPHOLE. (And also llvm bitcast,<br clear="none">which is now being used to translate the loophole operator in this case.)<br clear="none"><br clear="none">My issue is that there are 13 other places the front-end emits an internally<br clear="none">generated "loophole", and these (almost?) all can do so with unequal sizes.<br clear="none">Moreover, what should be done with the unequal sizes varies from place to place.<br clear="none"><br clear="none">It is possible that the "loophole" operator can be defined to do what is<br clear="none">correct in every case by a conditional rule based on the two types. I<br clear="none">need to do another pass through them to be sure. This may be the quickest<br clear="none">way to get the llvm backend working, but I think it is not good design.<br clear="none">It would be carefully tailored to just a specific set of uses of "loophole",<br clear="none">instead of making a reasonable abstraction out of" loophole". It would be<br clear="none">rather fragile and involve a lot of analysis on the full Cartesian product<br clear="none">of both supplier and client side cases of "loophole" to define and verify.<br clear="none"><br clear="none">The best way, IMO, is to fix each "loophole"-generating site to use other<br clear="none">operators, as appropriate. It is at these sites that it is known what<br clear="none">should be done in each case. I suspect existing intermediate operators<br clear="none">"widen", "insert_mn" and "extract_mn" are sufficient. Again, another pass<br clear="none">through the cases is indicated. The only pragmatic drawback to this is<br clear="none">that this requires considerable care and retesting to avoid breakage of<br clear="none">existing behavior. At worst, it risks inability to bootstrap the compiler.<br clear="none">I would prefer one change at a time, each tested by reboostrapping twice.<br clear="none"><br clear="none"><br clear="none"><br clear="none">On 12/13/2015 08:40 PM, Daniel Alejandro Benavides D. wrote:<br clear="none">> Hello:<br clear="none">> Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement it".<br clear="none">> Thanks in advance<br clear="none">><br clear="none">><br clear="none">><br clear="none">> El Domingo 13 de diciembre de 2015 21:20, Jay <<a rel="nofollow" shape="rect" ymailto="mailto:jay.krell@cornell.edu" target="_blank" href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> escribió:<br clear="none">><br clear="none">><br clear="none">> I know, but this pattern is pretty rare.<br clear="none">><br clear="none">> - Jay<br clear="none">><br clear="none">> On Dec 13, 2015, at 1:46 AM, Antony Hosking <<a rel="nofollow" shape="rect" ymailto="mailto:hosking@purdue.edu" target="_blank" href="mailto:hosking@purdue.edu">hosking@purdue.edu</a> <mailto:<a rel="nofollow" shape="rect" ymailto="mailto:hosking@purdue.edu" target="_blank" href="mailto:hosking@purdue.edu">hosking@purdue.edu</a>>> wrote:<br clear="none">><br clear="none">>> Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register.<br clear="none">>> The intent is to allow the backend to avoid that.<br clear="none">>><br clear="none">>>> On 11 Dec 2015, at 5:53 PM, Jay K <<a rel="nofollow" shape="rect" ymailto="mailto:jay.krell@cornell.edu" target="_blank" href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a> <mailto:<a rel="nofollow" shape="rect" ymailto="mailto:jay.krell@cornell.edu" target="_blank" href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>>> wrote:<br clear="none">>>><br clear="none">>>> The right thing to do, really, is take the address of a float, loophole<br clear="none">>>> that into an address of another type, and dereference that.<br clear="none">>>> Not in the backend, but in the Modula-3 code.<br clear="none">>>><br clear="none">>><br clear="none">><br clear="none">> _______________________________________________<br clear="none">> M3devel mailing list<br clear="none">> <a rel="nofollow" shape="rect" ymailto="mailto:M3devel@elegosoft.com" target="_blank" href="mailto:M3devel@elegosoft.com">M3devel@elegosoft.com</a> <mailto:<a rel="nofollow" shape="rect" ymailto="mailto:M3devel@elegosoft.com" target="_blank" href="mailto:M3devel@elegosoft.com">M3devel@elegosoft.com</a>><br clear="none">> <a rel="nofollow" shape="rect" target="_blank" href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a><br clear="none">><br clear="none">><br clear="none">><br clear="none">><br clear="none">> _______________________________________________<br clear="none">> M3devel mailing list<br clear="none">> <a rel="nofollow" shape="rect" ymailto="mailto:M3devel@elegosoft.com" target="_blank" href="mailto:M3devel@elegosoft.com">M3devel@elegosoft.com</a><br clear="none">> <a rel="nofollow" shape="rect" target="_blank" href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a><br clear="none">><br clear="none"><br clear="none">-- <br clear="none">Rodney Bates<br clear="none"><a rel="nofollow" shape="rect" ymailto="mailto:rodney.m.bates@acm.org" target="_blank" href="mailto:rodney.m.bates@acm.org">rodney.m.bates@acm.org</a><div class="yiv9475814017yqt0141890409" id="yiv9475814017yqtfd50699"><br clear="none">_______________________________________________<br clear="none">M3devel mailing list<br clear="none"><a rel="nofollow" shape="rect" ymailto="mailto:M3devel@elegosoft.com" target="_blank" href="mailto:M3devel@elegosoft.com">M3devel@elegosoft.com</a><br clear="none"><a rel="nofollow" shape="rect" target="_blank" href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a></div><br clear="none"><br clear="none"></div> </div> </div> </div></div></body></html>