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