<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'>Right -- I would have just said, add a name or such parameter to load/store, but I'm aware of LLVM GetElementPointer so came up with a name like it.<div>But, I'm not sure we want a separate call -- GetElementPointer, followed by a load/store of whatever is stacked -- or build it into the load/store.</div><div><br></div><div>I've always found the presence of the offset parameter in load/store "surprising".</div><div>I'd'a'naively'thunk that'd a be a separate add operation.</div><div>But I also suspect the original authors knew what they were doing and had possibly</div><div>done it several times already, and this parameter's presence was an easy lesson they learned</div><div>from experience.</div><div><br></div><div><div><br></div><div>Heck, perhaps they had my current desires in mind?</div></div><div><br></div><div><br></div><div>Then again, I was also /initially/ surprised by both the low level nature of the IR, all the layout done already, and that I was able to get it to work generating C. But ultimately it makes a lot of sense in the current form. If you look at the "level" and sophistication of M3x86 -- it doesn't do layout. Even M3C doesn't really do layout -- it echoes/renders the information in another form, leaving the C compiler to do the layout. </div><div><br></div><div><br></div><div>> something that suits LLVM and C</div><div><br></div><div><br></div><div>And presumably for the time being, gcc and M3x86? :)</div><div><br></div><div><br></div><div>My actual extremely long term goal that I might never get to is that once we have something very portable -- C. And I guess something everyone likes -- LLVM.</div><div>Perhaps try to write more of our backends. Like starting with M3x86.m3.</div><div>I know I'll never achieve the reach of C/gcc/LLVM though. Merely targeting AMD64 across NT/Linux/Mac will be difficult -- three file formats and at least two ABIs.</div><div><br></div><div><br></div><div> - Jay<br><br><br><div><hr id="stopSpelling">Subject: Re: [M3devel] alloca(jmpbuf) vs. alloca(jmpbuf + frame)?<br>From: hosking@purdue.edu<br>Date: Mon, 10 Aug 2015 14:31:50 +1000<br>CC: m3devel@elegosoft.com<br>To: jay.krell@cornell.edu<br><br>Ideally, we would also converge on something that suits both LLVM and C.<div>Your notion of get_member_reference is similar to LLVM getelementptr, which allows the backend to do layout for structs.</div><div>It would be very nice if the front-end used this level of abstraction.</div><div>I assume that is what you are talking about.</div><div><br></div><div><div><div><blockquote><div>On Aug 10, 2015, at 2:19 PM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:</div><br class="ecxApple-interchange-newline"><div><div dir="ltr" style="font-family:Calibri;font-size:16px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><div>The more I think about this, the more I want to do it the other way,</div><div>at least for the C backend, but only after another round of change.</div><div><br></div><div><br></div><div>For now, I prefer how it is.</div><div><br></div><div><br></div><div>The other change I want is "get_member_reference", or for load/store to indicate</div><div>field names or constant array indices, along with the "resolved" offset.</div><div><br></div><div><br></div><div>That is, I want the backend to be able to do layout, and I want the generated</div><div>C to be independent of word size. Including expressions involving</div><div>BITSIZE(INTEGER) to be rendered as</div><div> #include <stddef.h> // or stdint.h (or autoconf) </div><div> typedef ptrdiff_t INTEGER; // or intptr_t (or autoconf) </div><div> #define BITSIZE(x) sizeof(x) * CHAR_BIT</div><div><br></div><div> BITSIZE(INTEGER) </div><div><br></div><div><br></div><div>instead of the current 32 or 64.</div><div><br></div><div><br></div><div> Currently I have two pointers per jmpbuf.</div><div> One in the frame, one in another local variable.</div><div> Perhaps this can be converged to have just the one in the frame.</div><div> Independently of any other change.</div><div><br></div><div><br></div><div>Once we have get_member_reference, then for C this</div><div>would just be a nothing-special struct/record with a jmpbuf value at the end,</div><div>referenced by name.</div><div><br></div><div><br></div><div>For the other backends, perhaps we could make it a record,</div><div>of unspecified size, have the runtime compute the size by adding</div><div>the size of the prefix to the size of a jmpbuf and doing alloca.</div><div><br></div><div><br></div><div>I'd like C and non-C to be ABI compatible though.</div><div>They have other differences already, in particular around the frame pointer</div><div>for nested functions. This bothers me.</div><div><br></div><div><br></div><div> - Jay</div><br><br><br><div><hr id="ecxstopSpelling">From:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:hosking@purdue.edu">hosking@purdue.edu</a><br>Date: Sun, 9 Aug 2015 16:18:59 +0000<br>CC:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] alloca(jmpbuf) vs. alloca(jmpbuf + frame)?<br><br><div dir="ltr"><a href="https://github.com/modula3/cm3/commit/5b04afe9134e5807196ba6af13fa4cd28401f054" target="_blank">https://github.com/modula3/cm3/commit/5b04afe9134e5807196ba6af13fa4cd28401f054</a><div><br></div><div>jmpbuf in frame changed from value to pointer.</div><div><br></div><div> - Jay<br><br><br><br><div><hr id="ecxstopSpelling">Subject: Re: [M3devel] alloca(jmpbuf) vs. alloca(jmpbuf + frame)?<br>From: <a href="mailto:hosking@purdue.edu">hosking@purdue.edu</a><br>Date: Sun, 9 Aug 2015 20:09:36 +1000<br>CC: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>To: <a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br><br><div>What is the m3core change you refer to?<br><br>Sent from my iPad</div><div><br>On 9 Aug 2015, at 11:33 am, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br><br></div><blockquote><div><div dir="ltr"><span style="font-size:12pt;">I considered that I could lump the jmpbuf alloca in with its enclosing frame -- one slightly larger alloca,</span><div>and the same amount of overall stack, minus the pointer or two per jmpbuf in the current scheme.</div><div><br><div><br></div><div>That would preclude the need for m3core change, which I'm sure will cause trouble,</div><div>but is meant to be an ok thing to do.</div><div><br></div><div><br></div><div>However, that isn't perhaps as amenable to my next desired step in the C backend wrt jmp_buf.</div><div>Though, I guess, I could have it both ways -- the compiler and runtime could share a flag</div><div>and the frame be altered.</div><div><br></div><div><br></div><div>Thoughts?</div><div><br></div><div> - Jay</div></div></div></div></blockquote><blockquote><div><span>_______________________________________________</span><br><span>M3devel mailing list</span><br><span><a href="mailto:M3devel@elegosoft.com">M3devel@elegosoft.com</a></span><br><span><a href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel" target="_blank">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a></span><br></div></blockquote></div></div></div><br>_______________________________________________ M3devel mailing list<span class="ecxApple-converted-space"> </span><a href="mailto:M3devel@elegosoft.com">M3devel@elegosoft.com</a><a href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel" target="_blank">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a></div></div></div></blockquote></div><br></div></div></div></div> </div></body>
</html>