<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
> 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: hosking@cs.purdue.edu<BR>> Date: Tue, 31 Aug 2010 20:58:07 -0400<BR>> To: jay.krell@cornell.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] a trouble with passing records by value..<BR>> <BR>> <BR>> <BR>> On 31 Aug 2010, at 19:09, Jay K wrote:<BR>> <BR>> > <BR>> > I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers.<BR>> > Yucky.<BR>> <BR>> I strongly advise against that hack.<BR>> <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>> <BR>> This would be better...<BR>> <BR>> > <BR>> > - Jay<BR>> > <BR>> > ----------------------------------------<BR>> >> From: jay.krell@cornell.edu<BR>> >> To: hosking@cs.purdue.edu<BR>> >> CC: m3devel@elegosoft.com<BR>> >> Subject: RE: [M3devel] a trouble with passing records by value..<BR>> >> Date: Tue, 31 Aug 2010 23:05:08 +0000<BR>> >> <BR>> >> <BR>> >> t1 must still be passed in registers. The ABI can't be changed by that.<BR>> >> <BR>> >> - Jay<BR>> >> <BR>> >> ----------------------------------------<BR>> >>> From: hosking@cs.purdue.edu<BR>> >>> Date: Tue, 31 Aug 2010 09:15:32 -0400<BR>> >>> To: jay.krell@cornell.edu<BR>> >>> CC: m3devel@elegosoft.com<BR>> >>> Subject: Re: [M3devel] a trouble with passing records by value..<BR>> >>> <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>> >>> <BR>> >>> On 31 Aug 2010, at 07:25, Jay K wrote:<BR>> >>> <BR>> >>>> <BR>> >>>> Given something like this:<BR>> >>>> <BR>> >>>> jbook2:p247 jay$ more 1.c<BR>> >>>> #include<BR>> >>>> <BR>> >>>> typedef struct { long code; long value; } T1;<BR>> >>>> <BR>> >>>> void ActionLookup(T1 t, long code, long value);<BR>> >>>> <BR>> >>>> void ActionLookup(T1 t, long code, long value)<BR>> >>>> {<BR>> >>>> assert(t.code == code);<BR>> >>>> assert(t.value == value);<BR>> >>>> }<BR>> >>>> <BR>> >>>> int main()<BR>> >>>> {<BR>> >>>> T1 t1 = {2,2};<BR>> >>>> ActionLookup(t1, 2, 2);<BR>> >>>> return 0;<BR>> >>>> }<BR>> >>>> j<BR>> >>>> <BR>> >>>> <BR>> >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good.<BR>> >>>> <BR>> >>>> <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>> >>>> <BR>> >>>> <BR>> >>>> If m3cg were higher level this could be better.<BR>> >>>> <BR>> >>>> <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>> >>>> <BR>> >>>> <BR>> >>>> Maybe we should have M3CG include field references?<BR>> >>>> <BR>> >>>> <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>> >>>> <BR>> >>>> <BR>> >>>> - Jay<BR> </body>
</html>