Geir Tj|rhom <geirtj@...> writes:
> I wonder if I've come across a bug in the compiler for the Solaris/SPARC
> version of SBCL. Given the macro TEST below, the expression (TEST 1000)
> generates a type error from inside the code generator, but (TEST 500)
> works fine.
> I've tried it on SBCL 0.9.0 on Solaris. SBCL for x86 and PPC seem to
> handle the macro, but the time required to compile the expression rises
> rapidly with larger N values.
There is almost certainly an O(N^(1+\delta)) algorithm, if not more,
in the implementation of SBCL's compiler, which would explain growth
of compilation times in this way.
> Is the Solaris version being maintained, BTW? I've gotten the impression
> that almost all development takes place on the Linux/x86 version.
It is being maintained, in the sense that we check that it builds and
passes (most) tests; we occasionally release binary versions; and we
treat bug reports as bugs. Because available manpower is slight, I at
least tend to focus in development, as opposed to maintenance, on
things that either directly benefit me or are interesting; I would
imagine a similar attitude from most part-time SBCL maintainers.
(And, as an additional health warning, I should note that even bug
fixes aren't guaranteed in any sense from volunteers...)
So. In the meantime, what about the specifics? Well, you should note
at the very least that code of the form (test <largenum>) is not
portable, because of CALL-ARGUMENTS-LIMIT; although SBCL is, erm,
optimistic about how many arguments you can call a function with, in
general you shouldn't expect to be able to do more than (test 50).
Having said that, as best I can see, the bug lies in the definition of
the LIST VOP, or possibly in the :EXTRA argument to the PSEUDO-ATOMIC
macro. The problem is that the ADD instruction on the sparc takes
either a register or a sign-extended 13-bit quantity, so attempts to
allocate fixed amount of space taking more than 4100 (= 2^12 + 4, for
technical reasons) bytes will fail. So (test 512) will succeed, while
(test 513) will fail to compile with the same error that you've
To fix this, PSEUDO-ATOMIC probably needs to be extended to take a
temporary register argument in the case that the :EXTRA parameter is
supplied, so that the addition can be performed safely by loading the
extra quantity into a register if necessary.
I hope that helps somewhat,