Again: FFI syntax
Manuel M. T. Chakravarty
chak at cse.unsw.edu.au
Wed May 30 10:39:10 EDT 2001
Fergus Henderson <fjh at cs.mu.oz.au> wrote,
> On 29-May-2001, Manuel M. T. Chakravarty <chak at cse.unsw.edu.au> wrote:
> > Sven Panne <Sven_Panne at BetaResearch.de> wrote,
> > > Fergus Henderson wrote:
> > >
> > > > The calling convention should not necessarily default to 'ccall'.
> > > > That would not be appropriate for all implementations.
> > >
> > > Granted.
> > >
> > > > Instead, I think the default calling convention should be
> > > > implementation-dependent.
> > >
> > > Hmmm, this would make the semantics of the sources compiler-/interpreter-
> > > dependent, which is never a good thing.
> Making the semantics of a particular construct implementation-dependent is
> a good thing if the semantics that you want are implementation-dependent.
> Doing this allows the code to work correctly on different implementations
> without modifying the code.
> That is the case here, I believe. In particular, "ccall" is not abstract
> enough to use as a default. The default calling convention -- the one that
> you normally want -- is "whatever the corresponding C implementation uses".
> But on x86, "ccall" means a *particular* calling convention (args passed
> on stack, caller pops, return value in EAX, etc.) which may not match
> the one that your C implementation uses. If you have a C implementation
> which always passes args in registers, as is certainly allowed by the C
> standard, then you want to the default calling convention to be passing
> args in registers, otherwise nothing that uses the default will work.
How about saying that `ccall' means "whatever the
corresponding C implementation uses" on any platform?
(Nevertheless, the question of how the Haskell system
figures out what the C implementation uses, especially if
there are multiple C implementations with multiple
conventions is not, and cannot be handled.)
> > > > Also, implementations should be allowed to provide calling conventions
> > > > not on that list.
> > >
> > > IIRC the intention for enumerating some calling conventions here is to
> > > make future implementations agree on the name of callconv when they
> > > implement e.g. a C++ or Java FFI, not to rule out other possibilities.
> > Exactly.
> > > But this should be made clear from the FFI spec.
> > The spec said,
> > Generally, the set of calling conventions is open, as it
> > is infeasible to cover all useful calling conventions in
> > this report.
> > I have changed this now to
> > Generally, the set of calling conventions is open, i.e.,
> > individual implementations may elect to support additional
> > calling conventions.
> The words are clear, but IIRC they contradict the grammar.
> It would be nicer to make this explicit in the grammar.
callconv -> ccall | stdcall | cplusplus | jvm | dotnet |
| <implementation-specific conventions>
More information about the FFI