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

[Mika Nystrom]

Hmm my Klagenfurt distribution of PM3 has a bunch of Trestle things
in it.  mentor even works sometimes.  But I am not sure exactly
when it came out or what kinds of tricks they were doing in the
backend.  One can track it down by following the link in an email
I sent yesterday or the day before, but it's a binary distribution.

    Mika

Tony Hosking writes:
>
>On Jan 10, 2008, at 7:42 AM, Jay wrote:
>
>> PM3 appears to ignore call_conv.
>> Perhaps its NT386GNU uses usermode threads via cygwin1.dll and has  
>> no gui support, such as to not import any __stdcall functions???
>
>Probably, yes.  CM3 were the ones who added gui support.  Anyway, I  
>think it is simply a matter of adding the appropriate attribute to  
>the function decls in the gcc backend.  I believe that it supports  
>cdecl and stdcall.  Are these all we need to specify?
>
>> http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/m3/pm3/language/ 
>> modula3/m3compiler/m3cc/gcc/gcc/m3cg/m3.c?rev=1.1;content-type=text% 
>> 2Fx-cvsweb-markup;cvsroot=PM3
>>
>>  - Jay
>>
>> From: jayk123 at hotmail.com
>> To: m3devel at elegosoft.com
>> Date: Thu, 10 Jan 2008 12:40:22 +0000
>> Subject: [M3devel] could someone add __stdcall name mangling to  
>> m3cc please?
>>
>> 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!
>> Get the power of Windows + Web with the new Windows Live. Get it now!