[cffi-devel] [Patch] LispWorks 5.0 and amd64 support

[Martin Simmons]

>>>>> On Sat, 22 Sep 2007 21:57:13 +0800, Chun Tian (binghe) said:
> 
> Luís Oliveira wrote:
> > Hello Tian,
> >
> > On 22/09/2007, Chun Tian (binghe) <binghe.lisp at gmail.com> wrote:
> >   
> >> -+          #-lispworks5
> >>            cffi-features:no-long-long
> >>     
> >
> > If possible, we should instead use one of the following approaches for
> > checking whether Lispworks has long long support:
> >
> >   * some feature keyword symbol specific to long long support,
> >     if Lispworks provides any.
> >
> >   * check for version 5.0 or higher, presuming all platforms support
> >     long long as of version 5.0. (does Lispworks provide something like
> >     Allegro's :VERSION>=?)
> >
> >   * programmatically check for long long support at read-time, i.e.:
> >     (eval-when (<always>)
> >       (unless (somehow-check-for-long-long-here)
> >         (pushnew 'cffi-features:no-long-long *features*)))
> >
> > If you could modify the patch to use one of these alternative
> > approaches, that would be great. Thanks.
> >
> >   
> You're right and I was wrong:
> 
> 1. It seems that only 64bit LispWorks 5.0 has long-long support, not
> 32bit, and it's undocumented.
> 2. the feature :lispworks-32bit does not exist in versions prior to 5.0,
> so I cannot use it to detect FOREIGN-TYPED-AREF.
> 
> The long-long support maybe detect using (fli::64bit-long-p), I found
> this function in both 4.4 and 5.0 version of lispworks.
> So I think maybe these #+lispworks5 and #-lispworks5 can be replaced
> with #+#.(cl:if (fli::64bit-long-p) '(and) '(or)), etc.
> 
> Another problem is that LispWorks's FOREIGN-TYPED-AREF cannot accept the
> type | (unsigned-byte 64)| and |(signed-byte 64) now,
> though people from LispWorks, Ltd say they will support this in next
> version. It's quite hard for me to give a patch which can still use
> other type on |FOREIGN-TYPED-AREF on platform support long-long, and
> this patch should also consider the future version of
> lispworks which can support | (unsigned-byte 64)| and |(signed-byte 64).
> 
> And, I think |Lispworks didn't provide something like  Allegro's
> :VERSION>=?), but seems LispWorks put its version in *features*,
> and LispWorks's version change is much small than Allegro, so the same
> detect maybe done with combined #+.
> 
> If Martin Simmons see this post, I hope he can give us a better answer.

Testing FLI::64BIT-LONG-P is not right -- it is false on Windows x64, but that
platform fully supports :long-long.

Support for :long-long is available in the LispWorks 5.0 FLI:
- On all 64-bit platforms.
- For FLI:DEFINE-FOREIGN-FUNCTION on all 32-bit platforms.

It is not avaliable in:
- LispWorks 4.
- For data access functions such as FLI:DEREFERENCE on 32-bit platforms.

Because of this last restriction, if CFFI wants to support :long-long on
32-bit LispWorks platforms, then it can do it for DEFCFUN but not other APIs.
A single cffi-feature is not enough to describe this, so it could just support
it on 64-bit platforms by using #-lispworks-64bit to enable
cffi-features:no-long-long.

To avoid the bugs in FOREIGN-TYPED-AREF, I suggest something like this for the
optimizers (untested):

#+#.(cl:if (cl:find-symbol "FOREIGN-TYPED-AREF" "FLI") '(and) '(or))
(define-compiler-macro %mem-ref (&whole form ptr type &optional (off 0))
  (if (constantp type)
      (let ((type (eval type)))
        (if (or (eql type :pointer)
		#+(and :lispworks-64bit :lispworks5.0)
		(member type '(:long :unsigned-long
                               :long-long :unsigned-long-long)))
            (let ((fli-type (convert-foreign-type type))
                  (ptr-form (if (eql off 0) ptr `(inc-pointer ,ptr ,off))))
              `(fli:dereference ,ptr-form :type ',fli-type))
            (let ((lisp-type (convert-foreign-typed-aref-type type))) 
              `(locally
                   (declare (optimize (speed 3) (safety 0)))
                 (fli:foreign-typed-aref ',lisp-type ,ptr (the fixnum ,off))))))
      form))

Hope that helps.

-- 
Martin Simmons
LispWorks Ltd
http://www.lispworks.com/