[M3devel] next problem (NT386GNU)

Jay jayk123 at hotmail.com
Tue Jan 22 00:06:41 CET 2008 

I don't want to deal with learning about CVS branches, please.

I can try the __cdecl thunk hack I had nearly working, over in m3-win\import-libs.
It's lame compared to my parse.c though.

Given void __stdcall Foo(int a, struct {int a, b}), or rather Foo 12,

it would generate

one source file/.obj
   void __stdcall F(int a, int b, int c);  
  

void __stdcall Fstdcall(int a, int b, int c) {  return Fstdcall(a b c); }  

another source file/.obj
  void __stdcall Fstdcall(int a, int b, int c);  
  


void __cdecl F(int a, int b, int c) {  return Fstdcall(a b c); }  


If I could put parse.c back, I could limit this to functions that take structs.
Or at least one function in particular that I know is a current problem.
Limiting this hack would be good.

 - Jay


> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> Subject: Re: next problem (NT386GNU)
> Date: Mon, 21 Jan 2008 17:32:32 -0500
> To: jayk123 at hotmail.com
> 
> I'd prefer to have the backend do it properly based on properly  
> declared types.  I'd prefer to keep this code out of the current  
> mainline of parse.c -- you could fork a temporary branch if necessary.
> 
> On Jan 21, 2008, at 5:16 PM, Jay wrote:
> 
> > 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. Play now!
> 

_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail®-get your "fix".
http://www.msnmobilefix.com/Default.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080121/1329ef8f/attachment-0002.html>

More information about the M3devel mailing list