[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: indirect threading for bytecode interpreter

From: Helmut Eller
Subject: Re: indirect threading for bytecode interpreter
Date: Fri, 18 Sep 2009 00:48:13 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

* Tom Tromey [2009-09-17 23:06+0200] writes:

>>>>>> "Helmut" == Helmut Eller <address@hidden> writes:
> Helmut> 5% doesn't sound like a lot to some people.
> Shrug.  Obviously I think the tradeoff is worth it, or I would not have
> sent the patch.  I don't think the result is all that ugly.  And,
> importantly, it is very low-hanging fruit.

I just expressed my opinion.  I'm not the one to decide those issues.

> Helmut> vmgen sounds like a good idea, but I fear that it makes the build
> Helmut> process quite a bit more complicated.
> You can check in the generated code.

vmgen generates quite a few files, though.

> vmgen is a nice idea.  I rejected writing this as a direct-threaded
> interpreter because I assumed that the added memory use would be a bad
> tradeoff.  But, if you are interested in that, perhaps I could take a
> stab at it.

Yes, sounds a bit expensive memory-wise.  Especially on 64-bit machines.

> Helmut> I'm wondering why gcc can't perform this transformation from the
> Helmut> switch based code.  Is there no compiler setting to skip the
> Helmut> range check in the switch statement?
> It isn't about range checking but about eliminating a jump during the
> dispatch.

You mean the shared NEXT vs. copied NEXT issue.  Agreed, gcc can't
figure that out easily.


reply via email to

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