程序实质
回顾上次内容
-
咱们把 python 源文件
- 词法剖析 失去 词流(token stream)
- 语法分析 失去 形象语法树(Abstract Syntax Tree)
- 编译 失去 字节码 (bytecode)
- 字节码咱们看不懂
- 所以反编译 失去 指令文件(opcode)
- 指令文件是基于 python 虚拟机的虚构 cpu 的指令集
- 什么是 python 虚拟机呢?🤔
- 在理解虚构 cpu 之前
- 咱们先看看实在的 cpu
实在的 cpu
-
无论手机还是计算机
- 最外围器件的器件就是 cpu
- 这个货色是个实实在在存在的实体
- 咱们所说的 python 虚拟机能看到么?
- 就是用来运行 py 文件的
python3
到底是个啥?
which python3
ll /usr/bin/python3
-
这个 python3
- 是一个符号链接文件
- 只有 9 字节
- 他指向 python3.8
-
python3.8
- 也在 /usr/bin 外面
- 就是 /usr/bin/python3.8
- python3.8 是一个 5.3M 的文件
- 能够看得见
- 能够间接运行这个 phthon3.8 吗?
间接运行
/usr/bin/python3.8
-
python3.8
就在硬盘里呆着-
地位就在 /usr/bin/python3.8
- usr 是 unix software resource
- bin 是二进制 binary
- python3.8 是这个文件的名称
-
-
在运行命令的时候
- 把这个文件从硬盘装载到内存
- 而后用 cpu 开始逐行执行文件中的 0101 指令
- 能够把他复制到 shiyanlou 用户的宿主文件夹下吗?
复制
- 复制到 shiyanlou 下
- 再察看
# 把 /usr/bin/python3 这个 py 文件的解释器拷贝到~(以后用户文件夹)
#cp 的意思是 copy
cp /usr/bin/python3 ~
#确认 python3 曾经拷到~(以后用户文件夹)
#ls 的意思是 list
ls ~/python3.8
#查看 python3 文件细节
ls -lah ~/python3.8
-
python3 指向的 python3.8 只有 5.3M
- 这个可执行文件怎么这么小?
- 5.3M 这也就是一张照片的大小
-
以前的 Python3.5 只有 4.3M
- 更小
- 目前这 5.3M 的 Python3 外面到底有什么呢?🤔
钻研 python3
# 用 vi 关上这个刚拷贝过去的 python3
vi ~/python3.8
-
这个样子看起来
- 全是乱码
- 齐全看不懂啊
- 这个货色咱们的确看不懂
- 然而有人能看懂
- 谁呢?
cpu
- cpu 能看懂!!!
-
这些咱们看不懂的乱码
- cpu 能看懂
- 这是属于 cpu 的机器语言
- 这就是 cpu 的一条条的机器指令(instruction)
- 机器指令码都是二进制模式的
- 咱们尝试把 python3.8 转化为字节表现形式
以字节模式察看 python3.8
vi ~/python3.8
- 用 vim 关上~/python3.8
-
:
- 进入命令行模式
-
:%!xxd
咱们能够看到这个文件的二进制状态%
是指的对于所有行的范畴! 是执行外部命令
xxd
指的是转化为 16 进制模式
- 什么是 xxd 命令呢?
xxd
-
xxd 能够查看文件的二进制状态
- dump 的本意是(倾倒垃圾)
- 这里指的是转储
- 把文件转储为 16 进制模式汇编代码模式
-
:xxd –r
能够还原回去 😉:%!xxd
转成字节状态:%!xxd –r
转回文本状态
- 重复横跳 …
另存为 python3.8hex
- 一行是(16)10 进制 个字节
- G 到最初一行
- 总共有 343148 行
-
这就是 真正的机器语言🤭
- cpu 能执行的货色
- 真真切切看到了的
- 真的存在硬盘上 01010 的二进制可执行指令!!
- 这些指令执行进去就是咱们的游乐场!!!
- 或者说是咱们的 python 虚拟机
- 可是这个指令咱们看不懂怎么办?🤔
-
先把他另存进去
- :w python3.8hex
- 把以后缓存 (buffer) 另存 (write) 为
- python3.8hex
-
对 python3.8 强制退出
- :q!
- 不保留批改强制退出
- python3.8hex 就是咱们要的机器语言的字节状态
- 可是这字节状态咱们看不懂啊
汇编语言助记符
# 先把~/python3 对应的机器语言输入为汇编指令模式(反汇编)
objdump -d python3.8 > python3.8.asm
vi python3.8.asm
-
这次真的能够看懂了
- 减法(sub)
- 挪动(mov)
- 这些指令
- 能够发现以后零碎的架构 (指令集) 是 x86-64
- 这些和咱们方才的字节状态有关系吗?
比照
- 用 vi 分窗口别离关上关上 python3 和 python3.asm
vi -o python3.8hex python3.8.asm
- 下图中上半局部是机器语言
- 上图下半局部是机器语言对应的汇编指令助记符
- ctrl+j、ctrl+k能够高低切换
-
咱们来试着找找
- python3 文件中
- 机器语言的 0101 和 cpu 的汇编指令的对应关系🧐
找到了
-
先跳过上面窗格的第 8 行
- endbr64 意味着 64 位完结分支
- 上面的 sub 执行的是减法
-
上面窗格的 第 9 行
/48 83
找到高低的对应关系- 也就是第一条执行的汇编指令减法(sub)
- 汇编指令是计算机 cpu 机器指令的助记符
查找对应关系
423000
就是初始化 (init) 的 cpu 开始执行指令的地址-
咱们在下面查找 48 83 有没有对应的字节
- /4883 ec08 488b…
- 在下面的窗格中
- 搜寻这些字节状态
- 如同找到了对应关系
- 具体怎么对应的呢?
- 这台计算机用的是什么指令集呢?
- 什么是指令集来着?
指令集
- 指令集就是指令的汇合
- 指令集也叫计算机的架构
-
不同架构的 cpu 有不同的指令集
- 咱们目前的这个浏览器外面的零碎用的是
x86-64
- 除此之外
arm
、MIPS
、RISC-V
也是罕用的指令集
- 咱们目前的这个浏览器外面的零碎用的是
- 指令助记符和机器语言到底是则怎么对应的呢?
回到代码
-
代码会有不同的
section
模块- 入口是
init
- 作用是初始化
initialization
- 入口是
-
模块外面是具体的指令
- 比方第一句
48 83 ec 08
- 比方第一句
- 为什么 48 83 就能够代表减法
- 这是谁规定的呢?
查看指令集
-
这是 cpu 架构规定的
- 首先要明确到以后机器 cpu 的架构
- 反汇编外面说是 x86-64
- 到 shell 外面验证一下
- 以后机器所用的架构指令集的确是 x86_64
- 这是谁的架构呢?
搜寻
- 不会了就去搜寻😄
- 去 intel 官网找指令集
查问 x86_64 指令集
-
找到 cpu 的手册
- https://www.intel.com/content…
-
能够找到指令和二进制状态之间的关系么?
- 先要找到 x86-64 指令集中 48 83 这条指令
-
留神上图中
- 100B 中的 B 是 0 或 1
- 100B 能够是 1000
- 也能够是 1001
-
这的确是一条减法指令
- 而且是 8 位立刻数和寄存器的减法运算
逐渐搜寻
-
找起来真的很吃力
48 83 ec 08
对应sub $0x8,%rsp
- 的确是一条减法指令
- 的确是 8 位立刻数和寄存器的减法运算
-
和 objdump 的后果是统一的
- 废话!!!😠
- 除了减法指令 sub 之外
- 还有什么别的指令呢?
各种 cpu 指令
-
指令那可还有很多的
- 有运算的
- 有移位的
- 加减乘除都有
-
这些指令的汇合就是指令集
- 指令集就是 cpu 运行的根底!
- 这些机器语言的指令不能在别的指令集架构上运行么?
移植 port
-
想在别的指令集架构上运行程序
- 就须要移植(port)
- 移植 (port) 指的是从一种指令集移植到另一种指令集
-
从这个词的词源
-
能够看出欧美的航海文化根底
- port 港口
-
也能够看出咱们的农耕文化根底
- 移植
-
- 不移植会如何呢?
不移植
-
这是 playstation2 的架构图
- cpu 是 mips 架构的
-
不移植的话
- 就是让 x86 架构的 pc
- 去间接执行这些基于 mips 架构的的 0101…
-
就像让一个意大利泥瓦匠看一份中文写成的烹饪书来砌墙
- 鸡同鸭讲
- 驴唇不对马嘴
- 0101 的文件执行进去全是乱的
- 齐全不能用
-
而且不全是软件的问题
- 也波及到硬件等方面
- 可能某个寄存器在新架构中基本就不存在
架构师
- 这个时候架构师要解决相当多的问题
- 很不容易的
-
落实到咱们的 python3.8 游乐场
- 咱们的 python3.8 就是这样的一系列的 cpu 指令
- 能够解释 py 文件的
- python3.8 又是如何解释 py 文件的来着?
python3 执行过程
- 不论是 python3 这个游乐场
- 还是 hello.py 这个 python 程序
- 都在咱们的硬盘上
- 先得把文件从硬盘读到内存
python3 执行的过程大抵是这样
-
先把 python3.8 这个主解释器加载到内存中
- 而后在 x86-64 的 cpu 上执行
- 模拟出一台 python 虚拟机
- 筹备开始对 py 文件解释执行
先编译
-
而后把参数
hello.py
这个须要执行的程序加载到内存- 词法剖析 失去 词流(token stream)
- 语法分析 失去 形象语法树(Abstract Syntax Tree)
- 编译 失去 字节码 (bytecode)
- 也就是编译后的 pyc 文件
解释执行
-
不过这个 pyc 指令文件
- 是基于 python 虚拟机的虚构 cpu 的指令集的
- 须要放到模仿好的 python 虚拟机中
- 一条条指令进行执行
换句话说
-
简化版的 hello.py 的执行过程是:
- 给了
python3
一个参数hello.py
- 应用
python3
这个解释器来解释执行hello.py
hello.py
中的语句一句句地顺次解释执行
- 给了
-
全解释实现后
- 退出 python 这个程序
- 把控制权交回到 shell
-
这些都是基于解释器 python3.8 的
-
所谓的解释器也是
- 先编译成 python 虚拟机的字节码
- 而后用 python 虚拟机解释间接执行
-
-
而解释器 (python3) 是在不同零碎不同架构的 cpu 语言上运行的
- 那不同的零碎、cpu 架构
- python 都能正确地解释么?
架构的档次
-
不同架构的 cpu 都能够运行 python
- risc-v
- arm
- x64
- mips
- 龙芯
-
不同零碎的环境都能够运行 python
- win
- mac
- linux
- freebsd
跨架构跨平台原理
-
因为 python3 能够运行在不同的 cpu 架构和零碎上
- 所以同样的 py 文件被加载之后
- python 程序能够对 py 文件跨架构、跨零碎进行解释执行
- 一次编写到处运行
-
不同的架构
- 二进制对应的汇编指令都不一样
- 怎么能正确解释执行同样的 python 程序呢?
跨架构跨平台原理
-
/usr/bin/python3.8
自身是二进制文件- 是基于以后操作系统以后架构编译进去的可执行二进制文件
- 不同的架构有不同的编译器
- 不同的编译器编译进去的 python3.8
- 是不同的二进制指令序列
-
python3.8
构建了一个运行时环境- 这个环境能够解释读到的
python 语句
- 把
python 语句
翻译成零碎能读懂输入输出 - 翻译成以后架构可能执行的代码
- 这个环境能够解释读到的
- 而后边解释边执行
- 祝贺您实现了十分烧脑一个试验!
- 咱们去总结吧!!!
总结
-
python3
的程序是一个 5.3M 的可执行文件python3
外面全都是 cpu 指令- 能够执行的那种
-
咱们能够把指令对应的汇编找到
objdump -d ~/python3 > python3.asm
-
汇编语句是和以后机器架构的指令集相干的
uname -a
能够查问指令集
-
咱们执行的过程其实就
- 零碎执行
python3
这个可执行文件 - 给了
python3
一个参数hello.py
python3
对于hello.py
一句句的解释执行- 在显示器输入了
hello world
python3
执行结束- 把控制权交回给 shell
- 零碎执行
- 这就是咱们执行
hello.py
的过程 - 为什么咱们学编程总是从
hello world
开始呢?🤔 - 咱们下次再说!👋
- 蓝桥 ->https://www.lanqiao.cn/teache…
- github->https://github.com/overmind19…
- gitee->https://gitee.com/overmind198…
- 视频 ->https://www.bilibili.com/vide…