On Jul 17, 11:39 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> On 18 Jul., 01:15, castironpi <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Jul 17, 5:37 pm, I V <[EMAIL PROTECTED]> wrote:
>
> > > On Thu, 17 Jul 2008 15:08:17 -0700, castironpi wrote:
> > > > The Python disassembly is baffling though.
>
> > > >>>> y= 3
> > > >>>> dis.dis('x=y+1')
>
> > > You can't disassemble strings of python source (well, you can, but, as
> > > you've seen, the results are not meaningful). You need to compile the
> > > source first:
>
> > > >>> code = compile('y=x+1','-', 'single')
> > > >>> dis.dis(code)
>
> > > 1 0 LOAD_NAME 0 (x)
> > > 3 LOAD_CONST 0 (1)
> > > 6 BINARY_ADD
> > > 7 STORE_NAME 1 (y)
> > > 10 LOAD_CONST 1 (None)
> > > 13 RETURN_VALUE
>
> > > You may well find these byte codes more meaningful. Note that there is a
> > > list of opcodes athttp://docs.python.org/lib/bytecodes.html
>
> > Oh. How is the stack represented?
>
> As a pointer to a pointer of PyObject structs.
>
> > Does it keep track of which stack
> > positions (TOS, TOS1, etc.) are in what registers? Does stack
> > manipulation consume processor cycles?
>
> Python does not store values in registers. It stores locals in arrays
> and accesses them by position ( you can see the positional index in
> the disassembly right after the opcode name ) and globals / object
> attributes in dicts.
>
> For more information you might just download the source distribution
> and look for src/Python/ceval.c. This file contains the main
> interpreter loop.
Oh. I was interpreting, no pun, that the column of numbers to the
left indicated how many processor cycles were consumed in each
operation. It doesn't quite make sense, unless BINARY_ADD can refer
to memory outside of the registers, which I doubt on the basis that
two addresses would have to fit into a single operation, plus the
architecture opcode. Given that, what does that column indicate?
I'm intimidated by the source but I may look.
--
http://mail.python.org/mailman/listinfo/python-list
