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