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

Mon Dec 21 04:18:17 CET 2015

Hi all:
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]: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.)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.
Now, I wonder given that this is allowed to be safe in SPIN, what is the "UNSAFE" part of casting in Modula-3.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.
  [1][En línea]. Disponible en: https://www.marc.info/?l=cryptography&m=139784275512662&q=raw. [Accedido: 21-dic-2015].  
Thanks in advance

    El Miércoles 16 de diciembre de 2015 13:02, Rodney M. Bates <rodney_bates at lcwb.coop> escribió:

 The issue I raised is not with the M3 LOOPHOLE builtin function.  The compiler
currently implements it correctly, according to the language definition, as
Tony quoted.  The front end verifies the size equality, as required by the
language, then emits an intermediate "loophole" operator, which will be same
size, and thus well-defined as equivalent to LOOPHOLE.  (And also llvm bitcast,
which is now being used to translate the loophole operator in this case.)

My issue is that there are 13 other places the front-end emits an internally
generated "loophole", and these (almost?) all can do so with unequal sizes.
Moreover, what should be done with the unequal sizes varies from place to place.

It is possible that the "loophole" operator can be defined to do what is
correct in every case by a conditional rule based on the two types.  I
need to do another pass through them to be sure.  This may be the quickest
way to get the llvm backend working, but I think it is not good design.
It would be carefully tailored to just a specific set of uses of "loophole",
instead of making a reasonable abstraction out of" loophole".  It would be
rather fragile and involve a lot of analysis on the full Cartesian product
of both supplier and client side cases of "loophole" to define and verify.

The best way, IMO, is to fix each "loophole"-generating site to use other
operators, as appropriate.  It is at these sites that it is known what
should be done in each case.  I suspect existing intermediate operators
"widen", "insert_mn" and "extract_mn" are sufficient.  Again, another pass
through the cases is indicated.  The only pragmatic drawback to this is
that this requires considerable care and retesting to avoid breakage of
existing behavior.  At worst, it risks inability to bootstrap the compiler.
I would prefer one change at a time, each tested by reboostrapping twice.

On 12/13/2015 08:40 PM, Daniel Alejandro Benavides D. wrote:
> Hello:
> 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".
> Thanks in advance
>
>
>
> El Domingo 13 de diciembre de 2015 21:20, Jay <jay.krell at cornell.edu> escribió:
>
>
> I know, but this pattern is pretty rare.
>
>  - Jay
>
> On Dec 13, 2015, at 1:46 AM, Antony Hosking <hosking at purdue.edu <mailto:hosking at purdue.edu>> wrote:
>
>> Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register.
>> The intent is to allow the backend to avoid that.
>>
>>> On 11 Dec 2015, at 5:53 PM, Jay K <jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>> wrote:
>>>
>>> The right thing to do, really, is take the address of a float, loophole
>>> that into an address of another type, and dereference that.
>>> Not in the backend, but in the Modula-3 code.
>>>
>>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com <mailto:M3devel at elegosoft.com>
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>
>
>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>

-- 
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/20151221/5ec2dc2d/attachment-0002.html>