This commit should reduce the amount of iterations in concatenate to N
where N is the sum of the lengths of the input lists.
The previous implementation iterated from the beginning in each
concatenation because of `last-pair`.
This implementation is significantly faster in this extreme case:
(concatenate! `(,(iota 50000) ,@(map list (iota 500))))
>> Previous implementation:
real 0m0.671s
user 0m0.658s
sys 0m0.013s
>> This implementation:
real 0m0.175s
user 0m0.174s
sys 0m0.001s
The tests is done using `time`, which is not reliable at all, but using
`(trace last-pair)` shows accurately what happens with the iterations.
lib/srfi/231/base.scm:
1. Add argument checks for index-first, index-last, index-rotate, and index-swap.
lib/srfi/231/test.sld:
1. 1,$s/179/231/g (in vim notation)
2. Add tests for index-first, index-last, index-rotate, and index-swap.
3. Remove trailing spaces.
Makefile:
When installing chibi, make installation directory and install files for SRFI 231.
When uninstalling chibi, remove installation directory and files for SRFI 231.
lib/srfi/231/transforms.scm:
Move definition of vector-iota from here to ...
lib/srfi/231/base.scm:
Here.
lib/srfi/231/base.sld:
Export vector-iota to use in both base.scm and transforms.scm.
SRFI-144 requires that (flmin) returns +inf.0 and that
(flmax) returns -inf.0, so these procedures can't really
be aliases to the Chibi implementation of R7RS max and min.
This restores third-party (ab)users of the Chibi macro system such
as in https://gist.github.com/baguette/2632464, while allowing us
to break those uses in more interesting ways.
It also keeps the core slightly smaller (both in C and Scheme)
and speeds up the macro expansion process.
C standard defines signbit() as a macro returning "non-zero value" for
negative arguments (see 7.12.3.6 of C11 standard). SRFI 144's flsign-bit
is defined to return exactly 1.
Make sure to convert the result of signbit() call into "boolean int"
which is either 0 or 1.
This is not a theoretical issue. This causes SRFI 144 test suite to fail
on many architectures that are not x86_64.
GCC on x86_64 compiles signbit() as
movmskpd %xmm0, %eax
andl $1, %eax
which indeed returns either 0 or 1. movmskpd extracts 2-bit sign mask
from the FP value in src register and stores that in low-order bits of
the dst register. Then the unneded extra bit is masked out, leaving only
the lowest bit set or unset.
However, other architectures don't have such conveniences and go with
more direct approach. For example, GCC on ARMv7 produces this:
sub sp, sp, #8
vstr.64 d0, [sp]
ldr r0, [sp, #4]
and r0, r0, #0x80000000
add sp, sp, #8
bx lr
which effectively returns either 0 or -1. Generated code masks out
everything but the sign bit and returns the result as is. The value
0x80000000 is the representation of -1.
Even on i386 signbit() is compiled as
fldl 4(%esp)
fxam
fnstsw %ax
fstp %st(0)
andl $512, %eax
ret
which effectively returns either 0 or 512: fxam sets C1 bit FPU status
word to the sign of FP value, then the status word is extracted, the
"sign bit" is masked out, and left as is.
