<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'> > Some of them assume address is same size as native integer. <BR> <BR> This is correct and by-design. <BR> BYTESIZE(INTEGER) = BYTESIZE(REFANY) etc. (all pointers are the same size) <BR> <BR> In C and C++, for the vast majority of systems <BR> sizeof(size_t) = sizeof(char*) etc. (again, all pointers are the same size) <BR> <BR> VMS64 might be an exception. Might. <BR> <BR> However modern C and C++ offer intptr_t/uintptr_t for this: <BR> sizeof(intptr_t) == sizeof(char*) etc. (again, all pointers are the same size) <BR> <BR> <BR> It is popular to think sizeof(long) == sizeof(char*) but that is frequently incorrect, maybe half the time. <BR> (i.e. on Win64 and maybe VMS64) <BR> <BR> <BR> I'd still like to check/test what happens in the C and NT386 backends here, for loophole changing sizes, but not right now, sorry.<BR> <BR> <BR>The asserts about widen/chop not occurring are from me.<BR>You know, I fairly recently went through much/most/all of what you are doing (I hope all, but I fear much/most) -- implementing a new backend from scratch, and having to figure out precise meanings of things<BR> <BR>> > I would prefer one change at a time, each tested by reboostrapping twice.<BR> <BR> <BR>upgrade.py does the "twice" part builtin.<BR> <BR> <BR> - Jay<br><br> <BR><div>> Date: Sat, 2 Jan 2016 15:03:27 -0600<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?)<br>> <br>> The further I get into this, the more worms crawl out. The only cm3 IR<br>> operators that change an operand size (without storing/refetching in memory)<br>> are widen and chop. The inserts and extracts work entirely within the same-<br>> sized word. But widen and chop are never produced by the front end, and<br>> the integrated and C back ends assert they don't happen. m3cc has code<br>> for them, but this will be entirely untested, and vetting it involves<br>> tracing through lots of gcc code.<br>> <br>> So I plan to redefine the misdocumented loophole operator to allow size<br>> changes among Int32/Word32/Int64/Word64, with shortening changes doing a<br>> chop and widening doing either zero-extend or sign-extend, consistent with<br>> the signedness of the result type. I think this will cover all the cases<br>> required by current places where loophole is emitted, which further implies<br>> the backends are all doing at least these, assuming there are sufficient<br>> test cases. This amounts only to correcting the documentation in M3CG_Ops.i3<br>> <br>> m3llvm will then need to add these behaviors, and things should at least work<br>> as well as always.<br>> <br>> The many loophole-emitting places still need thorough review and documentation<br>> of their requirements. Some of them assume address is same size as native<br>> integer.<br>> <br>> Implementing chop and widen, using them for size changes, and changing loophole<br>> back to the same as LOOPHOLE is the right way, but involves a lot of work and<br>> testing, for small code changes.<br>> <br>> On 12/16/2015 12:01 PM, Rodney M. Bates wrote:<br>> > The issue I raised is not with the M3 LOOPHOLE builtin function. The compiler<br>> > currently implements it correctly, according to the language definition, as<br>> > Tony quoted. The front end verifies the size equality, as required by the<br>> > language, then emits an intermediate "loophole" operator, which will be same<br>> > size, and thus well-defined as equivalent to LOOPHOLE. (And also llvm bitcast,<br>> > which is now being used to translate the loophole operator in this case.)<br>> ><br>> > My issue is that there are 13 other places the front-end emits an internally<br>> > generated "loophole", and these (almost?) all can do so with unequal sizes.<br>> > Moreover, what should be done with the unequal sizes varies from place to place.<br>> ><br>> > It is possible that the "loophole" operator can be defined to do what is<br>> > correct in every case by a conditional rule based on the two types. I<br>> > need to do another pass through them to be sure. This may be the quickest<br>> > way to get the llvm backend working, but I think it is not good design.<br>> > It would be carefully tailored to just a specific set of uses of "loophole",<br>> > instead of making a reasonable abstraction out of" loophole". It would be<br>> > rather fragile and involve a lot of analysis on the full Cartesian product<br>> > of both supplier and client side cases of "loophole" to define and verify.<br>> ><br>> > The best way, IMO, is to fix each "loophole"-generating site to use other<br>> > operators, as appropriate. It is at these sites that it is known what<br>> > should be done in each case. I suspect existing intermediate operators<br>> > "widen", "insert_mn" and "extract_mn" are sufficient. Again, another pass<br>> > through the cases is indicated. The only pragmatic drawback to this is<br>> > that this requires considerable care and retesting to avoid breakage of<br>> > existing behavior. At worst, it risks inability to bootstrap the compiler.<br>> > I would prefer one change at a time, each tested by reboostrapping twice.<br></div> </div></body>
</html>