Re: gvector question

On Thu, 11 Aug 2005, bryan o'connor wrote:

> are there any length operations or bounds-checking for
> gvectors?

SVREF ordinarily does full type and bounds checking, but
it only works on objects of type SIMPLE-VECTOR.

CCL::%SVREF works on any GVECTOR, but does no type or
bounds checking.  (It's implemented as SVREF with
(declare (optimize (SPEED 3) (SAFETY 0))) in effect.)

CCL:UVREF works on any GVECTOR or IVECTOR and does
bounds checking; it's basically a huge TYPECASE, so
there is some extra overhead involved.

There's also something called CCL::%TYPED-MISC-REF:

(ccl::%typed-misc-ref :struct x 3)

will ensure that X is tagged as a STRUCT (typecode =
target::subtag-struct) and do bounds-checking under
default optimize settings.  (This may only work at
all - or at least only works the way I'm describing -
in compiled code when the type keyword is constant
and known to the backend.)  It might make sense to
ensure that the function exists and behaves like
the compiler primitive, just for completeness.

All of these things (except for UVREF) are open-coded,
and any type- or bounds-checking is usually just 2 or
3 additional instructions.

CCL::%SVREF is probably overused; when a lot of code
was written, UVREF was even slower and there wasn't
anything in between (SVREF probably involved a fairly
slow function call.)


>
> ccl::sd-slots returns a bogus object if the structure was
> defined with no slots.  (svref is referencing one element
> past the end)
>
> putting aside the question why one would ever want a
> structure with no slots.. any suggestions on which way to
> fix it?
>
> given (defstruct foo):
>
> - (make-foo) --> (gvector :struct '(foo) 'some-symbol-meaning-no-slots)
>  as long as that symbol would never be used as a slot
>  value for structures with slots.  check for symbol
>  in sd-slots.
>
> - (make-foo) --> (gvector :struct '(foo) num-slots)
>  where num-slots, in this case, is 0.

Structure instances just contain a list of the names of the structure
classes on the structure classes' CPL, followed by 0 or more other
slots.  SD-SLOTS should be looking at a "structure definition" object
- which contains stuff that's conceptually similar to what CLASS-SLOT
of the structure class should contain.  I think that a "structure
definition" is just a SIMPLE-VECTOR, so all of the accessor macros
could use SVREF instead of CCL::%SVREF; I think that these things
are only used for introspection, so a few extra cycles for improved
safety/sanity checking sounds like it'd be a good tradeoff.

I may be confused about something, but it sounds like either the
structure definition for the class is bogus in the no slots case or
something else is going on; I don't think that this needs to affect
how structure instances are created.

If FOO is the name of a structure class, then

(gethash 'foo ccl::%defstructs%)

will return the structure definition for that class.  At first
glance, the SD for s structure class with no slots doesn't look
grossly different than the definition for a class with slots;
perhaps SD-SLOTS is being used (incorrectly) on a structure
instance, and the issue is whether we quietly get something
irrelevant or noisily get something bogus ?

I don't think that we're getting much benefit from having
the SD- accessors be unsafe, and making them use SVREF
instead of CCL::%SVREF should catch anything like that
a little earlier.

>
> the latter would increase the size of all structs, the
> former just for structs with no slots.  the former also
> affects the least amount of code.  i'm not sure what one
> would use as that symbol, though.
>
>    ...bryan
>
> _______________________________________________
> Bug-openmcl mailing list
> [email protected]
> http://clozure.com/mailman/listinfo/bug-openmcl
>
>