Shulou(Shulou.com)06/02 Report--

Today, I will talk to you about how to understand the Python running environment in the Python virtual machine, which may not be well understood by many people. In order to make you understand better, the editor has summarized the following contents for you. I hope you can get something from this article.

In fact, the Python running environment is an overall concept, and the execution environment is actually a stack frame, which is the corresponding concept of Code Block. There is an essential difference between the two. We can understand the difference between them in the course of later operation.

The initialization process of the runtime environment is very complex, which will be analyzed in a separate chapter. Assuming that the initialization has been completed, we have stood outside the threshold of the Python virtual machine. We only need to push the dominoes slightly, and the whole execution process is like dominoes, unfolding one by one.

What drives this domino is in a function called PyEval_EvalFramEx, which is actually a concrete implementation of Python's virtual machine, which is a very huge function, so we list the source code a little differently than before.

PyEval_EvalFrameEx first initializes some variables, in which the important information contained in the PyCodeObject object in the PyFrameObject object is taken into account. Of course, another important action is to initialize the stack top pointer to f-> f_stacktop:

[PyEval_EvalFrameEx in ceval.c] co = f-> faucode; names = co- > co_names; coconsts = co- > co_consts; ffastlocals = f-> faulocalsplus; ffreevars = f-> f_localsplus + co- > co_nlocals; first_instr = (unsigned char*) PyString_AS_STRING (co- > co_code); next_instr = first_instr + f-> f_lasti + 1; stack_pointer = f-> f_stacktop F-> f_stacktop = NULL; / * remains NULL unless yield suspends frame * /

As we said earlier, bytecode instructions and bytecode instructions are stored in the co_code domain of the PyCodeObject object. The process of executing the bytecode instruction sequence in the Python virtual machine is to traverse the entire co_code from beginning to end, and execute bytecode instructions in turn.

In the virtual machine of Python running environment, three variables are used to complete the whole traversal process. Co_code is actually a PyStringObject object, and the character array in it is what really makes sense. That is to say, the entire bytecode instruction sequence is actually an array of characters that are common in C. Therefore, the three variables used in the traversal are of type char*: first_instr always points to the beginning of the bytecode instruction sequence.

Next_instr always points to the location of the next bytecode instruction to be executed; f_lasti points to the location of the previous bytecode instruction that has already been executed. Shows what happens at some point in the traversal of these three variables:

[ceval.c] / * Interpreter main loop * / PyObject* PyEval_EvalFrameEx (PyFrameObject * f, int throwflag) {. Why = WHY_NOT;. For (;) {. Fast_next_opcode: F-> f_lasti = INSTR_OFFSET (); / / get the bytecode instruction opcode = NEXTOP (); oparg = 0; / / if the instruction requires parameters, get the instruction parameter if (HAS_ARG (opcode)) oparg = NEXTARG () Dispatch_opcode: switch (opcode) {case NOP: goto fast_next_opcode; case LOAD_FAST:. }}

So how is this step-by-step action accomplished? let's take a look at the overall architecture of the Python runtime environment for executing bytecode instructions, which is actually a for loop plus a huge switch/case structure. Friends who are familiar with Windows SDK programming can imagine the huge message loop under Windows, just like that. In the analysis of the PyCodeObject object, we have said that the bytecode of Python is either parameterized or unparameterized, and the HAS_ARG is used to determine whether the bytecode is parameterized or not.

Note that the displacement of next_instr may be different for different bytecode instructions because there is a difference in whether instruction parameters are required or not. But in any case, next_instr always points to the next bytecode to be executed by Python, much like the PC register on x86 platforms.

After obtaining a bytecode instruction and its required instruction parameters, Python will use switch to judge the bytecode instruction and select different case statements according to the result of the judgment, and each bytecode instruction will correspond to a case statement. In the case statement, it is Python's implementation of bytecode instructions.

After the successful execution of a bytecode instruction, the execution flow of the Python runtime environment jumps to fast_next_opcode or for loop. In any case, the next action of Python is to obtain the next bytecode instruction and instruction parameters to complete the execution of the next instruction. In this way, we traverse all the bytecode instructions contained in co_code one by one, and finally complete the execution of the Python program.

After reading the above, do you have any further understanding of how to understand the Python runtime environment in the Python virtual machine? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.