[M3devel] next problem (NT386GNU)

Jay jayk123 at hotmail.com
Mon Jan 21 23:16:54 CET 2008 

Understood. Put back my parse.c in the meantime?

Also, the front end could do this, right? And probably without a stack?
It could compute "effective parameter size" and pass that down.
Backend could then divide by 4 and claim that is the signature,
that number of parameters.

Would have to see how passing a struct works out anyway -- one parameter
or one per field.

 - Jay


> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> Subject: Re: next problem (NT386GNU)
> Date: Mon, 21 Jan 2008 12:01:28 -0500
> To: jayk123 at hotmail.com
> 
> I just need to fix m3cc/cm3cg to emit the stdcall parameter  
> information for imported procedures.  It is simply a matter of not  
> ignoring declare_param for import_procedure chunks.  This means  
> maintaining a current_function_decl (and possibly a  
> current_param_count) stack (since import_procedure can occur inside a  
> declare_procedure chunk).  I know what needs doing, but have not much  
> free time right now...
> 
> On Jan 21, 2008, at 11:10 AM, Jay wrote:
> 
> > 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! Learn more.
> 

_________________________________________________________________
Climb to the top of the charts! Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080121/33f08bbd/attachment-0002.html>

More information about the M3devel mailing list