Re: [MIT-Scheme-devel] Faster ports.

[Taylor R Campbell]

   Date: Sat, 25 Jun 2011 13:42:31 -0700
   From: Matt Birkholz <address@hidden>

   >        (and (r 42) (r 43))                ; r42 <- address of bytes
   >         ^^^
   > ADD, surely?

   After shifting and masking them, I think of them as unsigned bits.  Do
   you mean "Use the ALU if you've already got the logic/shifter circuits
   engaged."?

Well, either ADD or IOR, but certainly not AND.

   > 1. The garbage collector needs to be able to relocate the address
   > fields, in case the frob is a vector-8b in the Scheme heap that moves
   > around.

   So slice-ref will use the two address fields regardless of buffer
   type?  That makes it as slow as external-string-ref EVERY time.  Our
   "near" type tags (should) make the cost of STRING? negligible...

I expect the cost of branching and cache effects to tremendously
outweigh the cost of a couple arithmetic instructions.

Note that I'm talking about a general slice abstraction here which
would be useful for a much broader range of applications than just I/O
buffers.  I want to kill all the SUBSTRING- variants of STRING-
procedures, and all the copying induced by not having SUBSTRING-
variants or by their being so painful to use, and the heavy overhead
implied by handling external strings at all.

   > 2. The garbage collector needs to know when it can release the frob if
   > it is an external string or similar, so there has to be a reference
   > for the sake of a GC finalizer in that case.

   I believe weak pairs is all you need.  I implemented this property for
   malloced aliens without special garbage collector support.

This property doesn't require special garbage collector support, but
it does require that each slice keep a reference to the object that it
is a slice of.