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

[Tony Hosking]

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 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™. Start now!