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

[Tony Hosking]

It will need to be a little cleaner than that -- I'd rather gather  
the parameters as declared and enter them into the function type.  It  
means not ignoring the parameter decls: see m3cg_declare_param check  
for current_param_count==0.  To do this it needs to be a little bit  
smarter about managing current_function_decl -- probably a stack.

On Jan 12, 2008, at 2:57 PM, Jay wrote:

> Something like this?????
>
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v
> retrieving revision 1.41
> diff -r1.41 parse.c
> 3066a3070
> >   tree atypes = NULL_TREE);
> 3091c3095,3102
> <   TREE_TYPE (p) = build_function_type (return_type, NULL_TREE);
> ---
> >   /* for NT386 __stdcall, we just need to declare the right number
> >   of parameters
> >   */
> >   if (--n_params== 0) {
> >     atypes = tree_cons (NULL_TREE, t_word, atypes);
> >   }
> >
> >   TREE_TYPE (p) = build_function_type (return_type, atypes);
>
> haven't even compiled it yet..
>
>  - Jay
>
>
>
>
>
>
> > From: jayk123 at hotmail.com
> > To: hosking at cs.purdue.edu
> > Date: Sat, 12 Jan 2008 18:13:27 +0000
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] could someone add __stdcall name mangling  
> to m3cc please?
> >
> > 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.
> >
> > - 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: Sat, 12 Jan 2008 10:41:26 -0500> To:  
> jayk123 at 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 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!>
> > _________________________________________________________________
> > Watch “Cause Effect,” a show about real people making a real  
> difference
>
>
> Get the power of Windows + Web with the new Windows Live. Get it now!