[M3devel] a trouble with passing records by value..

[Tony Hosking]

Surely there are ways to type things such that the backend is forced to compute the same layout as the front-end.  Can we type fields as bitfields to get what's needed?


On 1 Sep 2010, at 12:10, Jay K wrote:

> 
> "..." won't let me see things gdb.
> Clever hack though.
> 
> 
> The backend below parse.c implements the ABI, and generation of debugging information,
> as long as you give it correctly typed trees. So yes, we would generally be compatible
> with the C compiler. Except, well, except that m3front does the same work. Not good.
> 
> 
>  - Jay
> 
> ----------------------------------------
>> Date: Wed, 1 Sep 2010 11:47:14 -0400
>> From: hendrik at topoi.pooq.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] a trouble with passing records by value..
>> 
>> On Tue, Aug 31, 2010 at 09:24:07PM -0500, Rodney M. Bates wrote:
>>> If the writers of an ABI actually *required* that small structs/records be
>>> passed in registers, then they have made a big blunder. In C, formal
>>> parameters are l-values,
>> 
>> but they are copies of the corresponding actual parameters.
>> 
>>> and in Modula-3, they are designators, regardless
>>> of the parameter mode. Thus taking their address must always be possible,
>>> to comply with language semantics, which means they must be in memory.
>>> 
>>> The only possible resolutions are
>>> 
>>> 1) Declare that language semantics trump ABI requirements and defy the ABI.
>> 
>> On most platforms I ever had to be binary-compatible with in a C
>> interpreter I dealt with long long ago, declaring the formal parameters
>> as "..." (like printf) kept them in storage on the stack.
>> 
>> -- hendrik
>> 
>>> 
>>> 2) Pass them in registers at the time of control transfer, but store them
>>> in memory in the prologue, then access them from memory thereafter.
>> 
>> That's what the more optimizing compilers did, except they only ccopied
>> them to memory if the called code actually needed them to be in memory.
>> And they also watched out for functions whose addresses were taken, or
>> were accessible by external linkage.
>> 
>> But it mattered whether the function had a prototoype, and whether
>> parameters were declared as "...".
>> 
>> -- hendrik
>