must be stored in a vector. The number of these vectors (i.e. the "lexical
level") was not properly computed: sample bogus code
(funcall
(compile nil
'(lambda (b)
(labels ((%f8 nil -39011))
(flet ((%f4 (f4-1 f4-2 &optional (f4-3 (%f8)) (f4-4 b))
(%f8)))
(%f4 -260093 -75538 -501684 (let ((v9 (%f8))) -3))))))
and closure environments did not work. Example of failed code
(funcall
(compile nil
'(lambda (a b c)
(labels ((%f6 (f6-1 f6-2) c))
(multiple-value-call #'%f6 (values a c)))))
0 10 20)
LAMBDA-PARAMETERS-LIMIT are both 64. Up to C-ARGUMENTS-LIMIT may be
passed to a function using C calling conventions. If the function is
to retrieve more arguments, (for instance through a &rest variable),
this can be done, but then the arguments have to be pushed on the lisp
stack. This method allows us to raise the CALL-ARGUMENTS-LIMIT up to
MOST-POSITIVE-FIXNUM. From a users point of view, there is no visible
change, excep the fact that a function may receive more arguments.
The function apply() has been replaced with cl_apply_from_stack().
The former took a pointer to the list of arguments. The latter assumes
that the last "narg" elements on the lisp stack are the arguments of
the function.
growth of the stack and in the way va_arg() arguments can be accessed.
Fix the bytecodes compiler so that it handles toplevel forms properly and
so that it understands LOCALLY.
Split configure.in into configure.in+aclocal.m4 and improve the resulting
tests.
at the top level, it processes their bodies as top level forms as well. For
instance, (LOCALLY (EVAL-WHEN (:COMPILE-TOPLEVEL) (PRINT "HELLO"))), now works.
