<html><head><base href="x-msg://1237/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I believe there is one way out here.<div>Modula-3's dynamic types (UID-based) give a story for debugging in which we interpret the layout dynamically based on the Modula-3 type.</div><div>We can even rely on Modula-3 run-time support to interpret the UIDs.</div><div><br></div><div>I don't particularly understand the SPARC64_SOLARIS issue. Can you elaborate?</div><div><br>
<br><div><div>On 31 Aug 2010, at 22:00, Jay K wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="hmmessage" style="font-size: 10pt; font-family: Tahoma; ">> I strongly advise against that hack.<br><br> <br>It's not my favorite, but I'm possibly in<br>a jam here between providing type information<br>for debugging with stock gdb, and I suspect an<br>overall poor story regarding type information<br>and backend/frontend interface.<br> <br> <br>One option is to give up on type information.<br>i.e. go back to the historical way i.e. before August 2010.<br>That worked ok as far as most people observed (except for stock gdb..)<br>However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS.<br> <br><br>I suspect we never historically passed records in registers, and that we must continue not to.<br> Because of how fields are referenced. Unless maybe gcc "homes" the records as needed, if<br> it notices their address taken.<br><br> <br>It might suffice, besides giving up on type information, to<br>mark all records as "addressable". Or, again, to slightly<br>hack the backend. Maybe only for SPARC64.<br> <br> <br>The bigger controversial question is if we should change<br>m3cg (the interface) to know about "field references".<br> <br><br>And then, again, should layout be done by the frontend, backend,<br>or both? There are arguments for all three options.<br>I think the current *design* is frontend only.<br>But I think the current *implementation* is both (except for NT386).<br>And probably the right way is backend only.<br> <br><br>This would also generally fix the pesky "load/store use bitfields" thing.<br> <br> <br>Debuggability with stock gdb does seem like a nice idea.<br>But I see now it might conflict tremendously with our odd structuring.<br> <br> <br>I'll keep poking at it. e.g.: good type information, including for temporaries,<br>and mark all record types/values as addressable.<br> <br> <br>We should still consider the notion of "field references" in the m3cg interface.<br> Right? I'm not crazy in the "mismatch" I seem to "detect"?<br>Probably besides given the field "name", we should pass what the frontend<br>thinks is the offset, type, alignment. This will serve two purposes.<br>For NT386, it will let it continue to be fairly typeless, at least for now.<br>For m3cc, it can maybe assert that the layouts agree -- at least for the fields that are accessed.<br> <br> <br>I still have to understand how bitfields fit here also.<br>Though I checked -- it is quite nice afterall that offsets and sizes are given in bits instead of bytes!<br> <br><br> - Jay<br><br><br> <br>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> Date: Tue, 31 Aug 2010 20:58:07 -0400<br>> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> Subject: Re: [M3devel] a trouble with passing records by value..<br>><span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> On 31 Aug 2010, at 19:09, Jay K wrote:<br>><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers.<br>> > Yucky.<br>><span class="Apple-converted-space"> </span><br>> I strongly advise against that hack.<br>><span class="Apple-converted-space"> </span><br>> > I'm also going to try giving temporaries types.<br>> > Another m3cg change like pop_struct.<br>> > Given the latest internal error I saw.<br>> > Maybe review m3cg for more missing type information.<br>><span class="Apple-converted-space"> </span><br>> This would be better...<br>><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > - Jay<br>> ><span class="Apple-converted-space"> </span><br>> > ----------------------------------------<br>> >> From:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >> To:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> >> Subject: RE: [M3devel] a trouble with passing records by value..<br>> >> Date: Tue, 31 Aug 2010 23:05:08 +0000<br>> >><span class="Apple-converted-space"> </span><br>> >><span class="Apple-converted-space"> </span><br>> >> t1 must still be passed in registers. The ABI can't be changed by that.<br>> >><span class="Apple-converted-space"> </span><br>> >> - Jay<br>> >><span class="Apple-converted-space"> </span><br>> >> ----------------------------------------<br>> >>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >>> Date: Tue, 31 Aug 2010 09:15:32 -0400<br>> >>> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> >>> Subject: Re: [M3devel] a trouble with passing records by value..<br>> >>><span class="Apple-converted-space"> </span><br>> >>> What happens if you take the address of t inside ActionLookup?<br>> >>> What happens if you take the address of t1 inside main?<br>> >>><span class="Apple-converted-space"> </span><br>> >>> On 31 Aug 2010, at 07:25, Jay K wrote:<br>> >>><span class="Apple-converted-space"> </span><br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> Given something like this:<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> jbook2:p247 jay$ more 1.c<br>> >>>> #include<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> typedef struct { long code; long value; } T1;<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> void ActionLookup(T1 t, long code, long value);<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> void ActionLookup(T1 t, long code, long value)<br>> >>>> {<br>> >>>> assert(t.code == code);<br>> >>>> assert(t.value == value);<br>> >>>> }<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> int main()<br>> >>>> {<br>> >>>> T1 t1 = {2,2};<br>> >>>> ActionLookup(t1, 2, 2);<br>> >>>> return 0;<br>> >>>> }<br>> >>>> j<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good.<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value,<br>> >>>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is,<br>> >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers.<br>> >>>> Darn.<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> If m3cg were higher level this could be better.<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> There should be a viable compromise where the parameter is passed in registers, and only "homed"<br>> >>>> to some stack location if its address is used -- e.g. to pass unused parameters in registers.<br>> >>>> But given the inefficiency of field accesses, I'm not sure it is worth trying?<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> Maybe we should have M3CG include field references?<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> There is this basic problem that the interface between m3front and m3cc isn't really at the<br>> >>>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator.<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> - Jay<br></div></span></blockquote></div><br></div></body></html>