[M3devel] could someone add __stdcall name mangling to m3cc please?

[Jay]

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 at elegosoft.com> From: hosking at 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 at 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 at 0, GetFileAttributes at 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 at 28> > 00000000 T _CreateFileW at 28> > 00000000 I __imp__CreateFileMappingW at 24> > 00000000 T _CreateFileMappingW at 24> > 00000000 I __imp__CreateFileMappingA at 24> > 00000000 T _CreateFileMappingA at 24> > 00000000 I __imp__CreateFileA at 28> > 00000000 T _CreateFileA at 28> >> > C:\cygwin\lib\w32api>cd \MinGW\lib> >> > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile> > 00000000 I __imp__CreateFileW at 28> > 00000000 T _CreateFileW at 28> > 00000000 I __imp__CreateFileMappingW at 24> > 00000000 T _CreateFileMappingW at 24> > 00000000 I __imp__CreateFileMappingA at 24> > 00000000 T _CreateFileMappingA at 24> > 00000000 I __imp__CreateFileA at 28> > 00000000 T _CreateFileA at 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™.
http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080112/58eb21cc/attachment-0002.html>