<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Tony, Sorry, I didn't mean to check those in. Those were wild guesses that I hadn't tested yet.<BR>I put it back. Thanks for catching that.<BR>
 <BR>
 - Jay<BR><BR><BR>

<HR id=stopSpelling>
<BR>
> CC: m3devel@elegosoft.com<BR>> From: hosking@cs.purdue.edu<BR>> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?<BR>> Date: Sat, 12 Jan 2008 10:41:26 -0500<BR>> To: jayk123@hotmail.com<BR>> <BR>> I'm not sure what you were trying to do with parse.c by adding a <BR>> parameter (nargs*4) to the stdcall attribute, but that probably <BR>> doesn't do anything interesting. The problem appears to be because <BR>> on external function decls the parameter decls are currently being <BR>> ignored by cm3cg. If I fix parse.c to add the params for those then <BR>> it should work properly with the stdcall attribute.<BR>> <BR>> On Jan 12, 2008, at 8:27 AM, Jay wrote:<BR>> <BR>> > Thanks, but not quite. The number of parameters times four needs to <BR>> > be appended to the name, in decimal.<BR>> > But I'm just getting 0.<BR>> > That is, gcc is handling the underlying detail, but you aren't <BR>> > giving it enough infomrmation.<BR>> > I'll see if I can bang out those temporary wrappers automatically.. <BR>> > (a Quake programming challenge, that I've already invented the hard <BR>> > part of I think -- Quake can't do math..)<BR>> ><BR>> > - Jay<BR>> ><BR>> ><BR>> > > CC: m3devel@elegosoft.com<BR>> > > From: hosking@cs.purdue.edu<BR>> > > Subject: Re: [M3devel] could someone add __stdcall name mangling <BR>> > to m3cc please?<BR>> > > Date: Fri, 11 Jan 2008 13:16:44 -0500<BR>> > > To: jayk123@hotmail.com<BR>> > ><BR>> > > I just added support for this. Let me know if it seems to work (or<BR>> > > not! :-) ).<BR>> > ><BR>> > ><BR>> > > On Jan 10, 2008, at 7:40 AM, Jay wrote:<BR>> > ><BR>> > > > Could someone out there (Tony?) familiar with the gcc backend<BR>> > > > have it not ignore call_conv and if call_conv is 1, append<BR>> > > > an at symbol and the number of bytes of parameters to the function<BR>> > > > name?<BR>> > > > (Even for zero, e.g. Sleep@0, GetFileAttributes@4).<BR>> > > > This would be I guess at least for "imported" functions.<BR>> > > ><BR>> > > > Not clear about calling function pointers, probably needs<BR>> > > > modification.<BR>> > > > call_conv 0 is "__cdecl" is push right to left, caller cleans up<BR>> > > > call_conv 1 is "__stdcall" is push right to left, callee cleans up<BR>> > > > There are various synonyms.<BR>> > > > With no command line switches, __cdecl is the compiler default.<BR>> > > > __stdcall is deemed more efficient, and is very widely used.<BR>> > > ><BR>> > > > Not clear about functions implemented in Modula-3.<BR>> > > > Probably won't occur? Maybe for callbacks? WindowProcs, thread<BR>> > > > entry point?<BR>> > > ><BR>> > > > This could/should be for NT386GNU only.<BR>> > > > The hypothetical other NT targets only have one calling convention<BR>> > > > each.<BR>> > > ><BR>> > > > I COULD do something sleazy here and generate little adapter<BR>> > > > functions, over in m3-win/import-libs esp.<BR>> > > ><BR>> > > > I'm still checking out pm3 to see what it does here.<BR>> > > > (as in cvs checkout, not "looking at")<BR>> > > ><BR>> > > > This'll clear up:<BR>> > > ><BR>> > > > RTOS.m3:27: undefined reference to `_FatalExit'<BR>> > > > RTOS.mo: In function `RTOS__GetMemory':<BR>> > > > RTOS.m3:75: undefined reference to `_VirtualAlloc'<BR>> > > > RTOS.m3:85: undefined reference to `_VirtualAlloc'<BR>> > > > RTOS.mo: In function `RTOS__InitMemory':<BR>> > > > RTOS.m3:96: undefined reference to `_VirtualAlloc'<BR>> > > > RTOS.m3:100: undefined reference to `_GetSystemInfo'<BR>> > > > RTOS.mo: In function `RTOS__Write':<BR>> > > > RTOS.m3:118: undefined reference to `_AllocConsole'<BR>> > > > RTOS.m3:119: undefined reference to `_GetStdHandle'<BR>> > > > RTOS.m3:122: undefined reference to `_WriteFile'<BR>> > > > RTPerfTool.mo: In function `RTPerfTool__Start':<BR>> > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'<BR>> > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'<BR>> > > > RTPerfTool.mo: In function `RTPerfTool__Close':<BR>> > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'<BR>> > > > RTPerfTool.mo: In function `RTPerfTool__Send':<BR>> > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'<BR>> > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':<BR>> > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'<BR>> > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'<BR>> > > > etc.<BR>> > > ><BR>> > > > I did think I was past these. I thought I built m3core and libm3<BR>> > > > including linking (having even modified cm3.cfg)<BR>> > > > COULD be I'm using the wrong .libs, but:<BR>> > > ><BR>> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile<BR>> > > > 00000000 I __imp__CreateFileW@28<BR>> > > > 00000000 T _CreateFileW@28<BR>> > > > 00000000 I __imp__CreateFileMappingW@24<BR>> > > > 00000000 T _CreateFileMappingW@24<BR>> > > > 00000000 I __imp__CreateFileMappingA@24<BR>> > > > 00000000 T _CreateFileMappingA@24<BR>> > > > 00000000 I __imp__CreateFileA@28<BR>> > > > 00000000 T _CreateFileA@28<BR>> > > ><BR>> > > > C:\cygwin\lib\w32api>cd \MinGW\lib<BR>> > > ><BR>> > > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile<BR>> > > > 00000000 I __imp__CreateFileW@28<BR>> > > > 00000000 T _CreateFileW@28<BR>> > > > 00000000 I __imp__CreateFileMappingW@24<BR>> > > > 00000000 T _CreateFileMappingW@24<BR>> > > > 00000000 I __imp__CreateFileMappingA@24<BR>> > > > 00000000 T _CreateFileMappingA@24<BR>> > > > 00000000 I __imp__CreateFileA@28<BR>> > > > 00000000 T _CreateFileA@28<BR>> > > ><BR>> > > > I think at least THREE calling conventions should be supported --<BR>> > > > __cdecl, __stdcall, __fastcall --<BR>> > > > but oh well. We can live without __fastcall.<BR>> > > > Watcom has another calling convention, "watcall", and they let you<BR>> > > > describe calling conventions with #pragmas, neat.<BR>> > > ><BR>> > > > Thanks,<BR>> > > > - Jay<BR>> > > ><BR>> > > > Share life as it happens with the new Windows Live. Start sharing!<BR>> > ><BR>> ><BR>> ><BR>> > Make distant family not so distant with Windows Vista® + Windows <BR>> > Live™. Start now!<BR>> <BR><BR><br /><hr />Watch “Cause Effect,” a show about real people making a real difference. <a href='http://im.live.com/Messenger/IM/MTV/?source=text_watchcause' target='_new'>Learn more</a></body>
</html>