Skip to content

Conversation

@csrhodes
Copy link

@csrhodes csrhodes commented Jan 6, 2022

Hi!

The sb-nibbles contrib referred to here isn't yet in SBCL, and hasn't been discussed thoroughly, so please don't merge this PR yet!

The intent here (in the second commit) is to decouple the low-level implementation of nibbles functionality from the user-facing library, so that if SBCL chooses to change how it expresses its assembler (as has happened in the past), nibbles the library doesn't need to change; it probably makes it easier to support efficient accessors on other systems (e.g. 64-bit arm and power support unaligned accesses, I believe). The potential downside is that there's now a two-body problem; if nibbles one day wants to implement e.g. 128-bit accessors, it will need some cooperation with the sb-nibbles contrib. (The scheme I've chosen here is to test for symbol presence, and fall back to a generic implementation if it's not, so there's some hope for forward compatibility).

The first commit is a cosmetic fix, not of high importance (but I noticed it in the course of testing, so...). It is independent and could be merged as-is.

When optimizing, the array bounds check is performed with a single
comparison, jumping to an internal error if the check is violated.
Arrange that the error refers to an array index that is in fact out of
bounds.
If it is available, the corresponding package is present in the image
when compiling, so use that to conditionally compile legacy support or
support based on sb-nibbles as applicable.  The support based on the
new module simply transforms each nibbles vector accessor into the
corresponding sb-nibbles one.

Tested with SBCL with sb-nibbles, SBCL without sb-nibbles, and Clozure
Common Lisp (all x86-64).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant