An idea that's been batted about a bit lately is that our op-bloat is
at least partly caused by all the constant-argument variant forms all
of our ops need to support.
To address this, the constant_unfolding branch adds a step to IMCC
instruction selection to check for non-const variants of an
as-
Part of the purpose of my GSoC project is to develop tools to make
writing PAST::Optimizations not just possible, but actually
convenient.
There are existing special tools for tree transformations: for
example, the TGE or Tree Grammar Engine.
TGE provides a syntax for transformations on trees. To
On Sun, May 30, 2010 at 12:52:42AM -0700, Peter Lobsinger wrote:
> On Sun, May 30, 2010 at 12:01 AM, Stefan O'Rear wrote:
> > On Sat, May 29, 2010 at 11:38:58PM -0700, Peter Lobsinger wrote:
> >> 3) Have a separate ops table for every bytecode segment, switch tables
> >
> > 3a) The core ops become
On Sun, May 30, 2010 at 12:01 AM, Stefan O'Rear wrote:
> On Sat, May 29, 2010 at 11:38:58PM -0700, Peter Lobsinger wrote:
>> 3) Have a separate ops table for every bytecode segment, switch tables
>
> 3a) The core ops become merely a preloaded dynop table. Since you only
> pay for the ops you use
On Sat, May 29, 2010 at 11:38:58PM -0700, Peter Lobsinger wrote:
> 3) Have a separate ops table for every bytecode segment, switch tables
3a) The core ops become merely a preloaded dynop table. Since you only
pay for the ops you use (and a dispatch pointer is the same size as a
single opcode_t),
