Re: data-crunching in guile

[Neil Jerram <neil@ossau.uklinux.net>]

Andy Wingo <wingo@pobox.com> writes:

> Hey all,
>
> I'm pretty displeased about the way that the brainfuck compilation
> works. Check this:
>
>     brainfuck@(guile-user)> ,c ++]
>
> (The trailing ] is to note the end of the program. It's kindof a hack,
> but it works fine.)

Yes, seems OK.  Presumably in real brainfuck end of program is
indicated by EOF?

> What I'm getting at is that I think we should have VM ops for working on
> vectors -- both generic vectors, and specific ops for bytevectors, and
> probably an op for string-ref as well, and possibly string-set!. Then a
> native code backend could be effectively implemented to operate on the
> GLIL or assembly level, relying on the Tree-IL compiler's previous
> resolution of high-level operations (i.e., vector-set!) to low-level
> instructions. I think we have the space in the VM, and if we group all
> of the vector instructions at the end, we shouldn't affect the
> instruction cache too much.
>
> So that's my plan. Thoughts?

Sounds good to me.  Perhaps the generic operation could be ref or set
at a fixed offset of an object's SMOB data?

However I don't yet understand the possible downside - i.e. what you
say about space and the instruction cache.

     Neil