<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'><div style="text-align: left;">I don't want to deal with learning about CVS branches, please.<br><br>I can try the __cdecl thunk hack I had nearly working, over in m3-win\import-libs.<br>It's lame compared to my parse.c though.<br><br>Given void __stdcall Foo(int a, struct {int a, b}), or rather Foo 12,<br><br>it would generate<br><br>one source file/.obj<br> void __stdcall F(int a, int b, int c); <br>
void __stdcall Fstdcall(int a, int b, int c) { return Fstdcall(a b c); } <br><br>another source file/.obj<br> void __stdcall Fstdcall(int a, int b, int c); <br>
void __cdecl F(int a, int b, int c) { return Fstdcall(a b c); } <br>
<br>If I could put parse.c back, I could limit this to functions that take structs.<br>Or at least one function in particular that I know is a current problem.<br>Limiting this hack would be good.<br><br> - Jay<br></div><br><br><hr id="stopSpelling">> CC: m3devel@elegosoft.com<br>> From: hosking@cs.purdue.edu<br>> Subject: Re: next problem (NT386GNU)<br>> Date: Mon, 21 Jan 2008 17:32:32 -0500<br>> To: jayk123@hotmail.com<br>> <br>> I'd prefer to have the backend do it properly based on properly <br>> declared types. I'd prefer to keep this code out of the current <br>> mainline of parse.c -- you could fork a temporary branch if necessary.<br>> <br>> On Jan 21, 2008, at 5:16 PM, Jay wrote:<br>> <br>> > Understood. Put back my parse.c in the meantime?<br>> ><br>> > Also, the front end could do this, right? And probably without a <br>> > stack?<br>> > It could compute "effective parameter size" and pass that down.<br>> > Backend could then divide by 4 and claim that is the signature,<br>> > that number of parameters.<br>> ><br>> > Would have to see how passing a struct works out anyway -- one <br>> > parameter<br>> > or one per field.<br>> ><br>> > - Jay<br>> ><br>> ><br>> > > CC: m3devel@elegosoft.com<br>> > > From: hosking@cs.purdue.edu<br>> > > Subject: Re: next problem (NT386GNU)<br>> > > Date: Mon, 21 Jan 2008 12:01:28 -0500<br>> > > To: jayk123@hotmail.com<br>> > ><br>> > > I just need to fix m3cc/cm3cg to emit the stdcall parameter<br>> > > information for imported procedures. It is simply a matter of not<br>> > > ignoring declare_param for import_procedure chunks. This means<br>> > > maintaining a current_function_decl (and possibly a<br>> > > current_param_count) stack (since import_procedure can occur <br>> > inside a<br>> > > declare_procedure chunk). I know what needs doing, but have not much<br>> > > free time right now...<br>> > ><br>> > > On Jan 21, 2008, at 11:10 AM, Jay wrote:<br>> > ><br>> > > > agreed once I thought about it<br>> > > > I guess that explains left to right as well.<br>> > > > Parameters are always left to right from a higher level point of<br>> > > > view, and if that is wrong, the compiler will reorder.<br>> > > ><br>> > > > "everything" works now<br>> > > ><br>> > > > - Jay<br>> > > ><br>> > > ><br>> > > ><br>> > > > > CC: m3devel@elegosoft.com<br>> > > > > From: hosking@cs.purdue.edu<br>> > > > > Subject: Re: next problem (NT386GNU)<br>> > > > > Date: Mon, 21 Jan 2008 10:54:10 -0500<br>> > > > > To: jayk123@hotmail.com<br>> > > > ><br>> > > > > Surely, when using the gcc-based backend then we should make the<br>> > > > > backend handle it. The front end handling it is only need for <br>> > the<br>> > > > > integrated x86 backend.<br>> > > > ><br>> > > > > On Jan 21, 2008, at 2:43 AM, Jay wrote:<br>> > > > ><br>> > > > > > I haven't tested a fix but I see the problem.<br>> > > > > ><br>> > > > > > This function returns a struct.<br>> > > > > > There are two struct returning calling conventions.<br>> > > > > > In one, the backend handles it. Which includes the backend <br>> > knowing<br>> > > > > > there is a return value and its type (or at least its size?).<br>> > > > > > In the other, the front end handles it. In this case, the <br>> > front<br>> > > > end<br>> > > > > > generates passing an extra pointer parameter to the <br>> > function, and<br>> > > > > > the function's return type is void.<br>> > > > > ><br>> > > > > > The NT calling conventions, all of them, are marked as <br>> > front end<br>> > > > > > handling it. I assume that is correct, could check.<br>> > > > > > Everything else is marked as back end handling.<br>> > > > > ><br>> > > > > > Now then, somewhere along the line, gcc figures out that the<br>> > > > return<br>> > > > > > value isn't used here.<br>> > > > > > The point of the function call is to see if it generates an<br>> > > > exception.<br>> > > > > ><br>> > > > > > Gcc removes the function because its return value isn't <br>> > used, and,<br>> > > > > > well, somehow it doesn't know about the exceptions here. <br>> > I'll have<br>> > > > > > to see how "raise" is implemented. I think it's by a call to a<br>> > > > > > function that gets the jmpbuf from a thread local and calls<br>> > > > > > longjmp. (Did I mention it is very inefficient?)<br>> > > > > ><br>> > > > > > There are few possible fixes, but nothing completely <br>> > satisfactory<br>> > > > > > yet in mind.<br>> > > > > ><br>> > > > > > One is have parse.c mark all function calls as having side<br>> > > > affects.<br>> > > > > > This is easy, but overly pessimistic.<br>> > > > > > Another is for the front end to mark struct returning <br>> > functions as<br>> > > > > > having side affects. Better, but still overly pessimistic.<br>> > > > > > Another is for the front end to mark any function that can<br>> > > > raise as<br>> > > > > > having side affects. Getting better still. I don't know how <br>> > to do<br>> > > > > > that but I'll look. This is still a bit overly pessimistic, <br>> > since<br>> > > > > > what you really want to know is, not the function's side <br>> > affects,<br>> > > > > > but whether or not it raised. If the function is inlined, <br>> > the side<br>> > > > > > affects could be optimized away, or if there are enough <br>> > callers<br>> > > > who<br>> > > > > > don't care about the side affects to warrant an <br>> > optimization, and<br>> > > > > > depending on the cost of computing the side affects, another<br>> > > > > > instance of the function could be made that only raises or <br>> > not,<br>> > > > but<br>> > > > > > no side affects otherwise. This is "advanced" optimization the<br>> > > > sort<br>> > > > > > of which tends never to be implemented.<br>> > > > > ><br>> > > > > > I think the best option is anything that can raise is <br>> > marked as<br>> > > > > > having side affects.<br>> > > > > > I'll see if I can figure that out.<br>> > > > > ><br>> > > > > > You can figure this out by looking at m3cgcat -binary <<br>> > > > M3File.mc ><br>> > > > > > 1.txt on PPC_DARWIN and NT386GNU and comparing.<br>> > > > > ><br>> > > > > > Maybe marking all or nearly functions as having side <br>> > effects isn't<br>> > > > > > so bad.<br>> > > > > > Or at least anything returning a struct. That gets parity with<br>> > > > > > other platforms, even if it is a bit pessimistic.<br>> > > > > > I think I'll do that, and ignore figuring out if raise is <br>> > called<br>> > > > > > and using that as a filter.<br>> > > > > > The parity angle is good.<br>> > > > > ><br>> > > > > > The good news for all you Unix lovers :) is this bug is <br>> > relatively<br>> > > > > > portable to Cygwin.<br>> > > > > > True, it is specific to NT386GNU having multiple "calling<br>> > > > > > conventions", which no other platform has.<br>> > > > > > Which again, jokingly, strikes at the question -- What is <br>> > Posix?<br>> > > > > > What do you want from Cygwin?<br>> > > > > > One thing Cygwin does NOT give you is just one calling <br>> > convention,<br>> > > > > > alas, this calling convention business stinks. It's not <br>> > even an NT<br>> > > > > > thing, only an NT386 thing. All the other NT platforms had/ <br>> > have<br>> > > > > > only one calling convention.<br>> > > > > ><br>> > > > > > You can't get far on NT386 without needing to support two <br>> > calling<br>> > > > > > conventions.<br>> > > > > > The "OS" uses mostly __stdcall -- callee pops -- smaller, <br>> > faster.<br>> > > > > > But anything that is varargs, such as printf -- pretty much <br>> > must<br>> > > > > > use caller pops -- __cdecl.<br>> > > > > > As well, __cdecl is the default, so prevalent, and used in <br>> > most C<br>> > > > > > runtime functions.<br>> > > > > > There is also __fastcall that uses like up to two registers <br>> > for<br>> > > > > > parameters.<br>> > > > > ><br>> > > > > > I have seen a platform in which printf did the pop, and it<br>> > > > depended<br>> > > > > > on the number/size of parameters matching the format <br>> > string. On<br>> > > > > > most platforms, printf("", 1, 2, 3, 4) just does nothing, <br>> > but on<br>> > > > > > that platform, it'd unbalance the stack and crash.<br>> > > > > ><br>> > > > > > - Jay<br>> > > > > ><br>> > > > > > From: jayk123@hotmail.com<br>> > > > > > To: hosking@cs.purdue.edu<br>> > > > > > CC: m3devel@elegosoft.com<br>> > > > > > Subject: next problem (NT386GNU)<br>> > > > > > Date: Mon, 21 Jan 2008 05:47:28 +0000<br>> > > > > ><br>> > > > > > M3File.m3<br>> > > > > ><br>> > > > > > PROCEDURE IsReadable (path: TEXT): BOOLEAN =<br>> > > > > > (* We don't really check for readablitiy, just for <br>> > existence *)<br>> > > > > > BEGIN<br>> > > > > > TRY<br>> > > > > > EVAL FS.Status (path); line 82<br>> > > > > > RETURN TRUE;<br>> > > > > > EXCEPT OSError.E =><br>> > > > > > RETURN FALSE;<br>> > > > > > END;<br>> > > > > > END IsReadable;<br>> > > > > ><br>> > > > > > -----LINE 82 -----<br>> > > > > > start_call_direct p.25 0 Struct<br>> > > > > > load_address v.25 0<br>> > > > > > pop_param Addr<br>> > > > > > load v.26 0 Addr Addr<br>> > > > > > pop_param Addr<br>> > > > > > call_direct p.25 Struct<br>> > > > > > pop Struct<br>> > > > > ><br>> > > > > ><br>> > > > > ><br>> > > > > > I'm guessing you only see an import for the first call on <br>> > purpose,<br>> > > > > > but I will compare with PPC_DARWIN:<br>> > > > > ><br>> > > > > > -----LINE 46 -----<br>> > > > > > import_procedure FS__Status 2 Struct 0 p.25<br>> > > > > > declare_indirect 2078421550 -2078421551<br>> > > > > > declare_param _return 4 4 Addr 2078421550 F F 50 v.62<br>> > > > > > declare_param p 4 4 Addr 1358456180 F F 50 v.63<br>> > > > > > start_call_direct p.25 0 Struct<br>> > > > > > load_address v.13 0<br>> > > > > > pop_param Addr<br>> > > > > > load v.14 0 Addr Addr<br>> > > > > > pop_param Addr<br>> > > > > > call_direct p.25 Struct<br>> > > > > > pop Struct<br>> > > > > ><br>> > > > > ><br>> > > > > > .globl _M3File__IsReadable<br>> > > > > > .def _M3File__IsReadable; .scl 2; .type 32; .endef<br>> > > > > > _M3File__IsReadable:<br>> > > > > > .stabn 68,0,178,LM93-_M3File__IsReadable<br>> > > > > > LM93:<br>> > > > > > pushl %ebp<br>> > > > > > movl %esp, %ebp<br>> > > > > > pushl %edi<br>> > > > > > pushl %esi<br>> > > > > > pushl %ebx<br>> > > > > > subl $300, %esp<br>> > > > > > LBB15:<br>> > > > > > .stabn 68,0,181,LM94-_M3File__IsReadable<br>> > > > > > LM94:<br>> > > > > > L157:<br>> > > > > > movl -280(%ebp), %eax<br>> > > > > > andl $0, %eax<br>> > > > > > orl $_L_1, %eax<br>> > > > > > movl %eax, -280(%ebp)<br>> > > > > > movl -284(%ebp), %eax<br>> > > > > > andl $0, %eax<br>> > > > > > movl %eax, -284(%ebp)<br>> > > > > > subl $12, %esp<br>> > > > > > leal -288(%ebp), %eax<br>> > > > > > pushl %eax<br>> > > > > > call _RTHooks__PushEFrame<br>> > > > > > addl $16, %esp<br>> > > > > > leal -288(%ebp), %eax<br>> > > > > > addl $48, %eax<br>> > > > > > subl $12, %esp<br>> > > > > > pushl %eax<br>> > > > > > call __setjmp<br>> > > > > > addl $16, %esp<br>> > > > > > testb %al, %al<br>> > > > > > jne L158<br>> > > > > > .stabn 68,0,183,LM95-_M3File__IsReadable<br>> > > > > > LM95:<br>> > > > > > movl -288(%ebp), %eax<br>> > > > > > subl $12, %esp<br>> > > > > > pushl %eax<br>> > > > > > call _RTHooks__PopEFrame<br>> > > > > > addl $16, %esp<br>> > > > > > movl $1, -304(%ebp)<br>> > > > > > jmp L159<br>> > > > > > L158:<br>> > > > > > .stabn 68,0,185,LM96-_M3File__IsReadable<br>> > > > > > LM96:<br>> > > > > > movl $0, -304(%ebp)<br>> > > > > > L159:<br>> > > > > > LBE15:<br>> > > > > > movl -304(%ebp), %eax<br>> > > > > > leal -12(%ebp), %esp<br>> > > > > > popl %ebx<br>> > > > > > popl %esi<br>> > > > > > popl %edi<br>> > > > > > leave<br>> > > > > > ret<br>> > > > > ><br>> > > > > ><br>> > > > > > M3File.IsReadable's call to FS.Status is omitted, all files <br>> > are<br>> > > > > > readable, even if they are not openable, therefore it "finds"<br>> > > > > > cm3.cfg in the current directory and then fails to open it..<br>> > > > > ><br>> > > > > > later..<br>> > > > > > ..Jay<br>> > > > > ><br>> > > > > > Climb to the top of the charts! Play the word scramble <br>> > challenge<br>> > > > > > with star power. Play now!<br>> > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn<br>> > > > more.<br>> > > > ><br>> > > ><br>> > > ><br>> > > > Shed those extra pounds with MSN and The Biggest Loser! Learn <br>> > more.<br>> > ><br>> ><br>> > Climb to the top of the charts! Play the word scramble challenge <br>> > with star power. Play now!<br>> <br><br /><hr />Need to know the score, the latest news, or you need your HotmailŪ-get your "fix". <a href='http://www.msnmobilefix.com/Default.aspx' target='_new'>Check it out.</a></body>
</html>