[Top][All Lists]

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

[Axiom-developer] [#49 GCL argument list too long] additional informatio

From: anonymous
Subject: [Axiom-developer] [#49 GCL argument list too long] additional information
Date: Mon, 24 Jan 2005 21:05:46 -0600

> Camm,
> Kostas has found a problem on the solaris 9 platform. The argument list
> given has 154 items.

Yes, and I believe the reason is that his build loaded the
...NAG..chapter function interpreted, as opposed to compiled
(i.e. util.lisp not util.o) as I noted in a earlier post.
Fortunately, GCL's inliner expanded the apply therein and place all
args on the lisp value stack (as opposed to the limited C stack), thus
circumventing the argument limitation.  I've also posted two versions
which avert the problem at the lisp source level, which is preferable,
as the inliner depends on compilation safety options, etc.  Please let
me know if those functions don't fix the problem.  I still don't know
why Kostas' build loaded util.lisp interpreted.

> There used to be a similar problem in AKCL. Do you know what the
> current arg limits are and whether they can be changed?

63, and yes.  In fact, it can be made to be unlimited via libffi (if
memory serves).  We discussed this before, and it was deemed of lower
priority.  Please let me know if we now feel otherwise.  Expanding the
existing code further, which has a huge switch/case branch on the
argument number, would not seem advisable, though of course could be
done.  We could even generate the switch at configure time and put in
another configure options, but there are already too many of these

> Kostas,
> Try loading the function interpreted. There are two possible ways to
> do this. Either start the image and load the file "util.lisp" (rather
> than "util.o"). Or move the function into the file "nocompil.lisp"
> which contains functions which are never compiled. 

In this case, I believe, the advise should go the other way around.
compiling the function and load it would/should be an immediate
workaround, though this is just fortuitous in this case.

> As I recall, the interpreter can handle very long argument lists but
> the compiler cannot.

Calling apply from the interpreter will be limited, and calling any C
function with more that 63 args will trigger this error too.  As we
see here, this can come from either the interpreter or compiler
depending on the inlining performed.  The best solution is to avoid
the situation at the lisp level, which should be straightforward.
Even that JoinInner in nocompil.lisp could be written to take a single
list as an arg, I think, but we shouldn't fool with this at the

forwarded from

reply via email to

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