Re: Compilation to native

[Matthew Mundell <matt@mundell.ukfsn.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >> > This optimisation more than doubles the speed of the generated
> >> > function.  The optimisation adds two new byte operations.  As a start
> >> > the new operations always take parameters that are four bytes wide.  I
> >> > think the loading of these four bytes is the cause of the slower byte
> >> > interpretation.
> >> I don't understand.  Could you give us more info about what those new byte
> >> ops are and what they're used for (and maybe why you think they make things
> >> slower in the byte-interpreter, tho I should be able to figure that out on
> >> my own at that point).
> > The optimisation moves variable referencing and setting out of loops.
>
> Feel free to use precise words like `varref' or `varset'.  We want/need
> technical details here.

Thanks.  varrefs and varsets are moved out of loops.

>
> > The Lisp objects are instead referenced onto the stack before the
> > loop, and set from the stack afterwards.  The new operations are used
>
> You mean you added two byteops: one to read the Nth word on the stack
> (counting from the top) and the other to set that word? I expect you
> called them something like `sset' and `sref'?

Yes.  They're called stkref and stkset.  stkref pushes a copy of the
Nth Lisp_Object from the top of the stack onto the top of the stack.
stkset sets the Nth Lisp_Object from the top of the stack.

> Sounds generally useful (something similar is used in the `lexical' branch
> of Miles, you might want to check that out).

I've been verging on checking out his branch, but have been putting
off learning arch, partly because the documentation is excluded from
Debian, mostly because it looks like it'll take a while.