<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;">Understood. Put back my parse.c in the meantime?<br><br>Also, the front end could do this, right? And probably without a 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 parameter<br>or one per field.<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 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 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 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 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 front <br>> > end<br>> > > > generates passing an extra pointer parameter to the function, and<br>> > > > the function's return type is void.<br>> > > ><br>> > > > The NT calling conventions, all of them, are marked as 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 used, and,<br>> > > > well, somehow it doesn't know about the exceptions here. 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 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 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 to do<br>> > > > that but I'll look. This is still a bit overly pessimistic, since<br>> > > > what you really want to know is, not the function's side affects,<br>> > > > but whether or not it raised. If the function is inlined, the side<br>> > > > affects could be optimized away, or if there are enough callers <br>> > who<br>> > > > don't care about the side affects to warrant an 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 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 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 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 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 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 Posix?<br>> > > > What do you want from Cygwin?<br>> > > > One thing Cygwin does NOT give you is just one calling convention,<br>> > > > alas, this calling convention business stinks. It's not even an NT<br>> > > > thing, only an NT386 thing. All the other NT platforms had/have<br>> > > > only one calling convention.<br>> > > ><br>> > > > You can't get far on NT386 without needing to support two calling<br>> > > > conventions.<br>> > > > The "OS" uses mostly __stdcall -- callee pops -- smaller, faster.<br>> > > > But anything that is varargs, such as printf -- pretty much must<br>> > > > use caller pops -- __cdecl.<br>> > > > As well, __cdecl is the default, so prevalent, and used in most C<br>> > > > runtime functions.<br>> > > > There is also __fastcall that uses like up to two registers 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 string. On<br>> > > > most platforms, printf("", 1, 2, 3, 4) just does nothing, 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 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 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 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 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 more.<br>> <br><br /><hr />Climb to the top of the charts! Play the word scramble challenge with star power. <a href='http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan' target='_new'>Play now!</a></body>
</html>