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

Sun Jan 13 04:10:57 CET 2008

Yup.

On Jan 12, 2008, at 7:51 PM, Jay wrote:

>  > current_param_count
>
> Must this code use globals?
>
>  - Jay
>
>
> From: jayk123 at hotmail.com
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] could someone add __stdcall name mangling to  
> m3cc please?
> Date: Sun, 13 Jan 2008 00:49:10 +0000
>
> I commited something LIKE this, that lets m3core.dll link.
>  (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.)
>
> libm3.dll has a boring pathname format problem, ld doesn't like c: 
> \foo\../bar.lib and I got sidetracked..
>
> It MIGHT not work for SOME functions, a link error -- if taking  
> __int64 or small structs by value, in a __stdcall function.
> I'll see if that comes up as I progress through the system slowly.
>
>  - 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 19:06:35 -0500
> > To: jayk123 at hotmail.com
> >
> > 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!
> >
>
>
> Watch “Cause Effect,” a show about real people making a real  
> difference. Learn more
> Watch “Cause Effect,” a show about real people making a real  
> difference. Learn more