[M3devel] passing structs by value

[Jay K]

 > bad code, crash.

Clarification, not a crash but an "orderly" error.
This is somewhat by chance though.
You could imagine perhaps a record that just contains a pointer, and a crash.

 - Jay
----------------------------------------
> From: jay.krell at cornell.edu
> To: rodney_bates at lcwb.coop; m3devel at elegosoft.com
> Date: Fri, 27 Aug 2010 16:36:19 +0000
> Subject: Re: [M3devel] passing structs by value
>
>
> Rodney, don't worry too much, I believe I understand the language semantics and won't deliberately change them.
>
> > Of course, at the machine levelI'm talking about the machine level.
>
> Passing a record by value can be in registers or a pointer to a copy.
> The gcc backend wasn't passing enough type information around, such that
> where the C ABI specified in registers, it'd a be a pointer to a copy.
>    Imho, it's kind of bad of the gcc code to even have accepted the trees we give it.
> I don't much mind the inefficiency, but I do mind missing type information in the debugger.
>
> And what really got me started here is an assertion failure in the SPARC64_SOLARIS backend.
> It goes to decide how to pass a record by value, which includes looking at what fields the record
> has, and it had none. Which it is sometimes ok with, but not in this case.
>
> If you just change parse.c to pass around the type information it has, well, the easy
> code only has information at the reciever, not the caller, leading to inconsistency, bad code, crash.
> The badness only occurs in a little bit of code in the system, and then, only on some platforms.
> I was lucky to be using such a platform!
>
> I have fixed it now so that the passer and recieve both have the information.
>
> The result should be, on some platforms, depending on the ABI, depending on the exact RECORD,
> some records will be passed in registers.
> Minor side benefit is correct interop with C, though I'd suggest just staying away from
> passing records by value with C.
>
> Unfortunately SPARC64_SOLARIS still hits the same assertion failure in gcc. :(
> I'm double checking to make sure I used current source. Accidentally doing
> a clean build of m3cc, so it'll be a while.
>
>
>  - Jay
>
>
> ----------------------------------------
> > Date: Fri, 27 Aug 2010 10:30:15 -0500
> > From: rodney_bates at lcwb.coop
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] passing structs by value
> >
> > Jay, I am not sure what you are saying here, but it sounds like you might be considering the
> > passing mode of records to be an implementor choice. Have I read this right?
> >
> > It isn't a choice for Modula-3. The language specifies the mode. Value for VALUE in the
> > signature, reference for VAR, and for READONLY, it depends on the form of the actual.
> >
> > For function returns, the semantics are always by value.
> >
> > Of course, at the machine level, you can always pass a pointer between caller and callee,
> > as long as the necessary copying is done somewhere This is the only reasonable way to
> > implement READONLY, since whether a copy is to be made will differ at different call
> > sites.
> >
> > Jay K wrote:
> > > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI.
> > >
> > > I really can't follow the complicated rules here:
> > >
> > > http://www.x86-64.org/documentation/abi-0.99.pdf
> > >
> > >
> > >
> > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields.
> > >
> > >
> > >
> > > As much as we don't pass/return records by value between Modula-3 and C, that is ok.
> > > As long as Modula-3 callers/recievers agree. And they do, but...
> > >
> > >
> > > The gcc backend is given good type information at first, but historically throws much of it away.
> > > As you start to repair that, it starts following the ABI. At least at the callee side.
> > > I think the caller is still devoid of type information.
> > > I'm assuming there is a fallback rule for the case of missing type information.
> > >
> > > So if you give just one side the type information, you get a mismatch, bad code.
> > >
> > >
> > > Passing records in registers is nice, but..
> > > (reminder: I think historically we never did).
> > >
> > >
> > > I thin we should probably just change the frontend to handle passing records by value itself.
> > > Like it does for I386_NT/NT386.
> > >
> > >
> > > For any record parameter, introduce a temporary in the caller and pass its address.
> > > Or whatever the code is already prepared to do.
> > >
> > >
> > > We should probably handle records returned by value similarly.
> > >
> > >
> > > This decision can be revisited if/when there is a C backend.
> > > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it.
> > > I doubt anyone else is either.
> > > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work.
> > > Further long term deficiencies this uncovers, I'm very inclined to dig further into.
> > >
> > >
> > > The right fix is probably to maintain types in the expression stack.
> > > Or at least throw in more casts on the pops.
> > >
> > >
> > > I don't think pop_param presently recieves enough type information -- no type id.
> > >
> > >
> > > - Jay
> > >
>