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

[Jay K]

Well, I'd like to be able to dereference pointers in stock gdb and also see floats properly.
But yes, I put in use of bitfields for things with offset or size not a multiple of 8 (or "unit", whatever).
I put in asserts that record sizes match between frontend and backend.
It seems to work, at least on AMD64_DARWIN.
That still leaves room for fields to be placed wrong though. It's a start.
I should be able to go back and assert those too.
 
 
There's still a fair amount more to do here, including objects, enums, globals, constants, packed.
 
 
 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Wed, 1 Sep 2010 15:23:17 -0400
> To: jay.krell at cornell.edu
> CC: hendrik at topoi.pooq.com; m3devel at elegosoft.com
> Subject: Re: [M3devel] a trouble with passing records by value..
> 
> 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
> > 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100902/b83090a7/attachment-0002.html>