[MLton-devel] [MLton-user] _ffi and Windows stdcall symbols

[Stephen Weeks]

> Windows stdcall library entry points may be a problem as shown
> below.  Presumably either a different specifier is needed or the
> syntax of _ffi should be extended - possibly to include a header
> file to obtain a prototype.

Here's what I've learned.  stdcall and cdecl are two different calling
conventions for x86 machines.  With cdecl, what we've always used, the
caller pops the arguments.  With stdcall, the callee pops the
arguments, except with varargs.  In addition, on Cygwin/Windows,
stdcall appends to the end of the function name "@" followed by the
size in bytes of the arguments.  So, for example, _glClear becomes
_glClear@4 and _glColorMask becomes _glColorMask@16.  FreeBSD and
Linux do not change the name, only the calling convention.

It seems easy enough to modify both codegens to handle both types of
calls, for both imported and exported functions.  Actually, for
exported functions, it's really easy -- I can just add the appropriate
gcc attribute to the generated C functions.  As to how we should
indicate the attribute at the SML source level, I propose to allow a
sequence of attributes after the name but before the colon, as in:

	_ffi "name" <attribute>*: <ty>;
	_export "name" <attribute>*: <ty>;

For now, the only allowed attributes are "cdecl" and "stdcall", of
which at most one is allowed and the default is cdecl.  So, we could
do

	_ffi "glClear" stdcall: word -> unit;

and hopefully fix Mike's problem.

Another problem is that glClear is #if'ed to be stdcall on Cygwin but
cdecl on Linux.  The best fix I can see for this is to have the
stdcall attribute only apply when targeting Cygwin.

> Also on a related but more speculative note, maybe now is the best
> time to rationalise the naming of _ffi and _export, perhaps to
> reflect whatever standards might potentially be introduced in the
> forthcoming (unspecified ETA, of course) SML/NJ compiler.
> Compatibility of such extensions between these compilers would
> really boost library binding portability and availability I would
> expect.

My feelings are that development of SML/NJ has slowed to a point where
there's nothing to be gained by trying to synchronize extensions with
them.  We should try to make the design good so that users can
understand it and so that we can extend it in the future.

Although, we can discuss with the SML/NJ guys in a couple of weeks.

> Perhaps a lead could be taken from the Haskell 98 FFI Addendum?

I just read The Haskell 98 FFI Addendum and it is an excellent read.
They have a very similar design to ours (or should I say vice versa),
and have the "cdecl" (they call it "ccall") and "stdcall" attributes.
They actually specify C header files for imports, I guess to make it
easier on compilers that generate C so they don't have to make the
prototypes themselves.  I think that's a mistake.  Generating the
prototypes from the FFI decl, the way MLton does it, is better.  They
have a finalization interface that's directly tied to C pointers, but
I like our more general Finalizable module better.  They also have
some other features I'd like to have, like passing function pointers,
stable pointers that don't change across GC calls, and a nice
interface to malloc, sizeof, and peek/poke.  But for a future day.

For now, the only thing their report has inspired me to do is to
possibly change the syntax of _ffi and _export to be a little more
uniform.  One possibility would be to rename them like

	_import "name" <attribute>*: <ty>;
	_export "name" <attribute>*: <ty>;

Another, which follows the Haskell report, is to use a single _ffi
keyword, as in:

	_ffi {import|export} "name" <attribute>*: <ty>;

Any thoughts on this?  We could even make _ffi import the default so
as not to break old code.  But I'm not sure if that's a big deal since
it's an easy string replace to update.


Anyways, let me know your thoughts on this stuff.  I'm gonna try to
start in on attributes later today, and then respond to Mike on
MLton-user.



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel