[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: data-crunching in guile
From: |
Neil Jerram |
Subject: |
Re: data-crunching in guile |
Date: |
Thu, 25 Jun 2009 08:26:32 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) |
Andy Wingo <address@hidden> 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
Re: data-crunching in guile, Andy Wingo, 2009/06/26