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.
Make sure that we don't miss anything and cover the rest of bytevector
accessors with tests for unaligned memory access. Include both integers
and floats, in little and big endian flavors.
Native code implementing bytevector accessors uses the following access
pattern:
*(intNN_t*)(base+offset)
This can result in so called "unaligned memory access" if the offset is
not a multiple of 2, 4, 8, or if the base address has not been allocated
at an aligned address (unlikely).
Most popular modern architectures--x86 and ARMs--allow unaligned memory
accesses on the instruction level but they are typically performed a bit
slower than properly aligned accesses.
On the other hand, there are architectures which do not allow unaligned
memory accesses. Each load or store of a value longer than 1 byte should
use properly aligned address on those architectures. That is, u16 should
be loaded from even addresses, s32 should only be stored at an address
which is a multiple of 4, and f64 (aka double) can be located only at
addresses which are multiple of 8. If the address is not aligned, CPU
raises an exception which typically results in the process being killed
by the operating system with a SIGBUS signal.
SPARC is one of those architectures which are strict with alignment. The
current access pattern in bytevector native code can result in unaligned
accesses, which in turn results in crashes. This issue has been found in
this way: Chibi test suite includes some tests for unaligned accesses
and it failed on SPARC.
In order to avoid unaligned accesses, loads and stores need to be
performed a bit differently, doing 'type punning' in a safe way, not
just casting pointers which breaks strict aliasing rules.
The most portable and efficient way to do this is to use memcpy().
Compilers know about this trick and generate very efficient code here,
avoiding the function call and using the most efficient instructions.
(Obviously, only when optimizations are enabled.)
That is, given
static inline uint32_t ref_u32(const void* p) {
uint32_t v;
memcpy(&v, p, sizeof(v));
return v;
}
on x86 this will be compiled into a single "movl" instruction because
x86 allows unaligned accesses, similar with ARM where this becomes
a single "ldr" instruction. However, on RISC-V--another platform with
strict alignment rules--this code compiles into 4 "lbu" instructions
fetching 4 bytes, then some more arithmetic to stitch those bytes into
a single 32-bit value.
