一文看透指令集微架构CPU

Posted 2023-03-30 CAE虚拟与现实

一、微处理器的指令集架构（Instruction Set Architecture）分类

复杂指令集运算（Complex Instruction Set Computing，CISC）；

精简指令集运算（Reduced Instruction Set Computing，RISC）；

显式并行指令集运算（Explicitly Parallel Instruction Computing，EPIC）；

超长指令字指令集运算（Very Long Instruction Word，VLIW）；

最常见的是CISC和RISC。

二、仔细品品四种指令集

1、CISC:从计算机诞生以来，人们一直沿用CISC指令集方式。在CISC微处理器中，程序的各条指令是按顺序串行执行的，每条指令中的各个操作也是按顺序串行执行的。顺序执行的优点是控制 简单，但计算机各部分的利用率不高，执行速度慢。CISC是目前家用机的主要处理器类型。

基于CISC指令集的处理器有哪些？

>>>>>目前X86架构微处理器如Intel的Pentium/Celeron/Xeon与AMD的Athlon/Duron/Sempron；以及其64位扩展系统的x86-64的架构的EM64T的Pentium/Xeon与AMD64的Athlon 64/Opteron都属于CISC系列。

>>>>>主要针对的操作系统是微软的Windows。

2、RISC:RISC是在CISC指令系统基础上发展起来的，有人对CISC机进行测试表明，各种指令的使用频度相当悬殊，最常使用的是一些比较简单的指令，它们仅占指令总数的20％，但在程序中出现的频度却占80％。复杂的指令系统必然增加微处理器的复杂性，使处理器的研制时间长，成本高。并且复杂指令需要复杂的操作，必然会降低计算机的速度。基于上述原因，20世纪80年代RISC型CPU诞生了，相对于CISC型CPU，RISC型CPU不仅精简了指令系统，还采用了一种叫做“超标量和超流水线结构”，大大增加了并行处理能力。相比CISC而言，RISC的指令格式统一，种类比较少，寻址方式也比复杂指令集少，它只要求硬件执行很有限且最常用的那部分执令，大部分复杂的操作则使用成熟的编译技术，由简单指令合成。目前在中高档服务器中普遍采用这一指令系统的CPU，特别是高档服务器全都采用RISC指令系统的CPU。

基于RISC指令集的处理器有哪些？

>>>>>IBM的PowerPC处理器、SUN公司SPARC处理器、HP公司的PA-RISC处理器、MIPS公司MIPS处理器、Alpha处理器以及ARM都采用了RISC指令集，。

>>>>>目前只有UNIX，Linux，MacOS等操作系统运行在RISC处理器上。

3、VLIW:一种非常长的指令组合，它把许多条指令连在一起，增加了运算的速度。 VLIW的基本思路是:处理器在一个长指令字中赋予编译程序控制所有功能单元的能力，使得编译程序能够精确地调度在何处执行每个操作、每个寄存器存储器读和每个转移操作。实际上，编译程序创立每个程序的执行记录，计算机则反演该记录。在早期的VLIW计算机中，如果编译程序出错，计算机将产生错误的结果，计算机没有逻辑来检验是否以正确的次序来读寄存器、是否重复使用资源。

基于VLIW指令集的处理器有哪些？

>>>>>目前基于这种指令架构的微处理器主要有Intel的IA-64和AMD的x86-64两种

>>>>>主要操作系统有微软安腾版的Windows系统、UNIX系统等。

4、EPIC:EPIC从VLIW中衍生出来。EPIC指令构架也叫做“IA-64架构”。每时钟周期例如IA-64可运行20条指令，而CISC通常只能运行1-3条指令，RISC能运行4条指令，可见VLIW要比CISC和RISC强大的多。

三、MIPS、ARM和X86架构又是什么，和指令集什么关系？

处理器（CPU）架构就是处理器的硬件架构，称为微架构。是一堆硬件电路，去实现指令集所规定的操作运算。其实就是CPU的集中电路图纸，用来实现我们我们这些指令集，从而通过指令集就可以操作电路进而操作硬件。所以指令集决定了处理器的架构，因为处理器架构就是用硬件电路实现指令集。但是具体用什么样的处理器架构，设计怎样的硬件电路，每个人设计的都可以不一样。

当今处理器一共有三个最强大的架构，其中之一是以Intel和AMD为代表的X86架构，另外一个是手机，平板处理器所使用的ARM架构，最后一个便是我国龙芯处理器所选择的MIPS架构。

换句话说就是：X86架构是建立在CISC指令集上开发的CPU架构；ARM是建立在RISC指令集上开发的CPU架构；MIPS也是建立在RISC指令集上开发的CPU架构；

从某些方面来看，MIPS和ARM非常相似，都是采用精简指令集，都是针对低功耗应用设计，而且都是采用第三方授权方式生产；但实际上两者也有几大的不同，学院派的MIPS允许第三方对CPU架构进行大幅修改，而ARM只允许全球极少的几家半导体公司修改CPU架构（包括高通、苹果、NVIDIA和三星，全是半导体大拿），其他生产ARM芯片的公司都是直接采用ARM公版设计，而不能做任何修改（例如华为海思）。ARM的这项策略显然很适合商业推广，对第三方公司的技术要求也有所降低，开发的周期也会大大缩短，只需要照着ARM公版的CPU和GPU架构找芯片代工厂下单、流片、生产即可。

中国龙芯采用的都是64位MIPS指令架构，它与大家平常所知道的X86指令架构互不兼容，MIPS指令架构由MIPS公司所创，属于RISC体系。过去，MIPS架构的产品多见于工作站领域，索尼PS2游戏机所用的"Emotion Engine"也采用MIPS指令，这些MIPS处理器的性能都非常强劲，而龙芯2也属于这个阵营，在软件方面与上述产品完全兼容。普通用户关注MIPS主要还是因为我国所谓的"龙芯"。龙芯一开始抄袭MIPS，后来购买到了授权。倒也并非龙芯不想发展X86架构的桌面CPU市场或者ARM架构的移动设备市场，是因为这两家的授权太过于苛刻。X86的授权Intel已然不可能再授权。ARM是一家芯片设计公司，只能给出使用授权，不会同意让龙芯自行设计。只有MIPS才可行，MIPS的授权说白了就是随便抄随便改。很多龙芯的支持者提出了MIPS在理论上有诸多的领先，但不要忘了ARM是一家商业公司，市场占有率高，竞争意识也非常强。几乎所有的智能手机都是ARM架构，就是最有力的证明。

四、再来看看什么是汇编语言

汇编语言是用人类看得懂的语言来描述指令集。否则指令集的机器码都是一堆二进制数字，也就是机器语言，人类读起来非常麻烦，但汇编是用类似人类语言的方式描述指令集，读起来方便多了。要设计处理器，首先就需要有指令集，规定处理器相应操作，通过指令集去控制处理器实现相应功能。但处理器是一堆硬件电路，只能识别二进制数据，所以指令集是由一堆二进制数据组成。而二进制数据对人类来说读起来很麻烦。为了方便人类操作指令集，发明了汇编语言来描述指令集。汇编语言类似人类语言，读起来方便多了，至于汇编语言怎么转换成机器语言，是通过对应得汇编器来转换的。

虽然汇编语言读起来方便了，但也有缺陷。首先汇编语言操作起来还是挺麻烦的。其次汇编语言对应一条条指令集，所以当指令集改变时，就得修改相应汇编语言，导致其可移植性很差，不能跨平台使用，如ARM的汇编语言与Intel X86的就不同。这时人们就想开发一种更方便操作，超越指令集的语言，于是有了C，C++等高级语言。

但处理器只能识别二进制码，那怎么能识别高级语言呢？于是人们开发了编译器，依照如下顺序，将高级语言翻译成二进制码： 高级语言 汇编语言 二进制机器码。至此，人类可以很方便的利用高级语言编写程序，控制处理器完成相应功能。然后程序员这个红火的职业就此大规模诞生了。

五、小结

经常有人会提到ARM架构、X86架构，也会说到某某处理器采用了ARM或者X86，记得计算机（台式机、平板、笔记本）里面能看到的那个东西叫CPU(中央处理器），是指令集或者微架构的物理实现，那个玩意都是有说的制造他的厂家，例如Intel处理器、ARM处理器、海思处理器、龙芯处理器，这些处理器都采用的那些架构就是前面提到的微架构（硬件架构），就是ARM架构、X86架构或者MIPS架构，这些架构再往上的区别就是指令集区别了，包括CISC、RISC、VLIW和EPIC，这些以后跟别人说起来的时候也能让自己逼格高一点。

一文看透浏览器架构

在从事前端开发过程中，浏览器作为最重要的开发环境，浏览器基础是是前端开发人员必须掌握的基础知识点，它贯穿着前端的整个网络体系。对浏览器原理的了解，决定着编写前端代码性能的上限。浏览器作为JS的运行环境，学习总结下现代浏览器的相关知识

前言
经常听说浏览器内核，浏览器内核究竟是什么，以及它做了什么。我们将来了解下浏览器的主要组成部分、现代浏览器的主要架构、浏览器内核、浏览器内部是如何工作的

1 浏览器
现代浏览器结构如下：

The browser‘s main component

The User Interface
主要提供用户与Browser Engine交互的方法。其中包括：地址栏(address bar)、向前/退后按钮、书签菜单等等。浏览器除了渲染请求页面的窗口外的所有地方都属于The User Interface
The Browser Engine
协调（主控）UI和the Rendering Engine，在他们之间传输指令。 提供对The Rendering Engine的高级接口，一方面它提供初始化加载Url和其他高级的浏览器动作（如刷新、向前、退后等）方法。另一方面Browser Engine也为User Interface提供各种与错误、加载进度相关的消息。
The Rendering Engine
为给定的URL提供可视化的展示。它解析JavaScript、Html、Xml，并且User Interface中展示的layout。其中关键的组件是Html解析器，它可以让Rendering Engine展示差乱的Html页面。 值得注意：不同的浏览器使用不同的Rendering Engine。例如IE使用Trident，Firefox使用Gecko，Safai使用Webkit。Chrome和Opera使用Webkit（以前是Blink）
The Networking
基于互联网HTTP和FTP协议，处理网络请求。网络模块负责Internet communication and security，character set translations and MIME type resolution。另外网络模块还提供获得到文档的缓存，以减少网络传输。为所有平台提供底层网络实现，其提供的接口与平台无关
The JavaScript Interpreter
解释和运行网站上的js代码，得到的结果传输到Rendering Engine来展示。
The UI Backend
用于绘制基本的窗口小部件，比如组合框和窗口。而在底层使用操作系统的用户界面方法，并公开与平台无关的接口。
The Data Storage
管理用户数据，例如书签、cookie和偏好设置等。
2 主流浏览器的架构
2.1 FireFox

FireFox的架构

可以看到火狐浏览器的渲染引擎（Rendering Engine）使用的是Gecko；XML Parser解析器是Expat；Java Script解释器是Spider-Monkey（c语言实现）

2.2 Chrome

Chrome的架构

渲染引擎Rendering Engine使用的是WebKit

XML Parser： libXML解析XML，libXSLT处理XSLT

JS解释器使用C++实现的V8引擎，

2.3 IE

IE的架构

渲染引擎主要是Trident

Scripting Engine有JScript和VBScript

3 浏览器内核
浏览器最重要或者说核心的部分是“Rendering Engine”，可大概译为“渲染引擎”，不过我们一般习惯将之称为“浏览器内核”。主要包括以下线程：

3.1 浏览器 GUI 渲染线程，主要包括：
? HTML Parser 解析HTML文档，将元素转换为树结构DOM节点，称之为Content Tree
? CSS Parser 解析Style数据，包括外部的CSS文件以及在HTML元素中的样式，用于创建另一棵树，调用“Render Tree”

? Layout过程 为每个节点计算出在屏幕中展示的准确坐标

? Painting 遍历Render Tree，调用UI Backend提供的接口绘制每个节点

3.2 JavaScript 引擎线程
JS引擎线程负责解析Javascript脚本，运行代码 JS引擎一直等待着任务队列中任务的到来，然后加以处理，一个Tab页（renderer进程）中无论什么时候都只有一个JS线程在运行JS程序
GUI渲染线程与JS引擎线程是互斥的，所以如果JS执行的时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞

a) 减少 JavaScript 加载对 DOM 渲染的影响（将 JavaScript 代码的加载逻辑放在 HTML 文件的尾部，减少对渲染引擎呈现工作的影响；
b) 避免重排，减少重绘（避免白屏，或者交互过程中的卡顿；
c) 减少 DOM 的层级（可以减少渲染引擎工作过程中的计算量；
d) 使用 requestAnimationFrame 来实现视觉变化（一般来说我们会使用 setTimeout 或 setInterval 来执行动画之类的视觉变化，但这种做法的问题是，回调将在帧中的某个时点运行，可能刚好在末尾，而这可能经常会使我们丢失帧，导致卡顿）
3.3 浏览器定时触发器线程
浏览器定时计数器并不是由 JavaScript 引擎计数的, 因为 JavaScript 引擎是单线程的, 如果处于阻塞线程状态就会影响记计时的准确, 因此通过单独线程来计时并触发定时是更为合理的方案
3.4 浏览器事件触发线程
当一个事件被触发时该线程会把事件添加到待处理队列的队尾，等待 JavaScript 引擎的处理。这些事件可以是当前执行的代码块如定时任务、也可来自浏览器内核的其他线程如鼠标点击、AJAX 异步请求等，但由于 JavaScript 的单线程关系所有这些事件都得排队等待 JavaScript 引擎处理。
3.5 浏览器 http 异步请求线程
在 XMLHttpRequest 在连接后是通过浏览器新开一个线程请求， 将检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件放到 JavaScript 引擎的处理队列中等待处理。
4 以Chrome浏览器为例，演示浏览器内部如何工作
上面铺垫了这么多理论，下面结合Chrome讲解当用户在地址栏上输入URL后，浏览器内部都做了写什么

4.1 Chrome浏览器中的多进程
打开Chrome 任务管理器，可以看到

Chrome运行的进程

各个进程的功能

? Browser进程

功能：Controls "chrome" part of the application including address bar, bookmarks, back and forward buttons. Also handles the invisible, privileged parts of a web browser such as network requests and file access.
? GPU进程

功能：Handles GPU tasks in isolation from other processes. It is separated into different process because GPUs handles requests from multiple apps and draw them in the same surface.
? 第三方插件进程

功能：Controls any plugins used by the website, for example, flash. 每个插件对应一个进程，当插件运行时创建
? 浏览器渲染进程

功能：Controls anything inside of the tab where a website is displayed. 默认每个标签页创建一个渲染引擎实例。
? V8 Proxy resolver

关于V8 Proxy resolver可查看
code.google.com

group.google.com https://groups.google.com/a/c...!topic/net-dev/73f9B5vFphI

doc.google.com

Chrome支持使用代理脚本为给定的网址选择代理服务器，包含使用操作系统提供的代理解析程序的多个平台的回退实现。但默认情况下（iOS除外），它使用内置的解析V8执行代理脚本（V8 pac）。今天（截至2015年1月），V8 pac在浏览器进程中运行。这意味着浏览器进程包含一个V8实例，这是一个潜在的安全漏洞。在浏览器进程中允许V8还需要浏览器进程允许写入 - 执行页面。

我们关于将V8 pac迁移到单独进程的建议包括为解析器创建Mojo服务，从实用程序进程导出该服务，以及从浏览器进程创建/连接到该进程。

浏览器进程之间主要通过IPC (Inter Process Communication)通信

4.2 Per-frame renderer processes - Site Isolation
Site Isolation is a recently introduced feature in Chrome that runs a separate renderer process for each cross-site iframe. We’ve been talking about one renderer process per tab model which allowed cross-site iframes to run in a single renderer process with sharing memory space between different sites. Running a.com and b.com in the same renderer process might seem okay. The Same Origin Policy is the core security model of the web; it makes sure one site cannot access data from other sites without consent. Bypassing this policy is a primary goal of security attacks. Process isolation is the most effective way to separate sites. With Meltdown and Spectre, it became even more apparent that we need to separate sites using processes. With Site Isolation enabled on desktop by default since Chrome 67, each cross-site iframe in a tab gets a separate renderer process.

每个iframe是单独的渲染进程