[M3devel] passing structs by value

[Jay K]

Hm. I think the right fix here is to pass a typeid to pop_struct.

 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: passing structs by value
> Date: Fri, 27 Aug 2010 09:12:00 +0000
>
>
> 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
> > >
> >
>