[M3devel] passing structs by value

[Rodney M. Bates]

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
>