<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>I commited something LIKE this, that lets m3core.dll link.<BR>
(The below had several errors. Failing to loop, failing to terminate the list correctly, only getting function pointers or functions instead of both, for some reason the Windows *.i3 files use a mix.)<BR>
<BR>
libm3.dll has a boring pathname format problem, ld doesn't like c:\foo\../bar.lib and I got sidetracked..<BR>
<BR>
It MIGHT not work for SOME functions, a link error -- if taking __int64 or small structs by value, in a __stdcall function.<BR>
I'll see if that comes up as I progress through the system slowly.<BR>
<BR>
- Jay<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 19:06:35 -0500<BR>> To: jayk123@hotmail.com<BR>> <BR>> It will need to be a little cleaner than that -- I'd rather gather <BR>> the parameters as declared and enter them into the function type. It <BR>> means not ignoring the parameter decls: see m3cg_declare_param check <BR>> for current_param_count==0. To do this it needs to be a little bit <BR>> smarter about managing current_function_decl -- probably a stack.<BR>> <BR>> On Jan 12, 2008, at 2:57 PM, Jay wrote:<BR>> <BR>> > 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>> ><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 <BR>> > to m3cc please?<BR>> > ><BR>> > > Tony, Sorry, I didn't mean to check those in. Those were wild <BR>> > guesses that I hadn't tested yet.I put it back. Thanks for catching <BR>> > that.<BR>> > ><BR>> > > - Jay<BR>> > ><BR>> > ><BR>> > ><BR>> > > > CC: m3devel@elegosoft.com> From: hosking@cs.purdue.edu> <BR>> > Subject: Re: [M3devel] could someone add __stdcall name mangling to <BR>> > m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: <BR>> > jayk123@hotmail.com> > I'm not sure what you were trying to do with <BR>> > parse.c by adding a > parameter (nargs*4) to the stdcall attribute, <BR>> > but that probably > doesn't do anything interesting. The problem <BR>> > appears to be because > on external function decls the parameter <BR>> > decls are currently being > ignored by cm3cg. If I fix parse.c to <BR>> > add the params for those then > it should work properly with the <BR>> > stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > <BR>> > Thanks, but not quite. The number of parameters times four needs to <BR>> > > > be appended to the name, in decimal.> > But I'm just getting <BR>> > 0.> > That is, gcc is handling the underlying detail, but you <BR>> > aren't > > giving it enough infomrmation.> > I'll see if I can bang <BR>> > out those temporary wrappers automatically.. > > (a Quake <BR>> > programming challenge, that I've already invented the hard > > part <BR>> > of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: <BR>> > m3devel@elegosoft.com> > > From: hosking@cs.purdue.edu> > > <BR>> > Subject: Re: [M3devel] could someone add __stdcall name mangling > <BR>> > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > <BR>> > To: jayk123@hotmail.com> > >> > > I just added support for this. <BR>> > Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > <BR>> > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone <BR>> > out there (Tony?) familiar with the gcc backend> > > > have it not <BR>> > ignore call_conv and if call_conv is 1, append> > > > an at symbol <BR>> > and the number of bytes of parameters to the function> > > > name?> <BR>> > > > > (Even for zero, e.g. Sleep@0, GetFileAttributes@4).> > > > <BR>> > This would be I guess at least for "imported" functions.> > > >> > <BR>> > > > Not clear about calling function pointers, probably needs> > > <BR>> > > modification.> > > > call_conv 0 is "__cdecl" is push right to <BR>> > left, caller cleans up> > > > call_conv 1 is "__stdcall" is push <BR>> > right to left, callee cleans up> > > > There are various synonyms.> <BR>> > > > > With no command line switches, __cdecl is the compiler <BR>> > default.> > > > __stdcall is deemed more efficient, and is very <BR>> > widely used.> > > >> > > > Not clear about functions implemented in <BR>> > Modula-3.> > > > Probably won't occur? Maybe for callbacks? <BR>> > WindowProcs, thread> > > > entry point?> > > >> > > > This could/ <BR>> > should be for NT386GNU only.> > > > The hypothetical other NT <BR>> > targets only have one calling convention> > > > each.> > > >> > > > <BR>> > I COULD do something sleazy here and generate little adapter> > > > <BR>> > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still <BR>> > checking out pm3 to see what it does here.> > > > (as in cvs <BR>> > checkout, not "looking at")> > > >> > > > This'll clear up:> > > >> <BR>> > > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > <BR>> > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: <BR>> > undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: undefined <BR>> > reference to `_VirtualAlloc'> > > > RTOS.mo: In function <BR>> > `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to <BR>> > `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to <BR>> > `_GetSystemInfo'> > > > 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.> > > >> > > > I did think I was past these. I thought I <BR>> > built m3core and libm3> > > > including linking (having even <BR>> > modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> <BR>> > > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr <BR>> > CreateFile> > > > 00000000 I __imp__CreateFileW@28> > > > 00000000 <BR>> > T _CreateFileW@28> > > > 00000000 I __imp__CreateFileMappingW@24> > <BR>> > > > 00000000 T _CreateFileMappingW@24> > > > 00000000 I <BR>> > __imp__CreateFileMappingA@24> > > > 00000000 T <BR>> > _CreateFileMappingA@24> > > > 00000000 I __imp__CreateFileA@28> > > <BR>> > > 00000000 T _CreateFileA@28> > > >> > > > C:\cygwin\lib\w32api>cd <BR>> > \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr <BR>> > CreateFile> > > > 00000000 I __imp__CreateFileW@28> > > > 00000000 <BR>> > T _CreateFileW@28> > > > 00000000 I __imp__CreateFileMappingW@24> > <BR>> > > > 00000000 T _CreateFileMappingW@24> > > > 00000000 I <BR>> > __imp__CreateFileMappingA@24> > > > 00000000 T <BR>> > _CreateFileMappingA@24> > > > 00000000 I __imp__CreateFileA@28> > > <BR>> > > 00000000 T _CreateFileA@28> > > >> > > > I think at least THREE <BR>> > calling conventions should be supported --> > > > __cdecl, <BR>> > __stdcall, __fastcall --> > > > but oh well. We can live without <BR>> > __fastcall.> > > > Watcom has another calling convention, <BR>> > "watcall", and they let you> > > > describe calling conventions <BR>> > with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > <BR>> > > Share life as it happens with the new Windows Live. Start sharing! <BR>> > > > >> >> >> > Make distant family not so distant with Windows <BR>> > Vista® + Windows > > Live™. Start now!><BR>> > > _________________________________________________________________<BR>> > > Watch “Cause Effect,” a show about real people making a real <BR>> > difference<BR>> ><BR>> ><BR>> > Get the power of Windows + Web with the new Windows Live. Get it 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>