<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>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 view, and if that is wrong, the compiler will reorder.<BR><BR>
"everything" works now<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<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 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 return <BR>> > value isn't used here.<BR>> > The point of the function call is to see if it generates an 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 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 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 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, but <BR>> > no side affects otherwise. This is "advanced" optimization the 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 < 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 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 more.<BR>> <BR><BR><br /><hr />Shed those extra pounds with MSN and The Biggest Loser! <a href='http://biggestloser.msn.com/' target='_new'>Learn more.</a></body>
</html>