[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: ff-interface
- From: firstname.lastname@example.org (Tobias Kunze)
- Date: Thu, 6 May 93 01:16:05 +0200
yesterday i sent a description of a problem that i have with mcl's foreign-
function-interface, but it apparently didn't make it to cambridge.apple.com.
Today i posted another message which refered to the former, so i think it
would be best to describe the whole thing again:
I am dealing with the apple midimanager, but that's not important except for
the fact that it implies that some functions (which i write in c) may be
called at interrupt level.
To sum up, one could think of three different layers which my program handles:
Lisp, foreign functions written in c, and the MidiManager.
Moreover, there a three 'classes' of c functions: one class that gets called
from lisp, as described in the mcl manual via deffcfun, another one that gets
called from, and returns to the midimanager (callback functions), and a third
class that gets called by the midimanager, but additionally calls Lisp, too,
before returning to the midimanager again -- those are defined, again according
to the manual, via the defccallable macro.
Now here is the problem: all three sets of functions need to share a few
variables to communicate with each other, which implies the use of register a5.
Normally, the ff-interface is expected to supply an appropriate a5 pointer,
which it has set up while loading the code, exactly during the call. This holds
true for the first set of functions, those that are called directly from lisp.
However, the other two sets of functions fail to get their a5 pointer surrogat
and thus simply write to, or read from random memory locations (in fact, they
use mcl's own a5 pointer, but there's little diffrence :-().
I had functions which were called from the midimanager, then called a lisp
function, and the returned to the midimanager (the third 'class' or 'set'
before, and they used to work, that is, they could reference their lisp entry
point in their own a5-world correctly. So i know at least that this function
type works well -- and i have no doubt, those that skip such a lisp callback
should work, too.
After all, the a5-global area: the data area and the jumptable are both
as is the foreign-function structure in lisp and their a5-ptr slot. But for
reason, some functions don't get this pointer supplied.
Does anyone have an idea, what could be wrong? The manual is not very
in its explanations, especially how the ff-interface's function calling
Thanks a lot in advance, and please ignore the other message!