<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
Well, I'd like to be able to dereference pointers in stock gdb and also see floats properly.<BR>
But yes, I put in use of bitfields for things with offset or size not a multiple of 8 (or "unit", whatever).<BR>
I put in asserts that record sizes match between frontend and backend.<BR>
It seems to work, at least on AMD64_DARWIN.<BR>
That still leaves room for fields to be placed wrong though. It's a start.<BR>
I should be able to go back and assert those too.<BR>
<BR>
<BR>
There's still a fair amount more to do here, including objects, enums, globals, constants, packed.<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>
> From: hosking@cs.purdue.edu<BR>> Date: Wed, 1 Sep 2010 15:23:17 -0400<BR>> To: jay.krell@cornell.edu<BR>> CC: hendrik@topoi.pooq.com; m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] a trouble with passing records by value..<BR>> <BR>> 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?<BR>> <BR>> <BR>> On 1 Sep 2010, at 12:10, Jay K wrote:<BR>> <BR>> > <BR>> > "..." won't let me see things gdb.<BR>> > Clever hack though.<BR>> > <BR>> > <BR>> > The backend below parse.c implements the ABI, and generation of debugging information,<BR>> > as long as you give it correctly typed trees. So yes, we would generally be compatible<BR>> > with the C compiler. Except, well, except that m3front does the same work. Not good.<BR>> > <BR>> > <BR>> > - Jay<BR>> > <BR>> > ----------------------------------------<BR>> >> Date: Wed, 1 Sep 2010 11:47:14 -0400<BR>> >> From: hendrik@topoi.pooq.com<BR>> >> To: m3devel@elegosoft.com<BR>> >> Subject: Re: [M3devel] a trouble with passing records by value..<BR>> >> <BR>> >> On Tue, Aug 31, 2010 at 09:24:07PM -0500, Rodney M. Bates wrote:<BR>> >>> If the writers of an ABI actually *required* that small structs/records be<BR>> >>> passed in registers, then they have made a big blunder. In C, formal<BR>> >>> parameters are l-values,<BR>> >> <BR>> >> but they are copies of the corresponding actual parameters.<BR>> >> <BR>> >>> and in Modula-3, they are designators, regardless<BR>> >>> of the parameter mode. Thus taking their address must always be possible,<BR>> >>> to comply with language semantics, which means they must be in memory.<BR>> >>> <BR>> >>> The only possible resolutions are<BR>> >>> <BR>> >>> 1) Declare that language semantics trump ABI requirements and defy the ABI.<BR>> >> <BR>> >> On most platforms I ever had to be binary-compatible with in a C<BR>> >> interpreter I dealt with long long ago, declaring the formal parameters<BR>> >> as "..." (like printf) kept them in storage on the stack.<BR>> >> <BR>> >> -- hendrik<BR>> >> <BR>> >>> <BR>> >>> 2) Pass them in registers at the time of control transfer, but store them<BR>> >>> in memory in the prologue, then access them from memory thereafter.<BR>> >> <BR>> >> That's what the more optimizing compilers did, except they only ccopied<BR>> >> them to memory if the called code actually needed them to be in memory.<BR>> >> And they also watched out for functions whose addresses were taken, or<BR>> >> were accessible by external linkage.<BR>> >> <BR>> >> But it mattered whether the function had a prototoype, and whether<BR>> >> parameters were declared as "...".<BR>> >> <BR>> >> -- hendrik<BR>> > <BR>> <BR> </body>
</html>