Andy Wingo <wi...@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
