[M3devel] next problem (NT386GNU)

[Jay]

agreed once I thought about it
I guess that explains left to right as well.
Parameters are always left to right from a higher level point of view, and if that is wrong, the compiler will reorder.
"everything" works now
 
 - Jay



> CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: next problem (NT386GNU)> Date: Mon, 21 Jan 2008 10:54:10 -0500> To: jayk123 at hotmail.com> > Surely, when using the gcc-based backend then we should make the > backend handle it. The front end handling it is only need for the > integrated x86 backend.> > On Jan 21, 2008, at 2:43 AM, Jay wrote:> > > I haven't tested a fix but I see the problem.> >> > This function returns a struct.> > There are two struct returning calling conventions.> > In one, the backend handles it. Which includes the backend knowing > > there is a return value and its type (or at least its size?).> > In the other, the front end handles it. In this case, the front end > > generates passing an extra pointer parameter to the function, and > > the function's return type is void.> >> > The NT calling conventions, all of them, are marked as front end > > handling it. I assume that is correct, could check.> > Everything else is marked as back end handling.> >> > Now then, somewhere along the line, gcc figures out that the return > > value isn't used here.> > The point of the function call is to see if it generates an exception.> >> > Gcc removes the function because its return value isn't used, and, > > well, somehow it doesn't know about the exceptions here. I'll have > > to see how "raise" is implemented. I think it's by a call to a > > function that gets the jmpbuf from a thread local and calls > > longjmp. (Did I mention it is very inefficient?)> >> > There are few possible fixes, but nothing completely satisfactory > > yet in mind.> >> > One is have parse.c mark all function calls as having side affects. > > This is easy, but overly pessimistic.> > Another is for the front end to mark struct returning functions as > > having side affects. Better, but still overly pessimistic.> > Another is for the front end to mark any function that can raise as > > having side affects. Getting better still. I don't know how to do > > that but I'll look. This is still a bit overly pessimistic, since > > what you really want to know is, not the function's side affects, > > but whether or not it raised. If the function is inlined, the side > > affects could be optimized away, or if there are enough callers who > > don't care about the side affects to warrant an optimization, and > > depending on the cost of computing the side affects, another > > instance of the function could be made that only raises or not, but > > no side affects otherwise. This is "advanced" optimization the sort > > of which tends never to be implemented.> >> > I think the best option is anything that can raise is marked as > > having side affects.> > I'll see if I can figure that out.> >> > You can figure this out by looking at m3cgcat -binary < M3File.mc > > > 1.txt on PPC_DARWIN and NT386GNU and comparing.> >> > Maybe marking all or nearly functions as having side effects isn't > > so bad.> > Or at least anything returning a struct. That gets parity with > > other platforms, even if it is a bit pessimistic.> > I think I'll do that, and ignore figuring out if raise is called > > and using that as a filter.> > The parity angle is good.> >> > The good news for all you Unix lovers :) is this bug is relatively > > portable to Cygwin.> > True, it is specific to NT386GNU having multiple "calling > > conventions", which no other platform has.> > Which again, jokingly, strikes at the question -- What is Posix? > > What do you want from Cygwin?> > One thing Cygwin does NOT give you is just one calling convention, > > alas, this calling convention business stinks. It's not even an NT > > thing, only an NT386 thing. All the other NT platforms had/have > > only one calling convention.> >> > You can't get far on NT386 without needing to support two calling > > conventions.> > The "OS" uses mostly __stdcall -- callee pops -- smaller, faster.> > But anything that is varargs, such as printf -- pretty much must > > use caller pops -- __cdecl.> > As well, __cdecl is the default, so prevalent, and used in most C > > runtime functions.> > There is also __fastcall that uses like up to two registers for > > parameters.> >> > I have seen a platform in which printf did the pop, and it depended > > on the number/size of parameters matching the format string. On > > most platforms, printf("", 1, 2, 3, 4) just does nothing, but on > > that platform, it'd unbalance the stack and crash.> >> > - Jay> >> > From: jayk123 at hotmail.com> > To: hosking at cs.purdue.edu> > CC: m3devel at elegosoft.com> > Subject: next problem (NT386GNU)> > Date: Mon, 21 Jan 2008 05:47:28 +0000> >> > M3File.m3> >> > PROCEDURE IsReadable (path: TEXT): BOOLEAN => > (* We don't really check for readablitiy, just for existence *)> > BEGIN> > TRY> > EVAL FS.Status (path); line 82> > RETURN TRUE;> > EXCEPT OSError.E =>> > RETURN FALSE;> > END;> > END IsReadable;> >> > -----LINE 82 -----> > start_call_direct p.25 0 Struct> > load_address v.25 0> > pop_param Addr> > load v.26 0 Addr Addr> > pop_param Addr> > call_direct p.25 Struct> > pop Struct> >> >> >> > I'm guessing you only see an import for the first call on purpose, > > but I will compare with PPC_DARWIN:> >> > -----LINE 46 -----> > import_procedure FS__Status 2 Struct 0 p.25> > declare_indirect 2078421550 -2078421551> > declare_param _return 4 4 Addr 2078421550 F F 50 v.62> > declare_param p 4 4 Addr 1358456180 F F 50 v.63> > start_call_direct p.25 0 Struct> > load_address v.13 0> > pop_param Addr> > load v.14 0 Addr Addr> > pop_param Addr> > call_direct p.25 Struct> > pop Struct> >> >> > .globl _M3File__IsReadable> > .def _M3File__IsReadable; .scl 2; .type 32; .endef> > _M3File__IsReadable:> > .stabn 68,0,178,LM93-_M3File__IsReadable> > LM93:> > pushl %ebp> > movl %esp, %ebp> > pushl %edi> > pushl %esi> > pushl %ebx> > subl $300, %esp> > LBB15:> > .stabn 68,0,181,LM94-_M3File__IsReadable> > LM94:> > L157:> > movl -280(%ebp), %eax> > andl $0, %eax> > orl $_L_1, %eax> > movl %eax, -280(%ebp)> > movl -284(%ebp), %eax> > andl $0, %eax> > movl %eax, -284(%ebp)> > subl $12, %esp> > leal -288(%ebp), %eax> > pushl %eax> > call _RTHooks__PushEFrame> > addl $16, %esp> > leal -288(%ebp), %eax> > addl $48, %eax> > subl $12, %esp> > pushl %eax> > call __setjmp> > addl $16, %esp> > testb %al, %al> > jne L158> > .stabn 68,0,183,LM95-_M3File__IsReadable> > LM95:> > movl -288(%ebp), %eax> > subl $12, %esp> > pushl %eax> > call _RTHooks__PopEFrame> > addl $16, %esp> > movl $1, -304(%ebp)> > jmp L159> > L158:> > .stabn 68,0,185,LM96-_M3File__IsReadable> > LM96:> > movl $0, -304(%ebp)> > L159:> > LBE15:> > movl -304(%ebp), %eax> > leal -12(%ebp), %esp> > popl %ebx> > popl %esi> > popl %edi> > leave> > ret> >> >> > M3File.IsReadable's call to FS.Status is omitted, all files are > > readable, even if they are not openable, therefore it "finds" > > cm3.cfg in the current directory and then fails to open it..> >> > later..> > ..Jay> >> > Climb to the top of the charts! Play the word scramble challenge > > with star power. Play now!> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> 
_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080121/0a2c5b2e/attachment-0002.html>