[Openmcl-devel] How do I make a cocoa method that returns a float

Gary Byers gb at clozure.com
Tue Feb 22 13:57:36 PST 2005

On Tue, 22 Feb 2005, Anders Conradi wrote:

> On tisdag, feb 22, 2005, at 00:32 Europe/Stockholm, Dan Knapp wrote:
> >> How do I implement cocoa methods that return floats? I
> >
> >   It's not implemented yet - I ran into this a little while
> > ago.  For now, you should probably just reconsider whether
> > you really need to.  And I should make sure it's documented...
> I need that float return since I am overriding a method that returns a
> float.
> Anyway, it is more fun to at least try to implement it first.
> I dug into the internals of OpenMCL to see what is going on.
> When I do defcallback the callback body is wrapped inside a lambda that
> takes a mac-ptr and places the result of the body into that ptr. Then
> the named lambda and some auxiliary information is wrapped into a pfe
> vector. The pfe vector is added to %pascal-functions%. Then a
> trampoline is created. The trampoline is some ppc-code that calls the
> subprim .SPcallback with the index to the pfe vector. When the callback
> is called the trampoline is called and it calls the subprim. The
> subprim must call the lambda containing the callback body with a
> mac-ptr for the result. Then it places the result into gpr3 and returns
> to the foreign code. My hope is that it would be easy to hack the
> subprim to also place the result into fpr1, which is used to return
> floating point values. Since fpr1 isn't preserved across function calls
> this shouldn't break code that wants integer results.
> I am sure that I have underestimated the difficulty and missed
> something. I don't even know PPC assembly, but by adding one line to
> spentry.s and rebuilding the kernel my callback test seems to return
> the correct value. Unfortunately callbacks can't recieve floats and
> still can't return doubles.
> Well, anyway here it is.

The Linux version (the "EABI callback") does the right thing (namely,
returns both GPR3 and FPR1 from where they're stored in the pointer.)
The Linux version of the Lisp side of things also stores a float
return value where the callback will find it.

The Darwin version's been broken forever ..  both the lisp and kernel
side of the callback need to cooperate in more-or-less the same way
that the Linux versions do (the same general idea, but the offsets
may need to be a little different.)

For extra credit: we should ensure that 64-bit integer values also
get returned correctly.

More information about the Openmcl-devel mailing list