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

[Daniel Alejandro Benavides D.]

Hi:You know m3middle uses unsafe stuff, probably as Rodney points out m3front too, it doesn't have the correct implementation (as in m3middle) because it worked in another architecture, but not in here. That's why these modules need different treatment to care after release new versions.Thanks in advance
 


    El Domingo 13 de diciembre de 2015 22:19, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribió:
 

 Hi:but isn't the bit pattern, the data layout, what it makes the difference Anthony?
Thanks in advance 


    El Domingo 13 de diciembre de 2015 22:14, "Hosking, Antony L" <hosking at purdue.edu> escribió:
 

 Bits are bits.  It is implementation-dependent because bits one machine will be different on another.  My point was that the bit sizes are expected to be the same (except when T is an open array, in which case the bits form the payload of the open array, with the size constructed accordingly).

On 14 Dec 2015, at 2:05 PM, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:
Hi:exactly, if the bit pattern is unequal in two implementations, surely you will be having 2 different results



El Domingo 13 de diciembre de 2015 21:51, "Hosking, Antony L" <hosking at purdue.edu> escribió:


>From the language definition:

An unchecked type transfer operation has the form:


    LOOPHOLE(e, T)
where e is an expression whose type is not an open array type and T is a type. It denotes e's bit pattern interpreted as a variable or value of type T. It is a designator if e is, and is writable if e is. An unchecked runtime error can occur if e's bit pattern is not a legal T, or if e is a designator and some legal bit pattern for T is not legal for e.


If T is not an open array type, BITSIZE(e) must equal BITSIZE(T). If T is an open array type, its element type must not be an open array type, and e's bit pattern is interpreted as an array whose length is BITSIZE(e) divided by BITSIZE(the element type of T). The division must come out even.





On 14 Dec 2015, at 1:40 PM, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> 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> 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> 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
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


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20151214/333e60d9/attachment-0002.html>