Разобрать по составу понимал: «Понимать» корень слова и разбор по составу слова понимание

 c. co_consts 
 # вывод: (1, 2, <объект кода f в 0x00000218C2E758A0, файл "", строка 3>, 'f', 4, None) c.co_names 
 # Вывод: ('a', 'b' , 'f', 'print') 

В первой строке (смещения 0 и 2) константа 1 сначала помещается в стек оценки глобального кадра с использованием LOAD_CONST 0 . Затем STORE_NAME 0 открывает его и сохраняет в объекте.

Во второй строке константа 2 помещается в стек с использованием LOAD_CONST 1 .Однако для присвоения этой ссылки используется другое имя операции. Инструкция

  STORE_GLOBAL   namei  

выталкивает верхнюю часть стека и сохраняет ее в объекте, ссылка на который хранится в co_names [namei] . Таким образом, 2 хранится в объекте, на который ссылается b . Это считается глобальной переменной. Но почему эта инструкция не использовалась для и ? Причина в том, что a - это глобальная переменная внутри функции f . Если переменная определена в области модуля и никакие функции не обращаются к ней, она будет сохранена и загружена с использованием STORE_NAME и LOAD_NAME . В области видимости модуля нет различия между глобальными и локальными переменными.

В третьей строке определена функция f . Тело функции компилируется в отдельный объект кода с именем <объект кода f в 0x00000218C2E758A0, файл "", строка 3> и помещается в стек. Затем строковый объект, который является именем этой функции 'f' , помещается в стек (фактически, ссылки на них помещаются).Инструкция

  MAKE_FUNCTION   argc  

используется для создания функции. Ему нужны некоторые параметры, которые следует поместить в стек. Имя функции должно быть вверху стека, а объект кода функции - под ним. В этом примере его oparg равен нулю, но он может иметь другие значения. Например, если определение функции имело аргумент ключевого слова, например:

 def f (x = 5): 
 global b 
 b = 3 
 y = x + 1 
 return y 

Тогда дизассемблированный байт-код для строки 2 будет :

 2 4 LOAD_CONST 5 ((5,)) 
 6 LOAD_CONST 1 (<объект кода f в 0x00000218C2E75AE0, файл "", строка 2>) 
 8 LOAD_CONST 2 ('f') 
 10 MAKE_FUNCTION 1 

oparg из 1 для MAKE_FUNCTION указывает, что функция имеет некоторые аргументы ключевого слова, и кортеж, содержащий значения по умолчанию, должен быть помещен в стек перед объектом кода функции (здесь это (5,) ). После создания функции MAKE_FUNCTION помещает новый объект функции в стек. Затем по смещению 14 STORE_NAME 2 выталкивает объект функции и сохраняет его как объект функции, на который ссылается f .

Теперь давайте заглянем внутрь объекта кода f (x) , который начинается со строки 5. Оператор global a не преобразуется в отдельную инструкцию в байт-коде. Это только указывает компилятору, что и следует рассматривать как глобальную переменную.Таким образом, STORE_GLOBAL 0 будет использоваться для изменения его значения. Инструкция

  LOAD_GLOBAL   namei  

помещает ссылку на объект, на который указывает co_names [namei] , в стек. Затем он сохраняется в b с использованием STORE_GLOBAL 0 . Инструкция

  LOAD_FAST   var_num  

помещает в стек ссылку на объект, ссылка на который составляет co_varnames [var_num] . В объекте кода функции f атрибут co_varnames содержит:

 ('x', 'y') 

Итак, LOAD_FAST 0 помещает в стек x . Затем 1 помещается в стек. BINARY_ADD извлекает x и 1 , складывает их вместе и помещает результат в стек. Инструкция

  STORE_FAST   var_num  

выталкивает верхнюю часть стека и сохраняет ее в объекте, ссылка на который хранится в co_varnames [var_num] .Итак, STORE_FAST 1 выводит результат и сохраняет его в объекте, ссылка на который составляет y . LOAD_FAST и STORE_FAST используются с локальными переменными функций. Таким образом, они не используются в области модуля. С другой стороны, LOAD_GLOBAL и STORE_GLOBAL используются для глобальных переменных, доступ к которым осуществляется внутри функций. Наконец, LOAD_FAST 1 поместит значение y на вершину стека, а RETURN_VALUE вернет его вызывающей стороне функции, которая является модулем.

а как вызывается эта функция? Если вы посмотрите на байт-код строки 8, сначала LOAD_NAME 2 помещает в стек объект функции, ссылка на который f . LOAD_CONST 4 помещает свой аргумент ( 4 ) в стек. Инструкция

  CALL_FUNCTION   argc  

вызывает вызываемый объект с позиционными аргументами. Его oparg, argc указывает количество позиционных аргументов.Вверху стека находятся позиционные аргументы, причем крайний правый аргумент находится наверху. Ниже аргументов находится вызываемый объект функции.

CALL_FUNCTION сначала извлекает из стека все аргументы и вызываемый объект. Затем он выделит новый фрейм в стеке вызовов, заполнит локальные переменные для вызова функции и выполнит байт-код функции внутри этого фрейма. Как только это будет сделано, кадр будет извлечен из стека вызовов, а в предыдущем кадре возвращаемое значение функции будет помещено поверх стека оценки. Если предыдущего кадра нет, он будет помещен в стек оценки глобального кадра.

В нашем примере у нас только один позиционный аргумент, поэтому инструкция будет иметь вид CALL_FUNCTION 1 . После этого инструкция

  POP_TOP  

помещает элемент на вершину стека. Это потому, что нам больше не нужно возвращаемое значение функции. На рисунке 2 показаны все операции с байт-кодом со смещениями от 16 до 22. Команды байт-кода внутри f (x) показаны красным.

Встроенные функции

В строке 9 дизассемблированного байт-кода листинга 2 мы хотим напечатать (a) . print также является функцией, но это встроенная функция Python. Имя функции - это ссылка на вызываемый объект. Итак, сначала он помещается в стек, а затем передается его аргумент. Наконец, он будет вызываться с использованием CALL_FUNCTION . print вернет None , и после этого возвращенное значение будет извлечено из стека.

Python использует свои встроенные функции для создания структур данных. Например, следующая строка:

 a = [1,2,3] 

будет преобразована в:

 1 0 LOAD_CONST 0 (1) 
 2 LOAD_CONST 1 (2) 
 4 LOAD_CONST 2 (3) 
 6 BUILD_LIST 3 
 8 STORE_NAME 0 (a) 

Первоначально каждый элемент списка помещается в стек. Затем вызывается инструкция

  BUILD_LIST   count  

для создания списка с использованием count элементов из стека и помещает полученный объект списка в стек.Наконец, объект в стеке будет извлечен и сохранен в куче, и a будет его ссылкой.

EXTENDED_ARG

Как упоминалось ранее, некоторые инструкции могут иметь аргумент, слишком большой, чтобы поместиться в один байт по умолчанию, и они будут иметь префикс инструкции EXTENDED_ARG . Вот пример. Предположим, мы хотим напечатать 260 * символов. Мы могли бы просто написать print ('*' * 260) . Однако вместо этого я напишу что-нибудь необычное:

 s = 'print (' + '"*",' * 260 + ')' 
 c = compile (s, "", "exec") 
 disassemble (c) 

Здесь s содержит функцию print , которая принимает 260 аргументов, каждый из которых является символом * .Теперь посмотрите на получившийся дизассемблированный байт-код:

 1 0 LOAD_NAME 0 (печать) 
 2 LOAD_CONST 0 ('*') 
 4 LOAD_CONST 0 ('*') 
. . 
. . 
. . 518 LOAD_CONST 0 ('*') 
 520 LOAD_CONST 0 ('*') 
 522 EXTENDED_ARG 1 
 524 CALL_FUNCTION 260 
 526 POP_TOP 
 528 LOAD_CONST 1 (None) 
 530 RETURN_VALUE 

сначала помещается в стек

. .Затем передаются его 260 аргументов. Затем CALL_FUNCTION должен вызвать функцию. Но ему нужно количество аргументов (целевой функции) в качестве аргумента. Здесь это число 260, что больше максимального числа, которое может занимать байт. Помните, что oparg - это только один байт. Таким образом, CALL_FUNCTION имеет префикс EXTENDED_ARG . Фактический байт-код:

 522 EXTENDED_ARG 1 
 524 CALL_FUNCTION 4 

Как упоминалось ранее, аргумент EXTENDED_ARG будет сдвинут влево на восемь битов или просто умножен на 256 и добавлен к оператору следующего кода операции.Таким образом, oparg CALL_FUNCTION будет интерпретироваться как 256 + 4 = 260 (обратите внимание, что то, что показывает функция disassemble , - это интерпретированный oparg, а не фактический oparg в байт-коде).

Условные операторы и переходы

Рассмотрим следующий исходный код с оператором if-else :

 s = '' 'a = 1 
 if a> = 0: 
 b = a 
 else: 
 b = -a 
 '' '
 c = compile (s, "", "exec") 
 disassemble (c) 

Дизассемблированный байт-код:

 1 0 LOAD_CONST 0 (1) 
 2 STORE_NAME 0 (a) 
 2 4 LOAD_NAME 0 (a) 
 6 LOAD_CONST 1 (0) 
 8 COMPARE_OP 5 (> =) 
 10 POP_JUMP_IF_FALSE 18 
 
 3 12 LOAD_NAME 0 (a) 
 14 STORE_NAME 1 (b) 
 16 JUMP_FORWARD 6 (до 24 ) 
 
 5 >> 18 LOAD_NAME 0 (a) 
 20 UNARY_NEGATIVE 
 22 STORE_NAME 1 (b) 
 >> 24 LOAD_CONST 2 (Нет) 
 26 RETURN_VALUE 
 

Здесь есть несколько новых инструкций. В строке 2 объект, на который ссылается a , помещается в стек, а затем помещается литерал 0 . Инструкция

  COMPARE_OP   oparg  

выполняет логическую операцию. Название операции можно найти в cmp_op [oparg] . Значения cmp_op хранятся в списке с именем dis.cmp_op . Инструкция сначала выталкивает два верхних элемента стека. Мы называем первый TOS1 , а второй TOS2 .Затем логическая операция, выбранная с помощью oparg , выполняется над ними (TOS2 cmp_op [oparg] TOS1) , и результат помещается на вершину стека. В этом примере TOS1 = 0 и TOS2 = значение . Кроме того, oparg - это 5 и cmp_op [5] = '≥' . Таким образом, cmp_op проверит a≥0 и сохранит результат (истинный или ложный) поверх стека.

Инструкция

  POP_JUMP_IF_FALSE   target  

выполняет условный переход. Сначала он выталкивает верхнюю часть стека. Если элемент на вершине стека является ложным, он устанавливает счетчик байт-кода на target . Счетчик байт-кода показывает текущее смещение байт-кода, который выполняется. Таким образом, он переходит к смещению байт-кода, которое равно целевому, и выполнение байт-кода продолжается оттуда. Смещение 18 в байт-коде является целью перехода, поэтому в дизассемблированном байт-коде перед ним стоит >> . Команда

  JUMP_FORWARD   delta  

увеличивает счетчик байт-кода на delta .В предыдущем байт-коде смещение этой инструкции равно 16, и мы знаем, что каждая инструкция занимает 2 байта. Итак, когда эта инструкция завершена, счетчик байт-кода будет 16 + 2 = 18 . Здесь дельта = 6 , а 18 + 6 = 24 , поэтому происходит переход к смещению 24 . Смещение 24 является целью перехода и также имеет знак >> .

Теперь мы можем увидеть, как оператор if-else преобразуется в байт-код. cmp_op проверяет, соответствует ли a≥0 .Если результат ложный, POP_JUMP_IF_FALSE переходит с на смещение 18, которое является началом блока else . Если это правда, то будет выполнен блок if , а затем JUMP_FORWARD перейдет к смещению 24 и не выполнит блок else .

Теперь давайте посмотрим на более сложное логическое выражение. Рассмотрим следующий исходный код:

 s = '' 'a = 1 
 c = 3 
, если a> = 0 и c == 3: 
 b = a 
 else: 
 b = -a 
' '' 
 c = compile (s, "", "exec") 
 disassemble (c) 

Здесь у нас есть логические и .Дизассемблированный байт-код:

 1 0 LOAD_CONST 0 (1) 
 2 STORE_NAME 0 (a) 
 2 4 LOAD_CONST 1 (3) 
 6 STORE_NAME 1 (c) 
 
 3 8 LOAD_NAME 0 (a) 
 10 LOAD_CONST 2 ( 0) 
 12 COMPARE_OP 5 (> =) 
 14 POP_JUMP_IF_FALSE 30 
 16 LOAD_NAME 1 (c) 
 18 LOAD_CONST 1 (3) 
 20 COMPARE_OP 2 (==) 
 22 POP_JUMP_IF_FALSE 30 
_NAME 
 4 24 LOAD95 0 (a) 26 STORE_NAME 2 (b) 
 28 JUMP_FORWARD 6 (to 36) 
 
 6 >> 30 LOAD_NAME 0 (a) 
 32 UNARY_NEGATIVE 
 34 STORE_NAME 2 (b) 
 >> 36 LOAD_CONST 3 (Нет) 
 38 RETURN_VALUE 
 

В Python и есть оператор короткого замыкания. Таким образом, при оценке X и Y он оценивает только Y , если X истинно. Это легко увидеть в байт-коде. В строке 3 сначала оценивается левый операнд и . Если (a≥0) ложно, он не оценивает второй операнд и переходит к смещению 30, чтобы выполнить блок else . Однако, если это правда, второй операнд (b == 3) также будет оцениваться.

Циклы и стек блоков

Как упоминалось ранее, в каждом кадре есть стек оценки.Кроме того, в каждом кадре есть блоков, стек . Он используется CPython для отслеживания определенных типов структур управления, таких как циклы, с блоками и try / за исключением блоков . Когда CPython хочет войти в одну из этих структур, новый элемент помещается в стек блоков, а когда CPython выходит из этой структуры, элемент для этой структуры выталкивается из стека блоков. Используя стек блоков, CPython знает, какая структура активна в данный момент. Поэтому, когда он достигает break или continue statement, он знает, какие структуры должны быть затронуты.

Давайте посмотрим, как циклы реализованы в байт-коде. Рассмотрим следующий код и его дизассемблированный байт-код:

 s = '' 'для i в диапазоне (3): 
 print (i) 
' '' 
 c = compile (s, "", "exec") 
 disassemble ( в) ------------------------------------------------ -------------------- 1 0 SETUP_LOOP 24 (до 26) 
 2 LOAD_NAME 0 (диапазон) 
 4 LOAD_CONST 0 (3) 
 6 CALL_FUNCTION 1 
 8 GET_ITER 
 >> 10 FOR_ITER 12 (до 24) 
 12 STORE_NAME 1 (i) 
 2 14 LOAD_NAME 2 (печать) 
 16 LOAD_NAME 1 (i) 
 18 CALL_FUNCTION 1 
 20 POP_TOP 
 22 JUMP_ABSOLUTE 10 
 >> 24 POP_BLOCK 
 >> 26 LOAD_CONST 1 (Нет) 
 28 RETURN_VALUE 
 

Инструкция

  SETUP_LOOP   delta  

выполняется перед запуском цикла.Эта инструкция помещает новый элемент (который также называется блоком) в стек блоков. дельта добавляется к счетчику байт-кода, чтобы определить смещение следующей инструкции после цикла. Здесь смещение SET_LOOP равно 0 , поэтому счетчик байт-кода равен 0 + 2 = 2 . Кроме того, дельта составляет 24 , поэтому смещение следующей инструкции после цикла составляет 2 + 24 = 26 . Это смещение сохраняется в блоке, который помещается в стек блоков.Кроме того, в этом блоке хранится текущее количество элементов в стеке оценки.

После этого должна выполняться функция диапазон (3) . Его oparg ( 3 ) помещается перед именем функции. Результатом является итерация . Итерируемые объекты могут сгенерировать итератор , используя инструкцию:

  GET_ITER  

Он берет итератор на вершину стека и подталкивает его итератор. Инструкция:

  FOR_ITER   delta  

предполагает наличие итератора на вершине стека. Он вызывает свой метод __next __ () . Если он дает новое значение, это значение помещается в верхнюю часть стека (над итератором). Внутри цикла верх стека сохраняется в i после этого, и выполняется функция print . Затем выталкивается верхняя часть стека, которая является текущим значением итератора. После этого инструкция

  JUMP_ABSOLUTE   target  

устанавливает счетчик байт-кода на target и переходит к смещению target .Таким образом, он переходит к смещению 10 и снова запускает FOR_ITER , чтобы получить следующее значение итератора. Если итератор указывает, что других доступных элементов нет, верх стека выталкивается, а счетчик байтового кода увеличивается на дельта . Здесь дельта = 12 , поэтому после завершения цикла он переходит к смещению 24. При смещении 24 инструкция

  POP_BLOCK  

удаляет текущий блок из вершины стека блоков. Смещение следующей инструкции после цикла сохраняется в блоке (здесь 26).Таким образом, интерпретатор перейдет к этому смещению и продолжит выполнение оттуда. На рисунке 3 в качестве примера показаны операции с байт-кодом со смещениями 0, 10, 24 и 26 (на самом деле на рисунках 1 и 2 мы показали только стек оценки в каждом кадре).

Но что произойдет, если мы добавим в этот цикл оператор break ? Рассмотрим следующий исходный код и его дизассемблированный байт-код:

 s = '' 'для i в диапазоне (3): 
 break 
 print (i) 
' '' 
 c = compile (s, "", "exec") 
 разобрать (c) --------------------------------------------- ----------------------- 1 0 SETUP_LOOP 26 (до 28) 
 2 LOAD_NAME 0 (диапазон) 
 4 LOAD_CONST 0 (3) 
 6 CALL_FUNCTION 1 
 8 GET_ITER 
 >> 10 FOR_ITER 14 (до 26) 
 12 STORE_NAME 1 (i) 
 2 14 BREAK_LOOP 
 
 3 16 LOAD_NAME 2 (печать) 
 18 LOAD_NAME 1 (i) 
 20 CALL_FUNCTION 1 
 22 POP_TOP 10 
 24 JUMP_ABSOLUTE 
 >> 26 POP_BLOCK 
 >> 28 LOAD_CONST 1 (Нет) 
 30 RETURN_VALUE 
 

Мы только добавили оператор break к предыдущему ious loop. Этот оператор преобразуется в

  BREAK_LOOP  

Этот код операции удаляет эти лишние элементы из стека оценки и выталкивает блок из вершины стека блоков. Вы должны заметить, что другие инструкции цикла все еще используют стек оценки. Поэтому, когда цикл прерывается, элементы, которые ему принадлежат, должны быть удалены из стека оценки. В этом примере объект итератора все еще находится на вершине стека. Помните, что блок в стеке блоков хранит количество элементов, которые существовали в стеке оценки перед запуском цикла.

Итак, зная это число, BREAK_LOOP выталкивает эти дополнительные элементы из стека оценки. Затем происходит переход к смещению, которое хранится в текущем блоке стека блоков (здесь 28). Это смещение следующей инструкции после цикла. Таким образом, цикл прерывается, и выполнение продолжается оттуда.

Создание объекта кода

Объект кода - это объект типа код , и его можно создавать динамически. Модуль types может помочь с динамическим созданием новых типов, а класс CodeType () в этом модуле возвращает новый объект кода:

.CodeType (co_argcount, co_kwonlyargcount, 
 co_nlocals, co_stacksize, co_flags, 
 co_code , co_consts, co_names, 
 co_varnames, co_filename, co_name, 
 co_firstlineno, co_lnotab, freevars = None, 
 cellvars = None) 

Аргументы образуют все атрибуты объекта кода. Вы уже знакомы с некоторыми из этих аргументов (например, co_varnames и co_firstlineno ). freevars и cellvars являются необязательными, так как они используются в замыканиях, и не все функции используют их (дополнительную информацию о них см. В этой статье). Другие атрибуты объясняются на примере следующей функции:

 def f (a, b, * args, c, ** kwargs): 
 d = 1 
 def g (): 
 return 1 
 g () 
 return 1 

co_argcount : Если объект кода является объектом функции, количество принимаемых аргументов (не включая аргументы только по ключевым словам, * или ** аргументов). Для функции f это 2 .

co_kwonlyargcount : если объект кода является объектом функции, количество аргументов, содержащих только ключевые слова (не включая ** arg). Для функции f это 1 .

co_nlocals : количество локальных переменных плюс имя функций, определенных в объекте кода (аргументы также считаются локальными переменными). Фактически, это количество элементов в co_varnames , которое равно ('a', 'b', 'c', 'args', 'kwargs', 'd', 'g') .Так что 7 для f .

co_stacksize : показывает наибольшее количество элементов, которые будут помещены в стек оценки этим объектом кода. Помните, что некоторые коды операций должны помещать некоторые элементы в стек оценки. Этот атрибут показывает самый большой размер, до которого когда-либо будет увеличиваться стек в результате операций с байт-кодом. В этом примере это 2 . Позвольте мне объяснить причину этого. Если вы разобрали байт-код этой функции, вы получите:

 2 0 LOAD_CONST 1 (1) 
 2 STORE_FAST 5 (d) 
 3 4 LOAD_CONST 2 (<объект кода g в 0x0000028A62AB1D20, файл " ", строка 3>) 
 6 LOAD_CONST 3 ('f. .g ') 
 8 MAKE_FUNCTION 0 
 10 STORE_FAST 6 (g) 
 
 5 12 LOAD_FAST 6 (g) 
 14 CALL_FUNCTION 0 
 16 POP_TOP 
 
 6 18 LOAD_CONST 1 (1) 
 20 RETURN_VALUE 
 20 RETURN_VALUE 
0005 25 строка 2, один элемент помещается в стек с использованием  LOAD_CONST  и будет извлечен с помощью  STORE_FAST . Строки 5 и 6 аналогичным образом помещают один элемент в стек и вставляют его позже.Но в строке 3 два элемента помещаются в стек для определения внутренней функции  g : ее кодовый объект и ее имя. Таким образом, это максимальное количество элементов, которое будет помещено в стек оценки этим объектом кода, и оно определяет размер стека.  
 
  co_flags : целое число, биты которого указывают на то, принимает ли функция переменное количество аргументов, является ли функция генератором и т. Д. В нашем примере это значение равно  79 .Двоичное значение  79  равно  0b1001111 . Он использует систему с прямым порядком байтов, в которой байты записываются слева направо с возрастанием  и . Итак, первый бит - первый справа. Вы можете обратиться к этой ссылке, чтобы узнать значение этих битов. Например, третий бит справа представляет флаг  CO_VARARGS . Когда это  1 , это означает, что объект кода имеет переменный позиционный параметр ( * args  -like).
 
  co_filename : строка, определяющая файл, в котором присутствует функция. В данном случае это  '' , поскольку я запускал сценарий в записной книжке Jupyter. 
 
  co_name : имя, с которым был определен этот объект кода.  Вот имя функции  'f' . 
 
  Внедрение байт-кода  
 
 Теперь, когда мы полностью знакомы с объектом кода, мы можем начать изменять его байт-код.Важно отметить, что объект кода неизменен. Итак, однажды созданный, мы не можем его изменить. Предположим, мы хотим изменить байт-код следующей функции: 
 
 def f (x, y): 
 return x + yc = f .__ code__ 
 Здесь мы не можем напрямую изменить байт-код объекта кода функции. Вместо этого нам нужно создать новый объект кода, а затем назначить его этой функции. Для этого нам понадобится еще несколько функций. Функция  disassemble  может дизассемблировать байт-код в некоторые понятные для человека инструкции.Мы можем изменять их по своему усмотрению, но затем нам нужно собрать его обратно в байт-код, чтобы назначить его новому объекту кода. Вывод команды  disassemble  представляет собой отформатированную строку, которую легко читать, но трудно изменить. Поэтому я добавлю новую функцию, которая может дизассемблировать байт-код в список инструкций. Он очень похож на  disassemble , однако его вывод представляет собой список.
 Мы можем попробовать это на предыдущей функции:
 disassembled_bytecode = disassemble_to_list (c) 
 Теперь  disassembled_bytecode  равно:
 [['LOAD_FAST', 'x'], 
 ['LOAD_FAST', 'y '], 
 [' BINARY_ADD '], 
 [' RETURN_VALUE ']] 
 Теперь мы можем легко изменить инструкции этого списка.Но нам также нужно собрать его обратно в байт-код:
 Функция  get_oparg  похожа на обратную функцию  get_argvalue . Он принимает значение argvalue, которое является понятным для человека значением oparg, и возвращает соответствующий oparg. Ему нужен объект кода в качестве аргумента, поскольку атрибуты объекта кода, такие как  co_consts , необходимы для преобразования значения argvalue в oparg.
 Функция  build  берет объект кода и список дизассемблированных байт-кодов и собирает их обратно в байт-код. Он использует  dis.opname  для преобразования имени операции в код операции. Затем он вызывает  get_oparg  для преобразования значения argvalue в oparg. Наконец, он возвращает байтовый литерал списка байт-кода. Теперь мы можем использовать эти новые функции для изменения байт-кода предыдущей функции  f . Сначала мы меняем одну из инструкций в  disassembled_bytecode :
 disassembled_bytecode [2] = ['BINARY_MULTIPLY'] 
 Инструкция
  BINARY_MULTIPLY  
 выталкивает два верхних элемента стека и умножает их вместе результат в стек.Теперь мы собираем модифицированный дизассемблированный байт-код:
 new_co_code = assembly (disassembled_bytecode, c.co_consts, 
 c.co_varnames, c.co_names, 
 c.co_cellvars + c.co_freevars) 
 После этого мы создаем новый объект кода:
 типов импорта 
 nc = types.CodeType (c.co_argcount, c.co_kwonlyargcount, 
 c.co_nlocals, c. co_stacksize, c.co_flags, 
 new_co_code, c.co_consts, c.co_names, 
 c.co_varnames, c.co_varnames , c.co_name, 
 c.co_firstlineno, c.co_lnotab, 
 c.co_freevars, c.co_cellvars) 
 f .__ code__ = nc 
 Мы используем все атрибуты  f  для его создания и заменяем только новый байт-код ( new_co_code ). Затем мы назначаем новый объект кода  f . Теперь, если мы снова запустим  f , он не суммирует свои аргументы. Вместо этого он умножит их вместе:
 f (2,5) # Результат будет 10, а не 7 
  Внимание : Типы . Функция CodeType  имеет два необязательных аргумента для  freevars  и  cellvars , однако: при их использовании следует соблюдать осторожность.Как упоминалось ранее, атрибуты  co_cellvars  и  co_freevars  объекта кода используются только тогда, когда объект кода принадлежит функции, которая имеет свободные переменные или нелокальные переменные. Таким образом, функция должна быть замыканием или внутри нее должно быть определено замыкание. Например, рассмотрим следующую функцию:
 def func (x): 
 def g (y): 
 return x + y 
 return g 
 Теперь проверьте его объект кода:
 c = func .__ code__ 
 c.co_cellvars # Вывод: ('x',) 
 Фактически, эта функция имеет одну нелокальную переменную  x , поскольку к этой переменной обращаются ее внутренние функции. Теперь мы можем попробовать воссоздать его кодовый объект, используя те же атрибуты:
 nc = types.CodeType (c.co_argcount, c.co_kwonlyargcount, 
 c.co_nlocals, c.co_stacksize, c.co_flags, 
 new_co_code, c.co_consts, c .co_names, 
 c.co_varnames, c.co_filename, c.co_name, 
 c.co_firstlineno, c.co_lnotab, 
 cellvars = c.co_cellvars, 
 freevars = c.co_freevars) 
 Но если мы проверим тот же атрибут нового объекта кода
 nc.co_cellvars Результат будет: () 
 Он окажется пустым. Итак,  types.CodeType  не может создать один и тот же объект кода. Если вы попытаетесь назначить этот объект кода функции и выполнить эту функцию, вы получите сообщение об ошибке (это было проверено на Python 3.7.4).
  Оптимизация кода 
 Понимание инструкций байт-кода может помочь нам в оптимизации исходного кода.Рассмотрим следующий исходный код:
 setup1 = '' 'import math 
 mult = 2 
 def f (): 
 total = 0 
 i = 1 
 для i в диапазоне (1, 200): 
 total + = mult * math.log (i) 
 вернуть итог 
 '' 'setup2 =' '' import math 
 def f (): 
 log = math.log 
 mult = 2 
 total = 0 
 для i в диапазоне (1, 200) : 
 total + = mult * log (i) 
 return total 
 '' '
 Здесь мы определяем функцию  f ()  для вычисления простого математического выражения.Это было определено двумя разными способами. В  setup1  мы используем глобальную переменную  mult  внутри  f ()  и напрямую используем функцию  log ()  из модуля  math . В  setup2 ,  mult  является локальной переменной  f () . Кроме того,  math.log  сначала сохраняется в локальной переменной  log . Теперь мы можем сравнить производительность этих функций:
 t1 = timeit.timeit (stmt = "f ()", setup = setup1, number = 100000) 
 t2 = timeit.timeit (stmt = "f ()", setup = setup2, number = 100000) 
 print ("t1 =", t1) 
 print ("t2 =", t2) 
 ----------- -------------------------------------------------- ------- 
 t1 = 3.80761210086 
 t2 = 3.223011
14383 
 Вы можете получить разные числа для  t1  и  t2 , но суть в том, что  setup2  быстрее, чем  setup1 . Теперь давайте сравним их байт-код, чтобы понять, почему он быстрее. Мы просто смотрим на строку 7 в дизассемблированном коде  setup1  и  setup2 .Это байт-код для этой строки:  total + = mult * log (i) .
 В  setup1  мы имеем:
 7 24 LOAD_FAST 0 (всего) 
 26 LOAD_GLOBAL 1 (mult) 
 28 LOAD_GLOBAL 2 (математический) 
 30 LOAD_METHOD 3 (log) 
 32 LOAD_FAST 1 (i) 
 34 1 CALL_MET 
 36 BINARY_MULTIPLY 
 38 INPLACE_ADD 
 40 STORE_FAST 0 (итого) 
 42 JUMP_ABSOLUTE 20 
 >> 44 POP_BLOCK 
 Но в  setup2  мы получаем:
 7 30 LOAD_FAST 2 (итого) 
 32 LOAD_FAST LOAD_FAST 0 (журнал) 
 36 LOAD_FAST 3 (i) 
 38 CALL_FUNCTION 1 
 40 BINARY_MULTIPLY 
 42 INPLACE_ADD 
 44 STORE_FAST 2 (всего) 
 46 JUMP_ABSOLUTE 26 
 >> 48 POP_BLOCK 
  Как вы видите в обоих настройках1 mult  и  math  загружаются с использованием  LOAG_GLOBAL , но в  setup2 ,  mult  и  log  загружаются с использованием  LOAD_FAST . Таким образом, две инструкции  LOAD_GLOBAL  были заменены на  LOAD_FAST . Дело в том, что  LOAD_FAST , как следует из названия, намного быстрее, чем  LOAD_GLOBAL . Мы упоминали, что имена глобальных и локальных переменных хранятся в  co_names  и  co_varnames . Но как интерпретатор CPython находит значения при выполнении скомпилированного кода?
 Локальные переменные хранятся в массиве в каждом кадре (который не показан на предыдущих рисунках для упрощения).Мы знаем, что имена локальных переменных хранятся в  co_varnames . Их значения будут храниться в этом массиве в том же порядке. Поэтому, когда интерпретатор видит инструкцию типа  LOAD_FAST 1 (mult) , он считывает элемент этого массива по индексу  1 .
 Глобальные и встроенные функции модуля хранятся в словаре. Мы знаем, что их имена хранятся в  co_names . Поэтому, когда интерпретатор видит инструкцию типа  LOAD_GLOBAL 1 (mult) , он сначала получает имя этой глобальной переменной из  co_names [1] . Затем он будет искать это имя в словаре, чтобы получить его значение. Это намного более медленный процесс по сравнению с простым поиском в массиве локальных переменных. В результате  LOAD_FAST  быстрее, чем  LOAD_GLOBAL , и замена  LOAD_GLOBAL  на  LOAD_FAST  может улучшить производительность. Это можно сделать, просто сохранив встроенные и глобальные переменные в локальных переменных или напрямую изменив инструкции байт-кода.
  Пример: определение констант в Python 
 В этом примере показано, как использовать внедрение байт-кода для изменения поведения функций.Мы собираемся написать декоратор, который добавляет в Python оператор  const . В некоторых языках программирования, таких как C, C ++ и JavaScript, есть ключевое слово  const . Если переменная объявлена ​​как const с использованием этого ключевого слова, то изменение ее значения недопустимо, и мы больше не можем изменить значение этой переменной в исходном коде.
 Python не имеет оператора const, и я не утверждаю, что действительно необходимо иметь такое ключевое слово в Python. Кроме того, определение констант может быть выполнено без использования инъекции байт-кода.Итак, это всего лишь пример, чтобы показать вам, как привести в действие инъекцию байт-кода. Во-первых, позвольте мне показать, как вы можете его использовать. Ключевое слово const предоставляется с помощью декоратора функции с именем  const . После того, как вы украсите функцию  const , вы можете объявить переменную внутри нее как константу, используя ключевое слово  const.  (.  в конце является частью ключевого слова). Вот пример:
 @const 
 def f (x): 
 const. A = 5 
 return A * x 
 f (2) # Результат: 10 
 Переменная  A  внутри  f  теперь является константой.Теперь, если вы попытаетесь переназначить эту переменную внутри  f , будет возбуждено исключение:
 @const 
 def f (x): 
 const.  A = 5 
 A = A + 1 
 возврат A * x 
 ----------------------------------- --------------------------------- # Возникает исключение: 
  ConstError : 'A' - константа и не может быть переназначен! 
 Когда переменная объявлена ​​как константа, ей должно быть присвоено ее начальное значение, и она будет локальной переменной этой функции.
 Теперь позвольте мне показать вам, как это было реализовано. Предположим, я определяю такую ​​функцию (без декораций):
 def f (x): 
 const. A = 5 
 A = A + 1 
 return A * x 
 Он будет правильно скомпилирован. Но если вы попытаетесь выполнить эту функцию, вы получите ошибку:
 f (2) 
 ------------------------------ --------------------------------------  NameError : имя 'const' не определено 
 Теперь давайте посмотрим на дизассемблированный байт-код этой функции:
 2 0 LOAD_CONST 1 (5) 
 2 LOAD_GLOBAL 0 (const) 
 4 STORE_ATTR 1 (A) 
 3 6 LOAD_FAST 1 (A) 
 8 LOAD_CONST 2 ( 1) 
 10 BINARY_ADD 
 12 STORE_FAST 1 (A) 
 
 4 14 LOAD_FAST 1 (A) 
 16 LOAD_FAST 0 (x) 
 18 BINARY_MULTIPLY 
 20 RETURN_VALUE 
 
 Когда Python пытается скомпилировать функцию const , требуется  как глобальная переменная, поскольку она не была определена в функции. Переменная  A  считается атрибутом глобальной переменной  A . Фактически,  конст. A = 1  совпадает с  const. A = 1 , поскольку Python игнорирует пробелы между оператором точки и именем атрибута. Конечно, у нас действительно нет глобальной переменной с именем  A  в исходном коде. Но Python не будет проверять это во время компиляции. Только в процессе выполнения окажется, что имя  const  не определено. Так что наш исходный код будет принят при компиляции.Но нам нужно изменить его байт-код перед выполнением объекта кода этой функции. Сначала нам нужно создать функцию для изменения байт-кода:
 Эта функция получает список инструкций байт-кода, сгенерированный  assembly_to_list  в качестве аргумента. Он имеет два списка с именами  констант  и  индексов , в которых хранятся имена переменных, объявленных как const, и смещение, по которому они были назначены впервые. Первый цикл просматривает список инструкций байт-кода и находит все инструкции  ['LOAD_GLOBAL', 'const'] . Имя переменной должно быть в следующей инструкции. В этом примере следующая инструкция -  ['STORE_ATTR', 'A'] , имя -  A . Это имя и смещение этой инструкции хранятся в  константах  и  индексах . Теперь нам нужно избавиться от глобальной переменной  const  и ее атрибута и вместо этого создать локальную переменную с именем  A . Инструкция
  NOP  
 - это код «ничего не делать».Когда интерпретатор достигает  NOP , он игнорирует его. Мы не можем просто удалить код операции из списка инструкций, поскольку удаление одной инструкции уменьшает смещение всех следующих инструкций. Теперь, если в байт-коде есть скачки, их целевое смещение тоже должно измениться. Так что намного проще просто заменить ненужную инструкцию на  NOP . Теперь мы заменяем  ['LOAD_GLOBAL', 'const']  на  NOP , а затем заменяем  ['STORE_ATTR', 'A']  на  ['STORE_FAST', 'A'] . Последний байт-код выглядит следующим образом:
 2 0 LOAD_CONST 1 (5) 
 2 NOP 
 4 STORE_FAST 1 (A) 
 3 6 LOAD_FAST 1 (A) 
 8 LOAD_CONST 2 (1) 
 10 BINARY_ADD 
 12 STORE_FAST 1 (A) ) 
 
 4 14 LOAD_FAST 1 (A) 
 16 LOAD_FAST 0 (x) 
 18 BINARY_MULTIPLY 
 20 RETURN_VALUE 
 
 Теперь строка 2 эквивалентна  a = 2  в исходном коде, и выполнение этого байт-кода не вызывает любая ошибка времени выполнения.Цикл также проверяет, не объявлена ​​ли одна и та же переменная как константа дважды. Поэтому, если переменная, объявленная как const, уже существует в списке  констант , она вызовет настраиваемое исключение. Теперь осталось только убедиться, что переменные const не переназначены.
 Второй цикл снова просматривает список инструкций байт-кода, чтобы найти любое переназначение постоянных переменных. Любая инструкция вроде  ['STORE_GLOBAL', 'A']  или  ['STORE_FAST', 'A']  означает, что переназначение находится в исходном коде, поэтому она вызовет настраиваемое исключение, чтобы предупредить пользователя. Смещение начального присвоения константы требуется, чтобы убедиться, что начальное присвоение не рассматривается как переназначение.
 Как упоминалось ранее, байт-код следует изменить перед выполнением кода. Таким образом, перед вызовом функции  f  необходимо вызвать функцию  add_const . По этой причине мы помещаем его внутрь декоратора. Функция декоратора  const  получает в качестве аргумента целевую функцию  f . Сначала он изменит байт-код  f , используя  add_const , а затем создаст новый объект кода с измененным байт-кодом.Этот кодовый объект будет присвоен  f .
 Когда мы создаем новый объект кода, необходимо изменить некоторые из его атрибутов. В исходной функции  const  - глобальная переменная, а  A  - атрибут, поэтому оба они были добавлены в кортеж  co_names , и их следует удалить из  co_names  нового объекта кода. Кроме того, когда такой атрибут, как  A , превращается в локальную переменную, его имя должно быть добавлено в кортеж  co_varnames . Атрибут  co_nlocals  указывает количество локальных переменных (плюс определенные функции) и также должен быть обновлен. Остальные атрибуты остаются прежними. Наконец, декоратор возвращает целевую функцию с новым объектом кода, и теперь целевая функция готова к выполнению.
 Дизассемблирование байт-кода Python - Питер Голдсборо 
 В Python модуль  dis  позволяет дизассемблировать код Python в отдельные инструкции, выполняемые интерпретатором Python (обычно cPython) для каждой строки.Передача модуля, функции или другого фрагмента кода в функцию  dis.dis  вернет удобочитаемое представление базового дизассемблированного байт-кода. Это полезно для анализа и ручной настройки жестких циклов или выполнения других видов необходимой детальной оптимизации.
 Базовое использование 
 Основная функция, с которой вы будете взаимодействовать, когда захотите дизассемблировать код Python, - это  dis.dis . Он принимает либо функцию, метод, класс, модуль, строку кода, генератор или последовательность байтов необработанного байт-кода и распечатывает разборку этого объекта кода в  stdout  (если не указан явный аргумент  file ). В случае класса он будет дизассемблировать каждый метод (также статические методы и методы класса). Для модуля он разбирает все функции в этом модуле.
 Давайте посмотрим на это на практике. Возьмите следующий код:
  импорт

класс Foo (объект):
  def __init __ (сам):
    проходят

  def foo (self, x):
    вернуть x + 1

def bar ():
  х = 5
  у = 7
  г = х + у
  вернуть z

def main ():
  dis.dis (bar) # разбирает `bar`
  dis.dis (Foo) # разбирает каждый метод в `Foo`
  
 Это напечатает:
  14 0 НАГРУЗКА_КОНСТ 1 (5)
             3 STORE_FAST 0 (x)

15 6 LOAD_CONST 2 (7)
             9 STORE_FAST 1 (г)

16 12 LOAD_FAST 0 (x)
            15 LOAD_FAST 1 (г)
            18 BINARY_ADD
            19 STORE_FAST 2 (z)

17 22 LOAD_FAST 2 (z)
            25 RETURN_VALUE

Разборка __init__:
 8 0 LOAD_CONST 0 (Нет)
             3 RETURN_VALUE

Разборка foo:
11 0 LOAD_FAST 1 (x)
             3 LOAD_CONST 1 (1)
             6 BINARY_ADD
             7 RETURN_VALUE
  
 Кроме того, мы можем дизассемблировать весь модуль из командной строки, используя  python -m dis module_file. py . В любом случае, на этом этапе нам, вероятно, следует обсудить формат вывода дизассемблирования. Возвращаются следующие столбцы:
 Исходная строка кода, на которую ссылается разборка.
 Адрес инструкции байт-кода.
 Название инструкции.
 Индекс аргумента в имени блока кода и таблице констант.
 Удобное для человека отображение индекса аргумента (4) на фактическое значение или имя, на которое ссылаются.
 Для (4) важно понимать, что все  объектов кода  в Python, то есть изолированные блоки кода, такие как функции, имеют внутреннее имя  и таблицы констант . Эти таблицы представляют собой просто списки, где таблица констант будет содержать константы, такие как строковые литералы, числа или специальные значения, такие как  None , которые появляются хотя бы один раз в блоке кода, тогда как таблица имен будет содержать список имен переменных. Эти имена переменных затем являются ключами в словаре, сопоставляющем такие символы с фактическими значениями. Причина, по которой аргументы инструкции являются индексами в таблицах, а не значениями, хранящимися в этих таблицах, заключается в том, что аргументы могут иметь одинаковую длину (всегда два байта). Как вы понимаете, хранение строк переменной длины в байт-коде напрямую делает продвижение счетчика программы намного более сложным.
 Объекты кода 
 Я только что упомянул концепцию  объектов кода . Но что это? Проще говоря, объекты кода - это скомпилированное представление части кода.Затем это представление может быть понято интерпретатором cPython, который является наиболее распространенной и популярной реализацией языка программирования Python. Он написан на C и использует эти объекты кода для построчного выполнения кода Python. Рядом с cPython существует ряд других компиляторов и интерпретаторов Python, включая PyPy (который использует JIT-компилятор, что часто делает его намного быстрее, чем cPython) и Jython.
 Есть несколько способов создания объектов кода. Самый простой - получить доступ к члену  __code__ , который содержит все функции и методы (помните, что методы - это просто функции с дополнительным аргументом экземпляра):
  def foo ():
  проходят


В [1]: foo.__код__
Out [1]: <код объекта foo по адресу 0x109d419c0, файл «<строка>», строка 1>
  
 В качестве альтернативы вы можете просто скомпилировать любой фрагмент кода самостоятельно, используя встроенную команду  compile . Эта функция вернет объект кода. Принимает следующие параметры:
 Строка или объект  ast .
 Имя файла, в котором написан код, или описательная строка, если такой файл не существует (например,  «<строка>» ).
 Режим компиляции, который может быть одной из следующих трех строк:
  'exec' : позволяет анализировать несколько выражений.
  'eval' : позволяет анализировать только одно выражение (без пробелов).
  'single' : интерпретирует и оценивает выражение как интерактивная оболочка. Это означает, что код будет оценен, и любой результат, отличный от  None , будет напечатан.
 Например:
  code_object = compile ('x = 5; x + = 1', '', 'exec') # ОК
code_object = compile ('x = 5; x + = 1', '', 'eval') # Ошибка
  
 Эти объекты кода предоставляют всю информацию, необходимую интерпретатору Python, например cPython, для выполнения кода, представленного объектом.Для этого у объекта кода есть несколько интересных атрибутов:
  co_code : фактическая байтовая строка байт-кода.
  co_consts : Константы, доступные инструкциям («таблица констант»).
  co_names : глобальные символы, доступные для инструкций.
  co_nlocals : количество локальных символов (функций и переменных).
  co_varnames : список локальных символов (функций и переменных).
  co_argcount : если объект кода является объектом функции, количество аргументов, которые она принимает.
 Например, мы можем увидеть это, когда создадим следующую функцию:
  def foo ():
  х = 5
  def bar ():
    проходят
  вернуть len ([x])
  
 Кодовый объект  foo  будет иметь константы ( co_consts )  None  и  5 , имена локальных переменных ( co_varnames )  bar  и  x  и доступные символы ( co_names )  лен :
  В [1]: foo.__code __. co_consts
Выход [1]: (Нет, 5)
В [2]: foo .__ code __. Co_varnames
Выход [2]: ('bar', 'x')
В [3]: foo .__ code __. Co_names
Out [3]: ('len',)
  
 Понимание дизассемблированного кода 
 Теперь, когда мы знаем, что такое объекты кода и что у них есть таблицы имен и констант, мы можем лучше понять вывод  dis.dis () . Возьмем разборку следующей функции:
  у = 5
функция def ():
  x = len ([1, 2, 3])
  г = х + у
  вернуть z
  
 то есть:
  В [1]: дис.дисфункция)
Из [1]:
  3 0 LOAD_GLOBAL 0 (длина)
              3 LOAD_CONST 1 (1)
              6 LOAD_CONST 2 (2)
              9 LOAD_CONST 3 (3)
             12 BUILD_LIST 3
             15 CALL_FUNCTION 1 (1 позиционная, 0 пар ключевых слов)
             18 STORE_FAST 0 (x)

  4 21 LOAD_FAST 0 (x)
             24 LOAD_GLOBAL 1 (г)
             27 BINARY_ADD
             28 STORE_FAST 1 (z)

  5 31 LOAD_FAST 1 (z)
             34 RETURN_VALUE
  
 Например, самая первая строка показывает инструкцию  LOAD_GLOBAL .Это первая инструкция байт-кода третьей строки функции Python, как указано во втором и первом столбцах соответственно. Как мы также можем видеть, он загружает имя с индексом 0. Напомним, что этот индекс ссылается на список  co_names , связанный с объектом дизассемблированного кода. Последний столбец  len  - это просто дружеский намек от  dis.dis ()  относительно значения  co_names [0] .
 Но что делает  LOAD_GLOBAL ? Ну загружает глобальный.В данном случае глобальная функция (символ)  len . Это было очевидно, но что более интересно, так это , где  загружает глобальные данные. Ответ на этот вопрос заключается в том, как устроен интерпретатор cPython: он полностью основан на стеке. Это означает, что в стек добавляются любые символы функций или методов, константы или имена переменных. Такие операции, как двоичное сложение (инструкция байт-кода  BINARY_ADD , которую вы видите) будут затем работать с этим стеком, выталкивая два значения и помещая результат обратно в стек.Инструкции вызова функции ( CALL_FUNCTION ) аналогичным образом выталкивают символ функции и аргументы из стека, выполняют функцию (которая помещает новый кадр   в стек) и, в конечном итоге, помещают возвращаемое значение вызываемой функции обратно в стек.
 Полный список инструкций, понятных cPython, можно найти здесь. Вот несколько интересных:
  LOAD_FAST  : помещает локальную переменную по заданному индексу в стек.
  STORE_GLOBAL  : вставляет вершину стека в переменную с именем, указанным в данном индексе.
  BINARY_ADD : извлекает два верхних значения из стека, складывает их и помещает результат обратно в стек.
  BUILD_LIST <размер> : извлекает из стека множество элементов размером   и выделяет новый список.
  CALL_FUNCTION <#arguments> : Извлекает  #arguments  множества аргументов из стека.Младший байт этого числа определяет количество позиционных аргументов, старший байт - количество аргументов ключевого слова. Затем извлекает символ функции (саму себя) из стека, выполняет вызов и помещает возвращаемое значение функции обратно в стек.
  MAKE_FUNCTION <#arguments> : для создания объекта функции потребляет:
 Все аргументы по умолчанию в позиционном порядке,
 Кодовый объект функции,
 Полное имя функции,
из стека и помещает созданный объект функции в стек.
  POP_TOP : просто выталкивает (например, «удаляет») значение наверху стека.
 Практические примеры 
 Давайте теперь рассмотрим практические примеры того, как дизассемблирование наших программ может помочь вам оптимизировать и лучше понять ваш код.
 Исследование оптимизаций 
 Один простой случай - это расследование, когда ваш компилятор Python выполняет определенные оптимизации, а когда нет. Например, возьмите следующий код:
  я = 1 + 2
f = 3.4 * 5,6
s = 'Привет' + 'Мир!'

Я = я * 3 * 4
F = f / 2/3
S = s + 'Пока!'
  
 Делаем разборку показывает нам (комментарии мои):
  ### i
2 0 LOAD_CONST 10 (3)
            3 STORE_FAST 0 (i)

### f

3 6 LOAD_CONST 11 (19.04)
            9 STORE_FAST 1 (f)

### s

4 12 LOAD_CONST 12 ('Привет, мир!')
           15 STORE_FAST 2 (с)

### Я

6 18 LOAD_FAST 0 (i)
           21 LOAD_CONST 7 (3)
           24 BINARY_MULTIPLY
           25 LOAD_CONST 8 (4)
           28 BINARY_MULTIPLY
           29 STORE_FAST 3 (I)

### F

7 32 LOAD_FAST 1 (f)
           35 LOAD_CONST 2 (2)
           38 BINARY_TRUE_DIVIDE
           39 LOAD_CONST 7 (3)
           42 BINARY_TRUE_DIVIDE
           43 STORE_FAST 4 (F)

### S

8 46 LOAD_FAST 2 (с)
           49 LOAD_CONST 9 («Пока!»)
           52 BINARY_ADD
           53 STORE_FAST 5 (S)
           56 LOAD_CONST 0 (Нет)
  
 Как видите, компилятор легко выполнит простые арифметические операции «во время компиляции», такие как сложение  1 + 2  или сокращение выражения  3. 4 * 5.6  к константе  19.04 . Компилятор даже немедленно выполнит конкатенацию строк. Однако, как только задействуется одна переменная (см.  I  или  f ), компилятор прекращает оптимизацию и загружает имя переменной, а также все константы по отдельности и выполняет двоичные операции одну за другой в естественном порядке. операции.
 Когда самообладание - это плохо 
 Теперь давайте рассмотрим более реалистичный случай, когда разборка действительно дала бы вам понимание.В Python мы обычно используем диапазон   и итераторы для перебора последовательности чисел. Однако мы можем подумать, что вызов  диапазона  и использование итератора может быть слишком дорогостоящим по сравнению с циклом, подобным C-образному свертыванию. То есть мы хотим сравнить:
 с
  я = 0
пока я <х:
  я + = 1
  
 Давайте сделаем это и профилируем их:
  В [1]: timeit. timeit ('for i in range (x): pass', globals = dict (x = 100))
Из [1]: 1.49653139401

В [2]: timeit.timeit ('i = 0 \ n while i  
 Как видим, встроенная версия намного шустрее. Давайте разберем код и попробуем понять, почему. Сначала для диапазона   петля:
  1 0 SETUP_LOOP 20 (до 23)
            3 LOAD_NAME 0 (диапазон)
            6 LOAD_NAME 1 (x)
            9 CALL_FUNCTION 1 (1 позиционная, 0 пар ключевых слов)
           12 GET_ITER
      >> 13 FOR_ITER 6 (до 22)
           16 STORE_NAME 2 (i)
           19 JUMP_ABSOLUTE 13
      >> 22 POP_BLOCK
      >> 23 LOAD_CONST 0 (Нет)
           26 RETURN_VALUE
  
 Тогда для собственной версии:
  1 0 LOAD_CONST 0 (0)
            3 STORE_NAME 0 (i)

2 6 SETUP_LOOP 26 (до 35)
      >> 9 LOAD_NAME 0 (i)
           12 LOAD_NAME 1 (x)
           15 COMPARE_OP 0 (<)
           18 POP_JUMP_IF_FALSE 34
           21 LOAD_NAME 0 (i)
           24 LOAD_CONST 1 (1)
           27 INPLACE_ADD
           28 STORE_NAME 0 (i)
           31 JUMP_ABSOLUTE 9
      >> 34 POP_BLOCK
      >> 35 LOAD_CONST 2 (Нет)
           38 RETURN_VALUE
  
 Как мы видим, версия, использующая встроенную функцию  range , имеет меньше инструкций, чем вариант «накатать самостоятельно». В конечном итоге это сводится к тому, что версия, использующая диапазон  , будет лучше использовать внутренние реализации итераторов C, в то время как наша настраиваемая версия требует повторной интерпретации  INPLACE_ADD ,  COMPARE_OP ,  POP_JUMP_IF_FALSE  и других операций, что требует больше времени.
 Динамический поиск 
 Наконец, проверка дизассемблирования кода может дать нам довольно интересное представление о том, как свойства динамического языка Python влияют на его производительность.Напомним, что символ в Python необходимо повторно оценивать при каждом вызове во время выполнения. Это означает, что даже если мы дважды используем одну и ту же глобальную переменную в одной строке кода, ее придется извлекать из глобального пространства имен дважды, индивидуально, независимо от предыдущих или будущих загрузок, учитывая, что она может очень хорошо изменить значение и / или введите между оценками. В конечном итоге это означает, что кэширование «глубоко определенных» имен (с большим количеством точек) и сохранение их в локальных переменных может немного улучшить производительность нашего кода.
 В качестве простого примера предположим, что мы хотим просуммировать синусы диапазона значений - множества значений. Наивный способ сделать это будет следующим:
  def first ():
  всего = 0
  для x в диапазоне (1000):
    всего + = math.sin (x)
  общая сумма возврата
  
 Когда мы разбираем это с помощью  dis.dis (first) , мы получаем следующее:
  2 0 LOAD_CONST 1 (0)
            3 STORE_FAST 0 (всего)

3 6 SETUP_LOOP 39 (до 48)
            9 LOAD_GLOBAL 0 (диапазон)
           12 LOAD_CONST 2 (1000)
           15 CALL_FUNCTION 1 (1 позиционная, 0 пар ключевых слов)
           18 GET_ITER
      >> 19 FOR_ITER 25 (к 47)
           22 STORE_FAST 1 (x)

4 25 LOAD_FAST 0 (всего)
           28 LOAD_GLOBAL 1 (математика)
           31 LOAD_ATTR 2 (грех)
           34 LOAD_FAST 1 (x)
           37 CALL_FUNCTION 1 (1 позиционная, 0 пар ключевых слов)
           40 INPLACE_ADD
           41 STORE_FAST 0 (всего)
           44 JUMP_ABSOLUTE 19
      >> 47 POP_BLOCK

5 >> 48 LOAD_FAST 0 (всего)
           51 RETURN_VALUE
  
 Важный бит - строка 4. Как видите, поскольку мы полностью квалифицируем  math.sin , мы должны:
  LOAD_GLOBAL  символ модуля  math .
  LOAD_ATTR  символ  sin .
 Где (2) в конечном итоге означает поиск по словарю (хеш-таблице). Понимая динамическую природу Python, мы можем предположить, что кэширование и сохранение символа  math.sin  в локальной переменной может значительно улучшить производительность нашего кода в тесном внутреннем цикле.Посмотрим:
  по умолчанию в секунду ():
  грех = math.sin
  всего = 0
  для x в диапазоне (1000):
    всего + = грех (х)
  общая сумма возврата
  
 и в разобранном виде:
  2 0 LOAD_GLOBAL 0 (математика)
            3 LOAD_ATTR 1 (грех)
            6 STORE_FAST 0 (грех)

3 9 LOAD_CONST 1 (0)
           12 STORE_FAST 1 (всего)

4 15 SETUP_LOOP 36 (по 54)
           18 LOAD_GLOBAL 2 (диапазон)
           21 LOAD_CONST 2 (1000)
           24 CALL_FUNCTION 1 (1 позиционная, 0 пар ключевых слов)
           27 GET_ITER
      >> 28 FOR_ITER 22 (к 53)
           31 STORE_FAST 2 (x)

5 34 LOAD_FAST 1 (всего)
           37 LOAD_FAST 0 (грех)
           40 LOAD_FAST 2 (x)
           43 CALL_FUNCTION 1 (1 позиционная, 0 пар ключевых слов)
           46 INPLACE_ADD
           47 STORE_FAST 1 (всего)
           50 JUMP_ABSOLUTE 28
      >> 53 POP_BLOCK

6 >> 54 LOAD_FAST 1 (всего)
           57 RETURN_VALUE
  
 Если мы теперь посмотрим на внутренний цикл (строка 5), мы увидим, что мы заменили последовательность  LOAD_GLOBAL ,  LOAD_ATTR  на  LOAD_FAST  - поиск одиночной локальной переменной. Как следует из названия, это будет намного быстрее (предположительно). Давайте проверим:
  В [1]: timeit.timeit ('f ()', globals = dict (f = first), number = 100000)
Выход [1]: 27.1769976962

В [2]: timeit.timeit ('f ()', globals = dict (f = second), number = 100000)
Выход [2]: 15.568848820985295
  
 Ну, я не знаю вашего определения «намного быстрее», но множитель (почти) два в моей книге намного быстрее.
 Интерпретация байт-кода 
 Дизассемблированные инструкции байт-кода уже достаточно низкоуровневые (файл.к.а. здорово). Однако мы можем пойти еще глубже и понять сам код  байт  - то есть двоичное или шестнадцатеричное представление инструкций в скомпилированном и собранном байт-коде. Для этого давайте определим функцию и еще немного поработаем с ее свойством  __code__ :
  функция def ():
  х = 5
  l = [1, 2]
  вернуть len (l) + x
  
 Через  function .__ code__  мы можем получить доступ к объекту кода, связанному с функцией. Кроме того, функция  .__ code __. Co_code  возвращает фактический байт-код:
  In [1]: function .__ code __. Co_code
Out [1]: b'd \ x01 \ x00} \ x00 \ x00d \ x02 \ x00d \ x03 \ x00g \ x02 \ x00} \ x01 \ x00t \ x00 \ x00 | \ x01 \ x00 \ x83 \ x01 \ x00 | \ x00 \ x00 \ x17S '
  
 Да! Байтов! Как раз то, что я люблю на завтрак. Но что мы можем сделать из этих восхитительных кусочков байт-кода? Что ж, мы знаем, что эти байты определяют инструкции, некоторые из которых принимают аргументы, а некоторые нет. Каждая инструкция будет занимать один байт, а аргументы (например, индексы в имени и таблице констант) будут занимать дополнительные байты.Кроме того, к счастью, модуль  dis  (а также модуль кода операции  ) предоставляет таблицу  opname  и карту  opmap . Первый представляет собой простой список, составленный таким образом, что его индексация с помощью кода операции инструкции возвращает имя ( мнемоника ) этой инструкции. Последний,  dis.opmap , сопоставляет мнемонику инструкций с номерами их байт-кода:
  В [1]: dis.opname [69]
Выход [1]: 'GET_YIELD_FROM_ITER'

В [2]: дис.opmap ['LOAD_CONST']
Вых [2]: 100
  
 Итак, если мы знаем значение байта, описывающее определенную инструкцию, теперь мы знаем, как получить имя инструкции. Осталось только интерпретировать аргументы этих инструкций. Для этого нам нужно знать, принимает ли инструкция аргументы в первую очередь. Чтобы получить эту информацию, мы можем использовать  dis.hasconst ,  dis.hasname ,  dis.hasjrel  и  dis.hasjabs  и другие. Каждый из них представляет собой списки в модуле  dis , которые содержат байт-коды, принимающие либо постоянный аргумент, либо аргумент имени, либо цель относительного / абсолютного перехода или другой тип параметра.Например,  dis.hasnargs  также является таким списком, содержащим все коды операций, относящиеся к вызовам функций, такие как  CALL_FUNCTION ,  CALL_FUNCTION_VAR  (для функций, принимающих  * args ) или  CALL_FUNCTION_KW  (для функций, принимающих  * * kwargs ). Примечательно, что если инструкция вообще принимает аргументы, она может принимать только один аргумент, занимающий ровно 16 бит (два байта).
 Запись собственного байт-кода 
 Для практики и развлечения мы теперь можем сами написать некоторый байт-код.Скажем, например, мы хотели записать в байт-коде  x = 1 + 2 . Это равносильно первой загрузке констант  1  и  2  в стек с использованием  LOAD_CONST  с кодом операции  100  ( 0x64 ). Затем мы выполняем  BINARY_ADD  (код операции  23 / 0x17 ), который выталкивает эти два значения из стека и возвращает результат (3) наверх. Затем мы выполним  STORE_NAME  (код операции  125 / 0x7d ), чтобы извлечь результат из стека и сохранить его в единственной переменной, которая у нас будет, т.е.е. с индексом 0. Это равняется:
  0 LOAD_CONST 0 # 0x64
3 LOAD_CONST 1 # 0x64
6 BINARY_ADD # 0x17
7 STORE_NAME 0 # 0x7d

consts = (1, 2)
имена = ('х',)
  
 или в (десятичных) байтах:
  100 0 0 # consts [0]
100 1 0 # consts [1]
23 # без аргументов
125 0 0 # имен [0]
  
 Обратите внимание, что компилятор фактически оптимизирует  1 + 2  до константы  3 , как вы заметите, если вы запустите  dis. dis ('x = 1 + 2') .Кроме того, когда вы запустите  dis.dis , вы увидите, что код, похоже, возвращает  None  в конце. Это просто деталь реализации cPython, связанная с тем, что он написан на C и всегда требует возвращаемого значения (даже для кода вне функций).
 Дизассемблирование также сообщает нам, что одна инструкция  LOAD_CONST  занимает три байта. Один для кода операции и два для 16-битного параметра. Наконец, важно отметить, что аргументы хранятся в формате  little endian .Вот почему  LOAD_CONST 1  - это  100 1 0 , синус  0b00000001 0b00000000  -  1  с прямым порядком байтов.
 Написание дизассемблера 
 Учитывая всю эту информацию, мы теперь более чем готовы написать собственный небольшой дизассемблер байт-кода. Мы просто возьмем байтовую строку, например, возвращенную атрибутом  co_code  объекта кода, и переберем ее байты. Нам нужно будет прочитать байты для декодирования инструкций и выбрать правильное количество последующих байтов для аргументов. Кроме того, мы хотим использовать  co_lnotab  и  co_firstlineno  для перекрестных ссылок между байт-кодом и исходным, дизассемблированным кодом. Вы можете найти небольшую реализацию (~ 300 строк), следуя этим идеям, здесь.
 Outro 
 Многие люди любят Python за скорость разработки, которую обеспечивает высокоуровневый интерфейс программирования с высокой степенью абстракции. Тем не менее, каждый язык программирования высокого уровня обладает огромной глубиной загадок низкоуровневой реализации, которые дают вам представление о внутренней работе языка и позволяют принимать более обоснованные решения относительно критически важных для производительности оптимизаций.При этом не забывайте, что существует множество других языков, таких как современный C ++, Rust, Go и даже Java, которые будут быстрее, чем даже наиболее оптимизированный код Python (обычно), и обеспечат достаточно интуитивно понятные интерфейсы. Таким образом, рассматривайте то, что вы только что узнали, как полезные знания для редких крайних случаев и забавные мелочи, о которых можно поговорить с бабушкой за воскресным чаем, но не как приглашение разобрать всю вашу кодовую базу и оптимизировать отдельные инструкции.
 Ресурсы 
 Вот еще несколько ресурсов и ссылок, в которых я черпал вдохновение и знания:
 Что понимается под разборкой и разборкой труднодоступных Apple AirPods? 
  21.12.2016 15:00:00 
 Беспроводные наушники Apple объявили вместе с iPhone 7/7 Plus о прекращении производства разъема для наушников « AirPods ».  Появился в интернет-магазине 14 декабря 2016 г. настоящий момент  Подождите 6 недель  Это продукт, которому уделяется повышенное внимание.Отчет о том, что ценные AirPods были куплены и разобраны в спешке, был выпущен iFixit.
  AirPods Teardown - iFixit  
  https://www.ifixit.com/Teardown/AirPods+Teardown/75578 
 AirPods разделен на две части: беспроводной наушник и специальный чехол. 
 Сначала разложим беспроводной наушник. 
 Поскольку пластиковый корпус снаружи беспроводного наушника не имеет стыковочной поверхности, мы разрезаем его ножом и разбираем. Перед резкой сниму AirPods рентгеном и проверю внутри. 
 Учитывая, что внутри беспроводного наушника используется клей, в первую очередь прогреем весь беспроводной наушник. 
 Режьте ножом в тепле. 
 Сделав надрез по окружности ножом, можно вскрыть киркой. 
 Внутри есть мелкие детали, такие как фундамент и кабель. 
 Обрежьте нижнюю часть наушника ножом, чтобы вынуть внутренние части.Металлическая часть, прикрепленная к нижней части наушника, является частью, которая становится точкой контакта с аккумулятором, когда помещается в специальный футляр. 
 Поскольку он затвердел с помощью клея, удалить металлические части было довольно сложно. Внутри есть аккумулятор. 
 Затем я отрежу длинную часть, которая становится туловищем AirPods по вертикали. 
 Осторожно разрежьте пластиковый корпус пинцетом ... ... 
 Удачно вытащив антенну и аккумулятор.
 Аккумулятор, установленный в беспроводных наушниках, составляет 93 мВтч, что составляет около 1% емкости аккумулятора iPhone 7. 
 Далее мы снимем плату, кабели и т. Д. 
 Красная часть изображения представляет собой микросхему W1 производства Apple, которая улучшает соединение Bluetooth и качество звука. Оранжевая часть - аудиокодек Maxim Integrated « 98730 EWJ » Желтая часть - PSoC Cypress Semiconductor  CY8C4146FN  Должно быть. На этом разложение беспроводных наушников закончено.
 Далее следует разбирать особый кейс. Как и в случае с беспроводным наушником, специальный футляр также разрезается ножом и разбирается. 
 При снятии верхней части спецкейса вылез ленточный кабель. 
 Светодиодный индикатор для уведомления о сопряжении, который был прикреплен к концу ленточного кабеля. 
 Каркас специального футляра будет разрезан с помощью цепной мини-пилы, но мы будем уделять особое внимание, чтобы не повредить внутренние детали.
 Аккумулятор подключается к плате на корпусной части. 
 То, что было установлено, было литий-ионным аккумулятором китайского производства с 1,52 Втч при 3,81 В. 
 Удалите кнопки сопряжения, установленные на задней панели ... ... 
 Удалите очень маленький винт и отделите разъем молнии. 
 Основная плата закреплена на герметичность лентой, и ее трудно снять. 
 На удаленной основной плате микросхема зарядки аккумулятора NXP «1610 A 3» была помещена в оранжевую часть, ST «Micro Electroics»  STM32L072  «В желтой части - ARM произвела»  Cortex-M 0 + процессор  «Был установлен на рынке.
 На этом разборка-разборка завершена. Сложность ремонта, оцененная по разборке, составила «0 баллов» наивысшей сложности из 10 баллов (10 баллов - самая легкая). Наивысшая оценка сложности ремонта: «Невозможно отремонтировать интерьер, не разрушив корпус». Когда AirPods ломается, неплохо было бы принести их в Apple Store, не ремонтируя их самостоятельно. 
 Изучение K240: руководство по разборке и анализу 
 Здесь я документирую процесс, с помощью которого я разбираю и анализирую K240
исполняемый файл. Вы можете найти эту информацию для разборки других игр Amiga,
а также другие игры, в которых использовался процессор 68000, особенно Atari ST и
Игры Megadrive / Genesis.
 Разборка 
 Дизассемблирование - это процесс, который разбирает исполняемую программу и превращает ее
в серию инструкций на языке ассемблера, которые можно проанализировать, если вы
знаю 68к асм.
 Основной инструмент - неинтерактивный дизассемблер под названием IRA.
(Прочти меня
скачать).
Он все еще находится в активной разработке и может быть скомпилирован для работы в Linux (или любой другой
платформа с инструментами GNU), Windows и MacOSX, с включенными двоичными файлами для работы на
AmigaOS 2+, OS4 и MorphOS.
 Disassembly с IRA имеет ту проблему, что он не знает автоматически, что
исполняемый код и что такое данные. Сначала вы хотите запустить его с помощью -PREPROC
функция, которая угадывает границы кода / данных и генерирует файл конфигурации для
использовать в будущих разборках.
  ira -A -KEEPZH -NEWSTYLE -COMPAT = bi -PREPROC playk240
  
 Однако предположения IRA иногда ошибаются, поэтому вам придется
вручную отредактируйте файл .cnf, чтобы исправить это. Все последующие разборки теперь должны
используйте файл конфигурации вместо препроцессора:
  ira -A -KEEPZH -NEWSTYLE -COMPAT = bi -CONFIG playk240
  
 Определение того, что такое код, а что такое данные, требует некоторого технического чутья.Сравните предварительно обработанный файл с необработанным. В предварительно обработанном asm, если
вы видите множество записей данных (например,  DC.L ) с метками внутри них и шестнадцатеричный
числа, которые представляют собой общие инструкции 68k asm (например,  4e75 ), то есть
вероятно, код ошибочно идентифицирован как данные. И наоборот, в необработанном asm
(т.е. ни -PREPROC, ни -CONFIG), если вы видите много строк  DC.L  в
середина кода, или  ORI # 0  (0000 долларов в шестнадцатеричном формате интерпретируется как инструкция), то есть
вероятно, данные неправильно интерпретируются как код. Также часто декларации  EXT_  предлагать данные, неверно интерпретированные как код.
 Вам не нужен идеальный дизассемблер только для того, чтобы проанализировать и понять код,
но чем ближе ты подойдешь, тем лучше. Это помогает, если вы собираетесь модифицировать nad
пересборка программы.
 Есть и другие известные инструменты, но я не использовал их для этого.
проект:
 ReSource v6.06 - коммерческий интерактивный дизассемблер на Amiga с 1994 года.
Он больше не обновляется и его трудно достать, но многие программисты Amiga используют
это как их основной дизассемблер.Также есть
Ресурсное руководство.
 IDA Pro - популярный интерактивный
дизассемблер, поддерживающий множество платформ. Однако это коммерческое и
дорогой. Есть бесплатная версия, но она не поддерживает 68000.
 Ghidra - интерактивный дизассемблер, написанный
NSA и выпущен для широкой публики в 2019 году. Сторонняя надстройка называется
ghidra_amiga_ldr
позволяет загружать исполняемые файлы Amiga.
 Radare2 - это бесплатный интерактивный
дизассемблер с графическим интерфейсом под названием Cutter.Он поддерживает
процессор 68000, но еще не имеет загрузчика файлов фрагментов Amiga.
 Преимущество ReSource в том, что он автоматически пытается определить тип
переменных и т. п. в зависимости от того, как на них ссылаются, и ставит перед ним префикс
строка типа.
 Обучение и справочная информация 
 Очевидно, чтобы понять дизассемблированный код, вам необходимо изучить
68000 ассемблер, если вы еще не знаете его. Самая коммерческая Amiga
игры, включая K240, писались непосредственно на 68k ассемблере, а не на
язык высокого уровня, такой как C или AMOS Basic, поэтому нет значимого способа
«Декомпилировать» такие игры на язык более высокого уровня.
 Некоторые полезные ресурсы включают:
 Анализ 
 Разобраться в такой сложной игре, как K240, непросто. Во-первых, как и большинство
Игры для Amiga, K240 изначально собирался без отладочных символов, что означает, что
у вас нет имен переменных, с которыми можно было бы работать. Также нет комментариев, которые могут вам помочь.
 Однако есть несколько подходов, которые могут помочь.
 Попробуйте найти текстовые строки. Здесь может помочь опция IRA  -TEXT = 1 .
 Попробуйте найти известные числа или их шестнадцатеричные эквиваленты.Примеры
включают известные цены на корабли и начальную стоимость валюты.
 Во многих играх Amiga использовался генератор случайных чисел, засеянный из текущего
положение луча ЭЛТ на экране. Ищите ссылки на ВХПОСР
($ DFF006) или, возможно, VPOSR ($ DFF004). Случайность, как правило, используется больше в
стратегические игры и ролевые игры, поэтому, как только вы определите генератор случайных целых чисел
функцию, вы можете использовать это, чтобы сосредоточиться на коде, определяющем правила игры.
 Ссылки на четыре аудиоканала от AUD0LCH до AUD3LCH (от $ DFF0A0 до $ DFF0D0)
может идентифицировать события, вызывающие звук, например удары или повреждение.
 Ссылки на вызовы библиотеки Amiga из игр, совместимых с ОС, могут определить полезные
информация, в частности, чтение / запись файлов в  dos. library .  JSR (-552, Ан)  это открытая библиотека, и с  dos.library  мы можем искать `JSR` до -30
(открытый), -42 (чтение) и -48 (запись). В частности, области памяти, записанные в
файл сохранения игры обычно содержит все состояние игры.
 После того, как вы определили назначение ярлыка, дайте ему имя. Как только вы
понял функцию раздела кода, вы также можете добавлять комментарии.
 В IRA есть два основных подхода к этому. Один из способов - просто
найти-заменить все варианты использования этого имени метки в файле дизассемблирования (.asm) и
добавлять комментарии напрямую. Это просто, но иногда вызывает ошибки,
например когда вы по ошибке даете двум ярлыкам одно и то же имя.
 Другой способ в текущей версии IRA - добавить названия ярлыков и комментарии.
в файл .cnf, затем повторно запустите IRA, чтобы добавить их в .asm. Это помогает избежать
баги, и позволяет повторно разобрать (например,г. для исправления ошибок границы кода / данных)
без потери прогресса. Имена ярлыков и комментарии добавляются в .cnf
с директивами SYBOL, COMMENT и BANNER (см.  ira_config.doc ). Другой
полезные директивы включают TEXT, JMPB, JMPW, JMPL и EQU.
 Повторная сборка 
 Способ проверить, какие части кода делают, - это изменить код и перестроить его.
снова в рабочую программу.
 Идеальный инструмент для этого - VASM, ассемблер, который все еще активен.
разработка и позволит вам компилировать исполняемые файлы Amiga.
 Чтобы разобрать так, чтобы VASM правильно перестроил,
Ридми IRA
предлагает сначала разобрать со следующими вариантами:
  -compat = bi 
 Включает два флага совместимости, которые помогают обеспечить правильную сборку программ.
изначально собрана некоторыми сборщиками.  -кипж 
 Сохранять нулевые фрагменты, то есть пустые разделы. K240 это не нужно, но некоторые программы
может использовать это.
 Для повторной сборки документы IRA рекомендуют:
  vasmm68k_mot -no-opt -Fhunkexe -nosym -O playk240 playk240. 68k.asm
  
 Ключ здесь -  -no-opt , который отключает оптимизацию, которая может изменить способ
ваш код пересобран. Исходный исполняемый файл игры, вероятно, уже был
оптимизирован при первой сборке, поэтому дальнейшая оптимизация не требуется,
и может действительно сломать вещи.
 Параметр  -nosym  отключает символы отладки. Если вы его не укажете, vasm построит
все ваши имена ярлыков в исполняемый файл, что увеличит размер файла.
Однако, если вы используете отладчик WinUAE для просмотра кода, вам действительно нужно
чтобы исключить эту опцию, потому что вы хотите, чтобы имена меток не менялись.
 Отладка 
 Еще один полезный инструмент для понимания программного обеспечения Amiga - отладчик WinUAE,
что позволит вам пройти через программу. Нажмите Shift + F12, чтобы приостановить эмулятор.
и загрузите отладчик, затем введите команду «h», чтобы получить список команд.
Возможно, вам потребуется включить отладчик в параметрах.
 Некоторые советы по отладке сборки в WinUAE есть в
эта ветка.
 Вы также можете экспортировать состояние сохранения (сначала включить несжатые состояния сохранения) и
анализировать или заклинать редактировать это.
 Анализ других файлов 
 Maptapper - это инструмент для копирования Amiga.
графика из дампа памяти. Настройте WinUAE для создания только несжатого сохранения
заявляет, и убедитесь, что ваша эмулируемая Amiga не имитирует больше оперативной памяти, чем необходимо,
так что у вас не будет много места для поиска.
 Maptapper и подобные программы, такие как GfxRip, сложно использовать, поскольку вы должны
вручную найти границы спрайта.
 Track2File и xdfmaster - удобные программы Amiga для распаковки упакованных файлов.В документации Track2File также описаны форматы некоторых игр Amiga,
которые часто являются существующим форматом с ведущим заголовком из четырех символов
изменил на что-то другое, чтобы замаскировать метод сжатия.
 «Вернуться на главную страницу
 ПЕРСОНАЖЕЙ РАЗОБРАННО !: ПОНИМАНИЕ, КАК ФАНАТЫ ИНТЕРПРЕТАЮТ ПЕРСОНАЖИ ИЗ TRANSMEDIA SUPERHERO FRANCHISES 
 Используйте этот идентификатор для цитирования или ссылки на этот элемент:  https: // scholarbank.nus.edu.sg/handle/10635/165234 
 Title:
 ПЕРСОНАЖИ РАЗОБРАННЫ !: ПОНИМАНИЕ, КАК ФАНАТЫ ИНТЕРПРЕТАЮТ ПЕРСОНАЖИ С ФРАНЧАЙЗЫ TRANSMEDIA SUPERHERO
 Авторы:
 GAN JING YING
 Ключевые слова:
 супергерой 
 создание смысла 
 трансмедиа 
 когнитивная нарратология 
 карта значения
 Дата выдачи:
 18 апреля 2019 г.
 Образец цитирования:
 GAN JING YING (18.04.2019).ПЕРСОНАЖИ РАЗОБРАННЫ !: ПОНИМАНИЕ, КАК ФАНАТЫ ИНТЕРПРЕТАЮТ ПЕРСОНАЖИ С ФРАНЧАЙЗ TRANSMEDIA SUPERHERO. Репозиторий ScholarBank @ NUS.
 Abstract:
 Франшиза о супергероях трансмедиа представляет своим читателям несколько версий одного и того же персонажа в разных повествовательных цепочках в разных текстах и ​​медиа. С таким большим количеством разных вариантов одного и того же персонажа, как фанаты концептуализируют своих любимых персонажей и что влияет на эти личные конструкции персонажей? Это исследование показало, что через двенадцать полуструктурированных глубинных интервью с самопровозглашенными фанатами их характеры в высшей степени индивидуализированы, подвижны и неотделимы от личных предпочтений и опыта фанатов.Эти конструкции персонажей состоят из черт, событий и связанных с ними повторяющихся символов и могут быть изменены, когда фанат встречает новую информацию посредством перечитывания, личного опыта или достаточно мощного текста. Поклонники также могут когнитивно управлять несколькими различными версиями своего любимого персонажа, сохраняя при этом конструкции своих персонажей отдельно от них. Опираясь на карту материи Эллин Кашак, я предполагаю, что конструкция персонажа веера является продуктом взаимодействий между различными материями на карте материи человека, что приводит к построению персонажа, неотделимому от личности фаната.
 URI:
 https://scholarbank.nus.edu.sg/handle/10635/165234
 Встречается в коллекциях:
 Бакалаврские диссертации 
 
 Показать всю запись об элементе 
 Файлы в этом элементе: 
 Файл
 Описание
 Размер
 Формат
 Настройки доступа
 Версия
 GAN JING YING.pdf
653.02 kB
 Adobe PDF
 ЗАПРЕЩЕНО
 Нет
 Войти
 Элементы в DSpace защищены авторским правом, все права защищены, если не указано иное.
 Дезагрегация белков молекулярными шаперонами 
  Темная сторона сворачивания белков.  Неправильная укладка и агрегация основных клеточных белков - фундаментальная проблема для всех живых организмов.Агрегация даже несущественных белков может привести к изнурительным заболеваниям, таким как диабет II типа, болезнь Альцгеймера, Хантингтона и Паркинсона. Важно отметить, что на сворачивание и агрегацию белков сильно влияет механизм контроля качества клеточных белков, включающий сети молекулярных шаперонов. Не совсем понятно, как именно различные системы шаперонов взаимодействуют для разборки и реактивации агрегированных белков и как действие молекулярных шаперонов влияет на прогрессирование заболевания.
  Сложность определения дезагрегации белка.  Исследование дезагрегации белков молекулярными шаперонами представляет собой серьезную техническую задачу. В общем, агрегирующий белок может быстро заселять гетерогенную смесь собранных состояний, размер которых составляет несколько порядков. Точный путь агрегации или дезагрегации может быть исключительно чувствительной функцией окружающей среды, так что сдвиговые силы, фракционирование или условия растворителя, возникающие во время измерения, могут резко нарушить исследуемое распределение популяции.
 Мы используем различные подходы для изучения дезагрегазных систем как бактерий, так и дрожжей. В одном подходе мы используем флуоресцентно меченые, склонные к агрегации белки, такие как RuBisCO, с измерениями BAS одной частицы для измерения популяционной кинетики разборки белковых агрегатов молекулярными шаперонами.
  Как молекулярные шаперонные сети разбирают белковые агрегаты?  Интересно, что разные организмы организуют свой аппарат дезагрегации белков по-разному, причем большинство бактерий, многие одноклеточные эукариоты и растения используют основную бикаперонную сеть, состоящую из системы Hsp70, связанной с системой Hsp100.Напротив, высшие эукариоты, по-видимому, используют исключительно дезагрегазную систему на основе Hsp70. Не совсем понятно, как именно эти системы молекулярных шаперонов взаимодействуют для разрушения белковых агрегатов.
 В качестве примера того, что может делать система Hsp70, мы исследовали разборку флуоресцентных клатриновых оболочек дрожжевой системой молекулярных шаперонов Hsc70, состоящей из Ssa1p и Swa2p. Клатриновые оболочки - это большие белковые каркасы, которые используются для создания эндоцитарных пузырьков. Они представляют собой идеальную систему для проверки способности БАВ количественно определять разборку наночастиц.Анализ поведения распада больших флуоресцентных вспышек показывает, что процесс разборки покрытия очень кооперативен. См. JBC, 288: 26721 (2013).
 Произошла ошибка при установке пользовательского файла cookie 
 Этот сайт использует файлы cookie для повышения производительности. Если ваш браузер не принимает файлы cookie, вы не можете просматривать этот сайт.
 Настройка вашего браузера для приема файлов cookie 
 Существует множество причин, по которым cookie не может быть установлен правильно. Ниже приведены наиболее частые причины:
 В вашем браузере отключены файлы cookie. Вам необходимо сбросить настройки своего браузера, чтобы он принимал файлы cookie, или чтобы спросить вас, хотите ли вы принимать файлы cookie.
 Ваш браузер спрашивает вас, хотите ли вы принимать файлы cookie, и вы отказались.
 Чтобы принять файлы cookie с этого сайта, нажмите кнопку «Назад» и примите файлы cookie.
 Ваш браузер не поддерживает файлы cookie. Если вы подозреваете это, попробуйте другой браузер.
 Дата на вашем компьютере в прошлом.Если часы вашего компьютера показывают дату до 1 января 1970 г.,
 браузер автоматически забудет файл cookie. Чтобы исправить это, установите правильное время и дату на своем компьютере.
 Вы установили приложение, которое отслеживает или блокирует установку файлов cookie.
 Вы должны отключить приложение при входе в систему или проконсультироваться с системным администратором.
 Почему этому сайту требуются файлы cookie? 
 Этот сайт использует файлы cookie для повышения производительности, запоминая, что вы вошли в систему, когда переходите со страницы на страницу.Чтобы предоставить доступ без файлов cookie
 потребует, чтобы сайт создавал новый сеанс для каждой посещаемой страницы, что замедляет работу системы до неприемлемого уровня.
 Что сохраняется в файле cookie? 
 Этот сайт не хранит ничего, кроме автоматически сгенерированного идентификатора сеанса в cookie; никакая другая информация не фиксируется.
 Как правило, в cookie-файлах может храниться только информация, которую вы предоставляете, или выбор, который вы делаете при посещении веб-сайта.Например, сайт
 не может определить ваше имя электронной почты, пока вы не введете его. Разрешение веб-сайту создавать файлы cookie не дает этому или любому другому сайту доступа к
 остальной части вашего компьютера, и только сайт, который создал файл cookie, может его прочитать.