Adding modifiers to NCI

Joshua Juran jjuran at gmail.com
Mon Dec 29 06:33:28 UTC 2008


On Dec 27, 2008, at 3:20 AM, Reini Urban wrote:

> 2008/12/27 chromatic <chromatic at wgz.org>:
> ...
>> It doesn't, because every NCI signature expresses C calling  
>> conventions.
>> That's what they're for.
>
> Just to make it clear.
> Beware that these "C calling conventions" (not only __cdecl) should
> include the so-called "pascal" (__stddecl) and "fastcall" (__fastcall)
> calling conventions also.
>
> Otherwise we are locked out on Windows and IA-64.

For completeness (more than anything else) I'll mention that 68K Mac  
OS also has 'pascal' functions (including all of the Macintosh  
Toolbox traps) as well as C calling conventions.  There are also  
register-based OS traps, but the assembler glue is provided in the  
headers, they're no worse than plain A-traps.  The only complication  
is that the call is necessarily inlined and there is no function to  
take a pointer to, unless you define a wrapper yourself.

Then there's Mixed Mode, where 68K and PowerPC code can be mixed (on  
PowerPC).  This is transparent for 68K callers, but PowerPC code has  
to be aware of when it's calling through a 'universal' function pointer.

On PPC OS X there's potentially both CFM and Mach-O code running in  
the same process.

I don't know what significance (if any) this has to Parrot.  I have  
never intended to port Unix tools to Mac OS proper, but to a Unix- 
like environment that hides Mac OS behind POSIX system calls and  
generally mitigates the risk of hosing the system due to not making  
the right calls in the right order -- direct calls to the OS from  
Parrot are not of great importance to me, although it would be nice  
if they remained at least theoretically possible.

Josh




More information about the parrot-dev mailing list