Re: a return to struct madness?

--OXfL5xGRrasGEqWY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Dec 28, 2004 at 11:57:42AM -0700, Kevin Rosenberg wrote:
> I've not heard that alien:addr changes the allocation, but it wouldn't
> surprise me if it did cons. SBCL and CMUCL have the potential to very
> inefficient with alien access if you happen to trigger some consing. I
> use alien:addr so that UFFI application code would be the same if
> using either heap or stack based allocation. As you likely know,
> CMUCL/SBCL stack based and heap based objects are different.  I've not
> done any benchmarks for stack-based allocation with UFFI across
> platforms.

A while ago, when I was trying to fix this same problem in CL-SDL, I
noticed that the SBCL alien code, at least, appears to just drop the
possibility of stack allocation if it hits a %sap-alien; I suppose it's
possible that I could try modifying it to behave more intelligently
about this.

> > Also, I noticed that the OpenMCL inconsistency with get-slot-value still
> > seems to be in place; I have to use reader conditionals on whether to
> > quote the type name.
> 
> That shouldn't be. I did accept a patch from the mail list about 4
> months ago that broke quoting with OpenMCL, but I since reverted the
> patch. Could you send some sample code to me? Something that requires
> reader conditionals in application code in unaccetable. The goal of
> UFFI is to get rid of those.

Ah, sure enough -- my openmcl machine was still using UFFI 1.4.25.  I
apologize for the confusion; I realize now I had only updated UFFI on my
x86 machines.  That's one issue out of the way, anyway.

Attached is a simple test that demonstrates the stack problem; on my
machines, it's basically unusable on CMUCL 19a/x86, conses unacceptably
on SBCL/x86 and SBCL/PPC, and runs just fine on OpenMCL.  Hopefully I'm
just doing something stupid that you can point out immediately.

If it's something that's insoluble at the UFFI layer, that's probably
okay; right now, my code uses a wrapper around with-foreign-objects,
that uses a simpler expansion on SBCL/CMU without the alien:addr call.
Then, when I make calls that require a pointer to the alien value, I use
a macro pointer-to-object which expands to (alien:alien-sap object) on
SBCL/CMU, and just object on other platforms.  That's a bit ugly, but it
works for me for the moment.

Cheers.

-- 
Julian Squires

--OXfL5xGRrasGEqWY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="uffi-test.lisp"

(asdf:oos 'asdf:load-op :uffi)

(uffi:load-foreign-library "./uffi-test.so" :module "uffi-test")

(uffi:def-struct foo-s (x :int))

(uffi:def-function "get_a_foo" ((foo (* foo-s)))
  :returning :void :module "uffi-test")

(defun lots-of-foo ()
  (dotimes (i 100000)
    (uffi:with-foreign-object (foo '(:struct foo-s))
      (get-a-foo foo)
      (assert (= (uffi:get-slot-value foo foo-s 'x) 42)))))

(time (lots-of-foo))


--OXfL5xGRrasGEqWY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="uffi-test.c"


struct foo_s {
    int x;
};

void get_a_foo(struct foo_s *foo)
{
    foo->x = 42;
    return;
}

--OXfL5xGRrasGEqWY
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
UFFI-Devel mailing list
[email protected]
http://lists.b9.com/mailman/listinfo/uffi-devel

--OXfL5xGRrasGEqWY--