Bytecode optimisation

[Martijn Faassen]

Markus Stenberg wrote:
> 
> Martijn Faassen <faassen at pop.vet.uu.nl> writes:
> ..snip..
> 
> > I think the tricky parts are adding the type info to Swallow parse tree
> > (along with the type info for lots of builtin stuff), and then turning
> > this tree into the C tree.
> 
> The later part at least, is definitely painful.

Yup. :)

> > Perhaps someone already has a python module that can generate C code
> > from some tree structure?
> 
> Python2C produces C from Python parse tree
> (http://lima.mudlib.org/~rassilon/p2c/).

I briefly glanced at it but it obviously deserves a second look.

> > Random note: I think we need a form of C++ templates or generic
> > classes/types in order to do enough of Swallow. For instance, we need a
> > list(integer) and list(float) and list(fooClass). Some system of generic
> > programming seems necessary here.
> 
> Hell no. You should use Python's internal list/dict at least in the first
> place, and C++ in general is evil. (Especially as rest of Python is C)

Whoops, I was not expressing myself well. I didn't mean the
implementation should be C++ -- though I get along with C++ usually it
seems to me too we should generate C code and not C++. If only for the
reason that C code is far more portable than C++ at the moment.

I meant that we should generate the right C code in the right place. For
instance, if we have the following Swallow type info: 

"mylist" : types.list(types.integer),

We need to generate a C list of integers (ideally an array), that can
deal with appending integers and such.

If we have this:

"mylist" : types.list(types.string)

We need to generate a C list of strings, however.

Some system (implemented in C) of generic programming would seem useful
here. Perhaps this is built on top of the Python implementation of these
things. But in general with classes we run into this problem when we
deal with collection classes. Swallow generally enforces all elements in
the collection to be of one single type (or all have the same base class
in the case of objects).

> > > It may be nescessary to keep two or more copies of a function around (if you
> > > want both speed and flexibility).. one optimized to flash powder in native
> > > code, one in the original python bytecode.
> > Yes, I had the same idea.
> 
> Or even 3 functions;
>         - internal C function (just used in C->C calls)
>         - external C function wrapper (to be callable from Python and to
>         return things in Pythonese fashion)
>         - pure Python function (original bytecode)

That'd be 2 'real' functions and one wrapper, right? Though yeah, it's 3
things.

Regards,

Martijn