Re: [MIT-Scheme-devel] string-head!

[Chris Hanson]

On Thu, Sep 24, 2009 at 7:57 AM, Joe Marshall <address@hidden> wrote:
> On Wed, Sep 23, 2009 at 11:21 PM, Taylor R Campbell <address@hidden> wrote:
>> Does the new definition of STRING-HEAD! work when building an x86-64
>> LIARC from an i386 LIAR, or is this worked around because those C
>> files are thrown out after they're used to build the real ones on the
>> target, and because nothing in the compiler (presumably) uses
>> STRING-HEAD! ?
>
> I don't know the answer, but I'm guessing that when you cross-compile
> from an i386 to an x86-64 that the C files are generated with the expectation
> that a 64-bit C compiler will compile them (whether cross compiled from
> i386 or native compiled on the target machine).

Taylor is right about this one.  The C files we generate have a broken
string-head!.  The second round of compilation fixes this.  If the
compiler were to use string-head! we'd be screwed.

>>  Also, why don't we just teach LIAR to open-code
>> SET-STRING-MAXIMUM-LENGTH! ?
>
> I can't imagine it is worth the effort and pain.  You don't want to build
> too much knowledge of object representation into the compiler unless
> you really need it.  Open coding would save the function call and some
> argument shuffling, but you'd still be doing the other work.

I'm inclined to agree, only because the definition of
set-string-maximum-length! is pretty random. and includes that code to
conditionally update the string's length and insert a nul.  But adding
an open-coder for just the part that clobbers the object header would
be simple.  If we also added the inverse -- a primitive that reads the
object header and converts the length to #octets, we could eliminate
that compile-time constant.  Then we could cross compile.

However, to make this work we'd need some changes to the RTL, which
will have a ripple effect.  That might or might not be hairy.