[M3devel] passing structs by value

[Jay K]

Easier said than done.
Setting standard_structs = TRUE I thought would free the backend from worrying
about passing or returning structs at all, but that's far from true.
I thought the frontend would introduce temporaries and pass their addresses. But no.

See for example what M3x86 does in pop_struct.
Frustrating.

 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: passing structs by value
> Date: Thu, 26 Aug 2010 11:36:51 +0000
>
>
> aka: I propose Target.i3 standard_structs always be true, and therefore remove it and propagate true through m3front.
> Or at least make it always true and leave the code in m3front for future generations to revisit..
>
> I will go ahead and test this.
>
>   - Jay
>
> ----------------------------------------
> > From: jay.krell at cornell.edu
> > To: m3devel at elegosoft.com
> > Subject: passing structs by value
> > Date: Thu, 26 Aug 2010 11:34:54 +0000
> >
> >
> > 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
> >
>