On Thu, Sep 24, 2009 at 7:57 AM, Joe Marshall <jmarsh...@alum.mit.edu> wrote: > On Wed, Sep 23, 2009 at 11:21 PM, Taylor R Campbell <campb...@mumble.net> > 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. _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-devel