Hi,
Am I correct in thinking that the groveller doesn't grovel for functions and automatically create the correct defcfun forms for a given library?
On Fri, Aug 7, 2009 at 10:44 AM, Andy Chambersachambers.home@googlemail.com wrote:
Am I correct in thinking that the groveller doesn't grovel for functions and automatically create the correct defcfun forms for a given library?
Yes. For that functionality there's Verrazano. http://common-lisp.net/project/fetter/
On Allegro the feature (pushnew 'no-long-long *features*) is always set.
The no-long-long feature is incredibly broken on 64-bit Linux, as it assumes that a long is 32-bits when it is actually 64-bits. This causes very hard crashes (Allegro's strange SIGEMT).
64-bit Allegro can handle long-longs. On Linux an long is a long-long, but on MS Windows a long is an int. Therefore we use the :nat and :unsigned-nat types which are consistently 64-bit.
Here is a patch to correct it; I think I munged the beautiful whitespace though (with my proportional width font it looks munged anyway . . .).
On Thu, Aug 20, 2009 at 3:34 AM, John Fremlinjf@msi.co.jp wrote:
The no-long-long feature is incredibly broken on 64-bit Linux, as it assumes that a long is 32-bits when it is actually 64-bits. This causes very hard crashes (Allegro's strange SIGEMT).
Yeah, the problem of course is that there is no free 64-bit version of Allegro so we can't support as well as we'd like. You should complain to them. :-)
Here is a patch to correct it; I think I munged the beautiful whitespace though (with my proportional width font it looks munged anyway . . .).
Applied. Thanks!
Luís Oliveira wrote:
On Thu, Aug 20, 2009 at 3:34 AM, John Fremlinjf@msi.co.jp wrote:
The no-long-long feature is incredibly broken on 64-bit Linux, as it assumes that a long is 32-bits when it is actually 64-bits. This causes very hard crashes (Allegro's strange SIGEMT).
Yeah, the problem of course is that there is no free 64-bit version of Allegro so we can't support as well as we'd like. You should complain to them. :-)
I would second that. They seem to have decided on their pricing policy in the old days when a 64-bit chip was a really big deal, and basically only used for very high-end workstations or for servers.
Now, on the other hand, you'd actually have to go out of your way to find a 32-bit machine to buy.
I think if we chip away at them they will eventually give up on their model of 64-bit as being worthy of a cost premium, and start to ship a Professional (and presumably a trial) that's 64-bit. But it will probably take a number of people complaining.
I know I made Duane Rettig wince when I said at ILC that we'd ported our system to SBCL to get a 64-bit version.
Best, r
Here is a patch to correct it; I think I munged the beautiful whitespace though (with my proportional width font it looks munged anyway . . .).
Applied. Thanks!
Luís Oliveira luismbo@gmail.com writes:
On Thu, Aug 20, 2009 at 3:34 AM, John Fremlinjf@msi.co.jp wrote:
The no-long-long feature is incredibly broken on 64-bit Linux, as it assumes that a long is 32-bits when it is actually 64-bits. This causes very hard crashes (Allegro's strange SIGEMT).
Yeah, the problem of course is that there is no free 64-bit version of Allegro so we can't support as well as we'd like. You should complain to them. :-)
Well, I would rather recommend that everyone use SBCL as it is more correct, has a modern compiler, supports threads, and bugs are actually fixed(!) in a few days, rather than for the next release (or not at all).
Here's one more patch to inline some common CFFI operations which makes things faster. I'm not sure if you want to apply this patch as it is obviously a little cunning and if you want speed you should probably be using SBCL anyway.
As you can see, programming with Allegro tends to involve lots of SPR (support request) numbers. :-(
(This views are my personal ones and do not reflect those of MSI.)
--- old-cffi/src/cffi-allegro.lisp 2009-09-10 16:48:13.000000000 +0900 +++ new-cffi/src/cffi-allegro.lisp 2009-09-10 16:48:13.000000000 +0900 @@ -87,15 +89,41 @@ "Return true if PTR1 and PTR2 point to the same address." (eql ptr1 ptr2))
-(defun null-pointer () +(defmacro defun-speedy (name lambda-list documentation &body body) + ;; this is a very cheesy inliner for a few simple cases + (check-type documentation string) + (assert body) + `(progn + (declaim (inline ,name)) ;; this is just nonsense as Allegro 8.1 cannot inline user functions :-( + (defun ,name ,lambda-list + ,documentation + (declare (optimize speed)) + ,@body) + (define-compiler-macro ,name ,lambda-list + `(progn + +;; AARRRGH -- yet another Allegro compiler bug if this useless progn +;; is omitted (spr36171) + +;; [The Allegro compiler has some insane ideas about how to do (setf +;; let) resulting in the wrong output from get-setf-expansion (in +;; compiled mode).] + + (let (,,@(loop + for n in lambda-list + collect ``(,',n ,,n))) + (declare (optimize speed)) + ,@',body))))) + +(defun-speedy null-pointer () "Return a null pointer." 0)
-(defun null-pointer-p (ptr) +(defun-speedy null-pointer-p (ptr) "Return true if PTR is a null pointer." (zerop ptr))
-(defun inc-pointer (ptr offset) +(defun-speedy inc-pointer (ptr offset) "Return a pointer pointing OFFSET bytes past PTR." (+ ptr offset))
@@ -136,7 +164,7 @@ (return-from with-foreign-pointer `(let ((,size-var ,size)) (declare (ignorable ,size-var)) - (ff:with-static-fobject (,var '(:array :char ,size) + (ff:with-static-fobject (,var '(:array :char ,(eval size)) :allocation :foreign-static-gc) ;; (excl::stack-allocated-p var) => T (let ((,var (ff:fslot-address ,var)))
[...]
-
Andy Chambers -
John Fremlin -
Luís Oliveira -
Robert Goldman