guile-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]