gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: acl2-hons build in gcl 2.7.0 ok; regression running


From: Camm Maguire
Subject: [Gcl-devel] Re: acl2-hons build in gcl 2.7.0 ok; regression running
Date: 24 Jun 2006 18:24:41 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

Robert Boyer <address@hidden> writes:

> > Just curious what you might have expected to catch by this
> > -- at present a return type of '* and anything above t are
> > compiled identically.
> 
> That you would ask such a question shows just how dumb I am!
> 
> Normally, I run with safety=0, speed=3, for performance, but
> that is a good way to produce totally meaningless results
> like segmentation violations if Lisp code (including) the
> compiler is not right.
> 
> However, at safety=3, wrong number of arguments and many
> other things are very often caught.  It's just slow.  But
> it's why safety=3 exists and is so important, no?  For

Yes safety three will catch almost everything, or at least should.
But there is currently no comparison anywhere that actually returned
multiple values correspond to the proclaimed settings.  We may need
such as we try to accelerate mv.

Thus far, recompilation has been limited to load time of a binary
object.  We may also have to do it if/when the user does a defun or
(setf (symbol-function ...)) if we are to get the most mileage out of
mv, and of mutual recursion coincidentally.  I'm wondering if this is
a problem.  Might even be a bit better than at present, for if one
does (setf (symbol-function 'foo) (symbol-function 'bar)), and then
'bar  or 'foo are recompiled, the other will be too, but the two
functions will no longer be 'eq.  Wonder if this is a problem ....

Here is one idea for mv.  The compiler can convert

(defun foo (x) (values x x))

to 

(defun foo-int (a x)
        (setf (cdr a) x)
        x)

(defun foo (x)
        (let ((a (cons t t)));this can be made smaller, just a stack
                             ;  space opening
        (declare (:dynamtic-extent a))
        (let ((y (foo-int a x)))
        (values y (cdr a)))))

or even

(defun foo (x &key a) ;a would be a gensym
        (cond (a (setf (cdr a) x) x)
              (let ((a (cons t t)))
                (declare (:dynamic-extent a))
                (let ((y (foo x :a a)))
                        (values y (cdr a))))))

The efficiency of this approach is dependent on compiled functions
actually calling foo-int, or the second foo above with the key.  If
foo is then redefined with a defun, a recompile of callers to foo-int
must be made to make the call to foo instead, whereas the this might
not be necessary in the version with the &key above.  In this latter
case, however, it is unclear at present how to make the function call
itself optimal, as the first branch would have to return one value in
a register as is customary with fast-linking and one return type,
whereas the second branch would have to leave its values on the lisp
value stack to be consistent with the interpreter.  This might
actually be doable.

The same issue exists with mutual recursion -- do callers call a
wrapper with the normal number of arguments, or the internal state
function with one extra argument indicating the state?  And how is
this handled with function redefinition?

Suggestions/comments most welcome as always.

Take care,

> example, the "silly" bug I reported yesterday, was a case of
> a function, viz., fmt0, returning only 1 value when 2 were
> expected and this "might" have been caught at safety=3.  But
> perhaps I am only dreaming as usual.
> 
> Bob
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]