Debugging confusion -- too many stacks!

[Michael Hudson]

Christian Tismer <tismer at tismer.com> writes:

> Hey, we forgot about a stack :-))
> 
> Michael Hudson wrote:
> > 
> > Christian Tismer <tismer at tismer.com> writes:
> > 
> > > This VM stack could also be replaced by a set of registers, since
> > > the maximum stack size is always known at compile time.
> > 
> > My gut tells me that making this work with exceptions would be a dog.
> 
> I don't think so. Exception handlers have their own little stack
> in each frame. It is currently fixed to 20 items, wasting quite
> a lot of space most of the time (and this will vanish in
> Stackless "Heresy" 1.2), but it won't cause problems with a
> register machine.

Hmm.  You still need a evalutaion stack though, don't you?  I mean,
implementing function call without would one mean a pretty radical
change to the interpreter.

> > It's the sort of thing that might be fun to play with if the compiler
> > and eval loop were written in Python, but if I have to hack C to play
> > with these things, it just becomes tedious.  Still, maybe if I have a
> > month or two with nothing else to do...
> 
> A while ago, I considered this, too. Meanwhile I don't, since
> it doesn't bear a very reasonable speed gain. The win would be
> to have less of the tiny operations occouring all the time,
> and to have less of stack pointer operations. But when looking
> closer to it, you will find that the most slowdown lies in
> the outmost interpreter loop, which checks for periodic things
> for every opcode, regardless wether it is very fast or a slow
> function call.
> In Stackless Python, I have stolen these cycles already. The eval
> loop has some internal shortcuts to avoid this many checks. The fast
> opcodes are all running as fast as possible, avoiding these
> checks. One could still save some jumps and some assignments,
> but this is not enough to justify the lots of changes that a
> register implementation would impose to other modules.

Oh right.  I haven't looked at stackless python's ceval.c for a while.
A register machine might be a bit more elegant, but not much, I
suspect.

> It can still make sense to provide a hand-full of combined
> opcodes which have high frequency. jump_if_true combined
> with pop_top for instance, or some load/store combinations.
> If you have a proposal, and if you will support them through
> the bytecodehacks, I'd be happy to add them to Stackless Heresy.

Another thing that would make sense is typed bytecodes and typed
registers or a typed stack.  So if you can prove a and b are integers,
say, then you can stick a,b in registers 1,2 and compile

 a = a + b

into 

 IBINARY_ADD 1 2 1

Another observation: all the bytecodes currently understood by the
Python VM have length 1 or 3.  There's no hard limit though;
IBINARY_ADD above would have to be at least four bytes long.  Further,
there's no reason you can't embed chunks of another bytecode in the
midsts of the one the Python VM understands, such as one that operates
on typed registers.  Then you use bytecodehacks to pick functions
apart, do some cfa and dfa to find which variables are floats or ints
and generate typed bytecode for operations on them.

I did some of the above once, then it became apparent that the flow
analysis was far too hard for me.  I might give it another whack
sometime...

Cheers,
M.

-- 
well, take it from an old hand: the only reason it would be easier
to program in C is that you can't easily express complex  problems
in C, so you don't.                 -- Erik Naggum, comp.lang.lisp