Re: big strings

>>>>> "WP" == Walter C Pelissero <[email protected]> writes:

    WP> I suppose one could compare the generated code (disassembling it) and
    WP> see if there is any degradation.

Some further investigation indicates that max-bits really can be
#xffffffff.  And the word-offset deftype is wrong.  AFAICT,
word-offset really is the word-offset (32-bit words) of a particular
bit.  So the type is more like (integer 0 (2^32/32)).

I briefly looked at the disassembly for both functions.  There are
only 20 differences and they seem minor.  I think the difference is
because the offsets don't fit in a fixnum anymore.

    WP> Wouldn't a 32-bit integer be too big to fit in a "simple" Lisp object
    WP> thus requiring a further indirection?

That is correct.  But bit-bash-copy carefully declares things so that
the compiler knows the bit offsets will remain a 32-bit unsigned
object, and hence no consing is needed.  (I think.  The disassembly
doesn't show any more consing than the previous version.)

I've done a few more tests (ansi-tests) and it seems ok.  Using your
test-string-stream (but with only 15 iterations instead of 17) for
timing, both versions have the same execution times.

I think bit-bash-copy still has some issues since it won't be able to
copy every possible object, but that should only be a problem with
really big heaps and objects.

I'll check this in very shortly.

Thanks,

Ray