[Gcl-devel] Re: woe unto me: multiple value

[Camm Maguire]

Robert Boyer <address@hidden> writes:

> > Are you sure about this?
> 
> Am I sure about what?  No, is probably the answer in any
> case.
> 

:-)

> A very famous physicist wisely said something like "Every
> sentence I utter must be understood not as an affirmation,
> but as a question."
> 

Wonderful!  I wonder what, interpreting the above as a question,
we might conclude? :-)

> I'm not sure who said it to HUAC, but I wish I had: "I plead
> the first amendment".
> 
> Are there any simple little experiments you'd like me to try
> in cmucl, sbcl, allegro, abcl, or clisp?
> 

> >From the ANSI, concerning expressions like (the value-type form)
> 
>   results---the values resulting from the evaluation of form.
>   These values must CONFORM to the type supplied by value-type;              
> <= caps by me
>   see below.
> 
>   ...  somewhat below ...
> 
>   It is permissible for form to yield a different number of
>   values than are specified by value-type, provided that the
>   values for which types are declared are indeed of those
>   types.  Missing values are treated as nil for the purposes
>   of checking their types.
> 
>   Regardless of (sic) number of values declared by
>   value-type, the number of values returned by the special
>   form the is the same as the number of values returned by
>   form.

Thanks for this, but does this mean that proclaim ftype needs to
follow suit, or just 'the?

> 
> Can I say more than to give your the transcript below?
> (partially edited for brevity)
> 

To my understanding, GCL is the only lisp that makes measurable use of
proclaim ftype.  If we conclude that compiling the example below with
warnings currently present in (values x x) is not compliant, then we
will have to forgo every C style call GCL has ever made since the
beginning of time.  There is no way currently discernible to me to
support a function being able to change its mind at will on the number
of values returned without making all calls read from the lisp value
stack.

Actually, one idea just came to mind -- *perhaps* what at least the
other lisps view the standard as requiring is that all calls at any
multiple-value-binding location (end of function, end of 'or (not in
let, etc.), explicit mv binding form) must be written to explicitly
check the lisp value stack.  This sensible thing to do in this case
would be to always return the first value optimally (i.e. minimal C
stack writing), and neglect all lisp stack analysis in all other call
situations.

If this is the case, it still might be a good idea to provide some
means whereby the user could indicate to the compiler that said
function will always return the same number of values.  I suspect we
can likely use proclaim ftype for this even though none of the other
lisps appear to do so, but if not, we should use some other proclaim.


PPS.  It appears that some of the above is now moot.  Gcc can leave a
one value return in register, contradicting my earlier suspicions.
I'll try to extend the benchmark below to examine potential gains for
additional results soon:

=============================================================================
#include <stdio.h>
#include <sys/time.h>
#include <time.h>

int
foo(int x) {

  return x+x;

}

void
foo1(int x,int *y) {

  *y=x+x;

}

void 
test(int (*f)(int),void (*f1)(int,int *)) {

  struct timeval tv,tv1;
  int k,i,j[1000000];

  gettimeofday(&tv,NULL);
  for (k=0;k<1000;k++)
    for (i=0;i<1000000;i++)
      j[i]=f(i);
  gettimeofday(&tv1,NULL);
  printf("%f\n",(1000000.0*(tv1.tv_sec-tv.tv_sec)+(tv1.tv_usec-tv.tv_usec)));
  gettimeofday(&tv,NULL);
  for (k=0;k<1000;k++)
    for (i=0;i<1000000;i++)
      f1(i,j+i);
  gettimeofday(&tv1,NULL);
  printf("%f\n",(1000000.0*(tv1.tv_sec-tv.tv_sec)+(tv1.tv_usec-tv.tv_usec)));

}

int
main() {

  test(foo,foo1);

  return 0;

}
=============================================================================
cc -O3 tty1.c -o tty1
./tty1
6199322.000000
6928752.000000

Take care,

> 
> Bob
> 
> 
> % acl
> International Allegro CL Enterprise Edition
> CL-USER(1): (proclaim '(ftype (function (t) t) foo))
> (defun foo (x) (values-list x))
> (compile 'foo)
> (foo '(1 2 3 4 5))
> 
> T
> CL-USER(2): FOO
> CL-USER(3): FOO
> NIL
> NIL
> CL-USER(4): 1
> 2
> 3
> 4
> 5
> 
> % abcl
> Armed Bear Common Lisp 0.0.8 (built Sat Oct 15 2005 12:01:10 -0600)
> 
> CL-USER(1): (proclaim '(ftype (function (t) t) foo))
> (defun foo (x) (values-list x))
> (compile 'foo)
> (foo '(1 2 3 4 5))
> 
> NIL
> CL-USER(2): FOO
> CL-USER(3): FOO
> NIL
> NIL
> CL-USER(4): 1
> 2
> 3
> 4
> 5
> 
> % cmucl
> CMU Common Lisp 19b (19B), running on elgin.cs.utexas.edu
> 
> * (proclaim '(ftype (function (t) t) foo))
> (defun foo (x) (values-list x))
> (compile 'foo)
> (foo '(1 2 3 4 5))
> 
> FOO
> NIL
> NIL
> * 
> 1
> 2
> 3
> 4
> 5
> 
> % clisp
> Copyright (c) Sam Steingold, Bruno Haible 2001-2005
> 
> [1]> (proclaim '(ftype (function (t) t) foo))
> (defun foo (x) (values-list x))
> (compile 'foo)
> (foo '(1 2 3 4 5))
> 
> NIL
> [2]> FOO
> [3]> FOO ;
> NIL ;
> NIL
> [4]> 1 ;
> 2 ;
> 3 ;
> 4 ;
> 5
> [5]> Bye.
> % sbcl
> This is SBCL 0.9.8, an implementation of ANSI Common Lisp.
> 
> * (proclaim '(ftype (function (t) t) foo))
> (defun foo (x) (values-list x))
> (compile 'foo)
> (foo '(1 2 3 4 5))
> 
> 
> * 
> FOO
> * 
> FOO
> NIL
> NIL
> * 
> 1
> 2
> 3
> 4
> 5
> * 
> 
> 

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