跳转至

笔记

HDMI

HDMI

高清多媒体界面(英语:High Definition Multimedia Interface,缩写:HDMI)是一种全数字化影像和声音发送接口,可以发送未压缩的音频及视频信号。HDMI可以同时发送音频和视频信号,由于音频和视频信号采用同一条线材,大大简化系统线路的安装难度。

与DP的区别

HDMI是被设计来取代较旧的模拟信号影音发送接口。HDMI继承DVI的核心技术“传输最小化差分信号”TMDS,从本质上来说仍然是DVI的扩展。画面是以逐行的方式被发送,并在每一行与每祯画面发送完毕后加入一个特定的空白时间(类似模拟扫描线),并没有将数据“Micro-Packet Architecture(微数据包架构)”化,也不会只更新前后两帧画面改变的部分。每张画面在该更新时都会被完整的重新发送。

而DisplayPort一开始则面向液晶显示器开发,采用“Micro-Packet Architecture(微数据包架构)”传输架构,视频内容以数据包方式传送,这一点同DVI、HDMI等视频传输技术有着明显区别。

更多先进特性对比: https://www.cnbeta.com/articles/tech/1034975.htm

历史

HDMI 1.4

2009年5月28日提出,最高支持4K×2K(3840×2160p@24 Hz/25 Hz/30 Hz或4096×2160p@24 Hz)

HDMI 2.0

2013年9月4日提出

  1. 新增2160p@50 YCbCr 4:2:0、2160p@60 YCbCr 4:2:0(4K分辨率)
  2. 传输带宽18Gbit/s 支持4096*2160*60Hz

HDMI 2.1

2017年1月4日提出

  1. 支持的最大分辨率为 10K/120 Hz

比特率编码

在早期的DP和HDMI标注中,数字信号大多使用8b/10b的比特率编码进行传输。在8b/10b编码模式下,意味着每8位数据在实际传输中需要10位的传输带宽,而这些多出来的冗余用来确保信号的完整性,这意味着他们只有80%的理论带宽可以用来传输数据。

而在最新的协议下,DP 2.0采用128b/132b进行传输,编码效率效率提升到97%,而HDMI 2.1则采用16b/18b进行传输,编码效率为88.9%。

加上同代的DP接口一般都拥有更高的传输速率,所以最新一代DP接口相对HDMI的拥有更高的数据速率。

数据表示

每个像素都拥有红色,绿色和蓝色(RGB)这三个数据点,或者使用亮度,蓝色色度差和红色色度差(YCbCr / YPbPr)三个数据点

各种接口速率

查看电脑USB接口

接口驱动更新

???

软件的帧率

Windows

Android

实际应用

联想2020R7000

type c,同时支持dp1.2的视频输出 21.6Gbps

HDMI2.0 18Gbps

怎么算

小米的显示器是DP1.4的接口 10bits

但是实际是8bits 下需要的带宽为为3*8*3440*1440*100Hz=11888640000bps 3种颜色每个8位。

11888640000bps / 0.8 = 14860800000bps 也不对,哪里有问题

实际

买了根DP1.4的线,但是只有DP1.2的口 但是144Hz带不动,会花屏,或者闪烁。

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

https://zh.wikipedia.org/wiki/USB#%E6%A0%87%E5%87%86USB%E6%8E%A5%E5%8F%A3

https://www.cnbeta.com/articles/tech/1034975.htm

DP

DP

DisplayPort(简称DP)是一个由PC及芯片制造商联盟开发,视频电子标准协会(VESA)标准化的数字式视频接口标准。该接口免认证、免授权金,主要用于视频源与显示器等设备的连接,并也支持音频、USB和其他形式的资料。

用于取代传统的VGA、DVI。 DisplayPort是第一个依赖数据包化资料传输技术的显示连接端口。

历史

1.0

2006年5月发布。带宽10.8Gbps。DisplayPort 1.0的最大传输速度是8.64Gbit/s,长度是2米。已经废弃。

1.2

于2009年12月22日发布。它最大的改变是传输速度增加两倍到21.6Gbit/s(High Bit Rate 2(HBR2)mode),支持4K(4096X2160)60Hz,因此支授更高的分辨率、帧速率及色深。苹果公司设计的Mini DisplayPort亦兼容此标准。支持3D、支持多流(multi-streaming)。目前此版本是主流。

1.3

2014年9月15日,视频电子标准协会发布DisplayPort 1.3,带宽速度最高32.4 Gbps(HBR3),编码后有效带宽为25.92 Gbps,可支持4K(3840X2160)120hz、5K(5120X2880)60hz、8K(7680X4320)30hz。

1.4

2016年2月份最终版的DP 1.4连接端口规范,新标准基于2014年9月的DP 1.3规范,带宽不变但加入了显示压缩流(Display Stream Compression)技术、前向错误更正(Forward Error Correction)、高动态范围数据包(HDR meta transport),声道也提升到32声道1536 KHz采样率,一般情况下,DP1.4可提供4K 120Hz 8bit输出,若搭配DSC技术,可提供4K 144Hz 10bit输出。

DP1.4目前有严重BUG,无法进入bios或屏幕休眠后无法唤醒,20和30系显卡NVIDIA官方尚未放出修复更新,必须要显卡厂商自行修复,建议改用HDMI2.1

2.0

  1. 三倍数据带宽性能 之前版本的DisplayPort v1.4a提供了32.4 Gbps的最大链路带宽,四个通道中的每一个都以8.1 Gbps / lane的链路速率运行。使用8b / 10b信道编码,相当于25.92 Gbps的最大有效载荷。

DP 2.0将最大链路速率提高到20 Gbps / lane,并具有更高效的128b / 132b信道编码,最大有效载荷为77.37 Gbps - 与DP 1.4a相比,增加了三倍。

这意味着DP 2.0是第一个以60 Hz刷新率支持8K分辨率(7680 x 4320)的标准,全彩色4:4:4分辨率,包括每像素30位(bpp),支持HDR-10。

  1. 单显示分辨率??? 一个16K(15360×8640)显示器@ 60Hz和30 bpp 4:4:4 HDR(带DSC)

    一个10K(10240×4320)显示器@ 60Hz和24 bpp 4:4:4(无压缩) 双显示分辨率

    两个8K(7680×4320)显示器@ 120Hz和30 bpp 4:4:4 HDR(带DSC)

    两个4K(3840×2160)显示@ 144Hz和24 bpp 4:4:4(无压缩) 三重显示分辨率

    三个10K(10240×4320)显示器@ 60Hz和30 bpp 4:4:4 HDR(带DSC)

    三个4K(3840×2160)显示@ 90Hz和30 bpp 4:4:4 HDR(无压缩)

特点

  1. 完全兼容现有HDMI1.4a标准和旧的HDMI标准。
  2. 支持USB Type-C。
  3. 支持144Hz刷新率
  4. 支持6、8、10、12与16位色深。
  5. 1080p的有效传输带宽保证长度为5米。
  6. 多屏幕输出 DisplayPort 1.2支持MST(Multi-Stream Transport),单个DP可连接到多个显示器。要使用这项功能,显示器需要支持DP 1.2菊花链(Daisy-chaining),或使用MST Hub把DP一个拆成三个。

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

USB & Thunderbolt & Type-C

USB

通用串行总线(英语:Universal Serial Bus,缩写:USB)是连接计算机系统与外部设备的一种串口总线标准,也是一种输入输出接口的技术规范,被广泛地应用于个人电脑和移动设备等信息通讯产品。

最新一代的USB是USB4,传输速度为40Gbit/s。物理接头USB Type-A、Type-B接头分正反面,新型USB Type-C接头不分正反。

区分USB3.0

  1. 按颜色区分,接口内部是黑色的为USB2.0,蓝色或红色的为USB3.0
  2. 接口触点区分,USB2.0接口只有四个触点,而USB3.0有9个触点(外五内四)
    1. 4个(1个供电,2个数据,1个接地);USB 3.0拥有9个(另外4个提供给SuperSpeed技术);USB 3.1 Type-C拥有24个
  3. 还有一种是看接口标识,见下图

速率

接口样式

历史

USB 2.0

USB 2.0:2000年4月发布。增加更高的数据传输速率480Mbit/s(现在称作Hi-Speed,大约57MB/s),但受限于BOT传输协议和NRZI编码方式,实际最高传输速度只有35MByte/s左右。

USB 3.0(USB 3.1 Gen1/USB 3.2 Gen1)

USB 3.0于2008年11月发布,速度由480Mbps大幅提升到5Gbps。USB 3.0插座通常是蓝色的,并向下兼容USB 2.0和USB 1.x。USB 3.0引入了全双工传输,USB 1.x和USB 2.0则是半双工传输。

USB 3.1(USB 3.1 Gen2/USB 3.2 Gen2x1)

USB3.0推广小组于2013年7月31日宣布USB 3.1规格[10],传输速度提升为10Gb/s,比USB3.0的5Gb/s快上一倍,并向下兼容USB 2.0/1.0,如果要得到10Gb/s的传输速度仍需在主机、目标端同时具备对应的芯片才能达成,电力供应可高达100瓦。

USB Type-C接口

于2014年8月完成。与USB 3.1规格大致相同。但USB-C只是一个接口,不一定支持USB 3.x或Power Delivery(许多手机的Type-C仍然使用USB 2.0)

USB 3.2(USB 3.2 Gen2x2)

在USB Type-C接口上实现双通道,速度方面,使用USB 3.2主机连接USB 3.2存储设备,可以实现两条通道10Gbps的传输速度,理论上也就是相当接近于20Gbps。

另外,从USB 3.2开始,Type-C是唯一推荐的接口方案。

USB4

USB4项目集成Thunderbolt 3协议,USB4支持40Gbps的传输速度,固定Type-C口。

USB Type-C接口

特点

可选集成DisplayPort、HDMI、MHL。 可选集成Thunderbolt。 可选集成USB4。

Thunderbolt

Thunderbolt(又称“雷电”,苹果中国译为“雷雳”[4])是由英特尔发表的连接器标准,目的在于当作电脑与其他设备之间的通用总线,第一代与第二代接口是与Mini DisplayPort集成,较新的第三代开始改为与USB Type-C结合,并能提供电源。

历史

由于 Thunderbolt 1, 2使用的是苹果Mini Displayport,配件无法用在其他电子设备,普及程度远低于对手USB。

由于雷电协议需要额外的独立芯片支持,费用高昂。Intel决定把雷电协议开源给USB-IF。这间接促成了USB4的推出。 第三版(Thunderbolt 3) 2015年6月2日,COMPUTEX 2015 ,代号为Alpine Ridge,双倍带宽达到40 Gbit/s (5 GB/s)。Thunderbolt 3 物理接口改用USB Type-C。

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

BHive : An Infrastructure for Adaptive Dynamic Optimization 2003 IEEE

摘要

动态优化逐渐显现出是一种解决传统静态汇编困难的好方法。 但是市面上有大量的针对开发静态优化的编译器框架,但是少有针对动态优化的。

我们实现了一种动态分析和优化的框架,为DynamoRIO动态代码修改系统提供了一种创建额外模块的交互界面。通过简单轻量的API就可以提炼许多DynamoRIO运行时的底层细节,但是只能在单指令流下,而且不同指令显示的细节也是不同的。

该API不仅可以用来优化,也可以instrumentation,热点分析和动态翻译。

为了展现架构的有效性,我们实现了若干优化,一些例子有40%提升,基于DynamoRIO平均有12%加速。

简介

随着现代软件的复杂,还有动态load,共享库等特性,静态分析越来越衰弱。静态分析器去分析整个程序是困难或者不可能的,而静态优化又受限于静态代码分析器的准确性。而且静态优化过多会导致出错时难以debug。

DynamoRIO

Client Interface

Instruction Representation

DynamoRIO API

DynamoRIO Client

Extensions for Adaptive Optimization

Extensions for Custom Traces

Examples

Redundant Load Removal

Strength Reduction

Indirect Branch Dispatch

Custom Traces

Experimental Results

Conclusions

就是这个动态框架好,使用范围广,前途光明

BHive的提取基本块的应该就是 bbuf

https://github.com/DynamoRIO/dynamorio/blob/master/api/samples/bbbuf.c

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

Static Code Analysis

静态代码分析器的意义

在不运行程序的情况下,预测程序性能表现。得到估计时钟周期,资源占用情况,潜在的代码瓶颈等的分析。以便优化程序,或者为了更好的运行程序反过来对CPU的架构设计提出意见。

在预测的过程中,也会简单进行自动向量化,指令调度等工作。

比如你想看在arm架构下该程序下有什么瓶颈,但是你只有intel的机器,你就可以通过静态代码分析器来分析。但是当前的效果都不是太好。

已有的Static Code Analyzer

IACA

IACA (the Intel Architecture Code Analyzer) is a (2019: end-of-life) freeware, closed-source static analysis tool made by Intel

由于Intel对自己的处理器优化很了解,所有可以更好的预测。 比如 zero-idioms 和 micro-op fusions(聚合,将相邻指令变为一条指令)

zero-idioms —— The processor recognizes that certain instructions are independent of the prior value of the register if the two operand registers are the same. An instruction that subtracts a register from itself will always give zero, regardless of the previous value of the register.

Ithemal

Ithemal (Instruction THroughput Estimator using MAchine Learning) 基于hierarchical LSTM–based 方法。基本块预测器,但是是黑盒。

Long short-term memory (LSTM) is an artificial recurrent neural network (RNN) architecture used in the field of deep learning.

应该是准确度最高的

LLVM-mca

LLVM Machine Code Analyzer 受到IACA启发的相似的工具,是乱序超标量(多条流水线,每周期可以完成2条以上指令,如下图)微架构模拟器。 使用了LLVM后端的调度模型参数。这种重用调度模型的选择对llvm cost 模型提供了经验。其准确性于调度模型有关。

OSACA

Open Source Architecture Code Analyzer

是IACA的开源替代,也和llvm-mca很像。是参数化的乱序模拟器,但是参数来自测量的指令查找表

cost model

LLVM 和GCC 也有cost model,但是是指令层面的,不是基本块层面的。

比如LLVM 至少有3个: 1. a generic, per-instruction IR (Intermediate Representation) cost model for its target-independent optimizations 2. one for instruction scheduling (the scheduling model [14] is also used by llvm-mca); 3. another one for register allocation

基本概念

throughput

Predicting the (average) number of clock cycles a processor takes to execute a block of assembly instructions in steady state

performance models / Processor performance models

指代静态代码分析器,就是别名。

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

https://github.com/RRZE-HPC/OSACA

Kunpeng

多线程SMT (Simultaneous multithreading)

统一的调度器复杂度超级高,只有Intel实现了,但是效果很好。

什么是CPU Die

良品率会更高

自研OpenBLAS+ ,毕申编译器,自研MPI

片间一致性可以到达4P到16P???。Intel可以达到8P

问题

  1. 虽然说是保密的,但是鲲鹏930,950应该已经出来了
  2. 930,950是异构的核(是大小核吗?)

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

https://bbs.huaweicloud.com/blogs/268031

GPU

这篇聚焦于 GPU 发展的起源,目的和历史。(看历史真好玩)

ISA & Micro-architecture

Instruction Set Architecture(ISA)

指令集架构(Instruction Set Architecture)是指一种类型CPU中用来计算和控制计算机系统的一套指令的集合。

指令集架构主要规定了指令格式、寻址访存(寻址范围、寻址模式、寻址粒度、访存方式、地址对齐等)、数据类型、寄存器。指令集通常包括三大类主要指令类型:运算指令、分支指令和访存指令。此外,还包括架构相关指令、复杂操作指令和其他特殊用途指令。因此,一种CPU执行的指令集架构不仅决定了CPU所要求的能力,而且也决定了指令的格式和CPU的结构。X86架构和ARMv8架构就是指令集架构的范畴。

所以不要说Nvidia是属于x86还是arm了,显卡应该是有自己的架构的。比如NV Tesla架构 、Fermi架构、Maxwell架构、Kepler架构、Turing架构。

而且X86具体到Intel,也有Skylake 架构 Ice lake 架构 Haswell架构等具体的实现

CISC与RISC的历史

复杂指令集(CISC,complex instruction set computer)

RISC:Reduced Instruction Set Computer

Three Performance Knobs

\(\(p(performance)=\frac{IPC*f}{Instruction\ Count}\)\)

在计算机发展初期,计算机的优化方向是通过设置一些功能复杂的指令,把一些原来由软件实现的、常用的功能改用硬件的指令系统实现(减少IC),以此来提高计算机的执行速度。也就是为了减少程序的设计时间,逐渐开发出单一指令,复杂操作的程序代码。设计师只需写下简单的指令,再交给CPU去执行。

但是后来有人发现,整个指令集中,只有约20%的指令常常会被使用到,大约占了整个程序的80%;剩余80%的指令,只占了整个程序的20%。(典型的二八原则)

于是有人提出RISC尽量简化计算机指令功能的想法,主张硬件应该专心加速常用的指令,较为复杂的指令则利用常用的指令去组合。功能简单、能在一个节拍内执行完成的指令被保留,而较复杂的功能用一段子程序来实现,这种计算机系统就被称为精简指令系统计算机。

简单来说,CISC任务处理能力强,适合桌面电脑和服务器。RISC通过精简CISC指令种类,格式,简化寻址方式,达到省电高效的效果,适合手机、平板、数码相机等便携式电子产品。

各种架构

X86架构

1978年6月8日,Intel 发布了新款16位微处理器 8086,也同时开创了一个新时代:X86架构诞生了。

X86指令集是美国Intel公司为其第一块16位CPU(i8086)专门开发的,美国IBM公司1981年推出的世界第一台PC机中的CPU–i8088(i8086简化版)使用的也是X86指令。

为了保证电脑能继续运行以往开发的各类应用程序以保护和继承丰富的软件资源,所以Intel公司所生产的所有CPU仍然继续使用X86指令集。

IA64

IA64,又称英特尔安腾架构(Intel Itanium architecture),使用在Itanium处理器家族上的64位指令集架构,由英特尔公司与惠普公司共同开发,2001年首次推出。

ARM

见 arm.md

MIPS

1981年出现,由MIPS科技公司开发并授权,它是基于一种固定长度的定期编码指令集,并采用 导入/存储(Load/Store)数据模型。

mips是一个学院派的cpu,授权门槛极低,因此很多厂家都做mips或者mips衍生架构。我们平时接触到的mips架构cpu主要用在嵌入式领域,比如路由器。

目前最活跃的mips是中国的龙芯,其loongisa架构其实是mips的扩展。

DEC Alpha

Alpha是DEC公司推出的RISC指令集系统,基于Alpha指令集的CPU也称为Alpha AXP架构,是64位的 RISC微处理器,最初由DEC公司制造,并被用于DEC自己的工作站和服务器中。作为VAX的后续被开发,支持VMS操作系统,如 Digital UNIX。

侧重超算,目前貌似最活跃是中国申威,神威太湖之光的cpu

RISC-V

2010年提出,受到大家的支持。USTC有团队研究。

Instruction Set Architecture(ISA)的发展展望

90年代,MIPS和Alpha作为知名RISC在与X86竞争计算机市场中失败,又在错过智能终端高速发展的机遇中走向衰弱。2010年发布的RISC-V作为从发明伊始即以开源为最大特色的RISC ISA受到全球学界、产业界的高度关注。全球顶级学府、科研机构、芯片巨头纷纷参与,各国政府出台政策支持RISC-V的发展和商业化。RISC-V有望成为X86和ARM之后ISA第三极。

微架构(Micro-architecture)

实现指令集架构的物理电路被称为处理器的微架构(Micro-architecture)

大多数情况下,一种处理器的微架构是针对一种特定指令集架构进行物理实现。少部分处理器架构设计为了更好的兼容性,会在电路设计上实现多个指令集架构。虽然,指令集架构可以授权给多家企业,但微架构的设计细节,也就是对指令的物理实现方式是各家厂商绝对保密的。

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

https://www.zhihu.com/question/423489755/answer/1622380842

Big-Endian & Little-Endian

问题是否有意义

鸡蛋从哪头打破,怎么会有哪种更合适呢?对个人生活和社会发展又有什么意义呢?Swift写这段故事,其实是讽刺当时法国和英国的时政,认为真正重要的事情得不到关注、而在一些毫无意义的事情上争论不休。

各个阵营的选择

Motorola的PowerPC系列CPU采用Big-Endian方式存储数据,

而Intel的x86系列则采用Little-Endian方式存储数据。

JAVA虚拟机中多字节类型数据的存放顺序,也就是JAVA字节序是Big-Endian。

很多的ARM,DSP(Digital signal processor)都为小端模式。有些ARM处理器还可以随时在程序中(在ARM Cortex 系列使用REV、REV16、REVSH指令)进行大小端的切换。

忽略大小端的情况

得益于高级语言的发展,在现在的软件开发基本不需关心字节序(除非是socket编程),如Java这类跨平台移植的语言由虚拟机屏蔽了字节序问题。

对于大小端的处理也和编译器的实现有关,在C语言中,默认是小端(但在一些对于单片机的实现中却是基于大端,比如Keil 51C),Java是平台无关的,默认是大端。在网络上传输数据普遍采用的都是大端

大小尾端程序

华为鲲鹏AArch64 和 Intel x86 都是little-endian

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

LLVM-MCA: Install&RunTests

github

https://github.com/llvm/llvm-project/tree/main/llvm/tools/llvm-mca

Quick Start

安装

下载可执行文件上传服务器,解压

安装遇到的问题

  1. cannot find libtinfo.so.5
  2. sudo apt install libncurses5
  3. ln -s /usr/lib/libncursesw.so.6 /usr/lib/libtinfo.so.5 或者类似的 ln -s /usr/lib/libncurses.so.5 /usr/lib/libtinfo.so.5
  4. 在/snap/core下找到了,但是这是什么目录?是之前Ubuntu的包管理工具,但是已经不用了。

从源码安装

node5

由于之后要写代码的,还是从头安装更好。

cd llvm-project
mkdir build
cmake -S llvm -B build -G "Unix Makefiles" -DLLVM_ENABLE_PROJECTS="clang;llvm-mca" -DCMAKE_INSTALL_PREFIX="~/Install/llvm" -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_ASSERTIONS=On
cd build
make -j32
make install

kunpeng

cmake -S llvm -B build -G "Unix Makefiles" -DLLVM_ENABLE_PROJECTS=all -DCMAKE_INSTALL_PREFIX="~/Install/llvm" -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_ASSERTIONS=On
#change cmake or -DLLVM_ENABLE_PROJECTS="all"
error
g++: error: unrecognized command line option ‘-mllvm’
g++: error: unrecognized command line option ‘--tail-merge-threshold=0’
g++: error: unrecognized command line option ‘-combiner-global-alias-analysis’
change
cmake -S llvm -B build -G "Unix Makefiles" -DLLVM_ENABLE_PROJECTS="clang;llvm-mca" -DCMAKE_INSTALL_PREFIX="~/Install/llvm" -DLLVM_TARGETS_TO_BUILD=AArch64 -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_ASSERTIONS=On

使用

clang foo.c -O2 -target x86_64-unknown-unknown -S -o - | llvm-mca -mcpu=btver2
由于不是X86,llc --version 查看到target是 aarch64-unknown-linux-gnu
clang /home/shaojiemike/Download/llvm-project-main/lldb/test/API/lang/c/forward/foo.c -O2 -target aarch64-unknown-linux-gnu -S -o -|llvm-mca -timeline -show-encoding -all-stats -all-views
生成汇编代码,并默认管道到llvm-mca,并开启所有输出。

可以看出是用TSV110Unit的port,默认cpu是tsv110

名词解释

ALU/BRU

算数逻辑单元 ALU 负责处理整数运算指令. 跳转处理单元BRU 负责处理跳转指令. BRU 可以与 ALU 合并, 复用 ALU 的逻辑来计算跳转指令的条件和跳转地址, 也可以作为一个单独的功能单元接入到流水线中.

MDU

乘除法单元 MDU (mult-divide unit)

需要进一步的研究学习

  1. llvm-mca微指令怎么实现的,怎么把汇编变成微指令
  2. 在view里加memory的实现
  3. 考虑了cache命中等影响 https://github.com/andreas-abel/uiCA uops
  4. 鲲鹏架构 https://bbs.huaweicloud.com/community/usersnew/id_1513665626477516

遇到的问题

  1. llvm-mca -mcpu=help竟然会卡住,不知道为什么
  2. 所以说是华为已经写了一个叫tsv110的,实现2个功能?

开题缘由、总结、反思、吐槽~~

参考文献

样例输出

Iterations:        100
Instructions:      200
Total Cycles:      70
Total uOps:        200

Dispatch Width:    4
uOps Per Cycle:    2.86
IPC:               2.86
Block RThroughput: 0.5


No resource or data dependency bottlenecks discovered.


Instruction Info:
[1]: #uOps
[2]: Latency
[3]: RThroughput
[4]: MayLoad
[5]: MayStore
[6]: HasSideEffects (U)
[7]: Encoding Size

[1]    [2]    [3]    [4]    [5]    [6]    [7]    Encodings:                    Instructions:
 1      1     0.33                         4     20 00 80 52                   mov  w0, #1
 1      1     0.50                  U      4     c0 03 5f d6                   ret


Dynamic Dispatch Stall Cycles:
RAT     - Register unavailable:                      0
RCU     - Retire tokens unavailable:                 0
SCHEDQ  - Scheduler full:                            0
LQ      - Load queue full:                           0
SQ      - Store queue full:                          0
GROUP   - Static restrictions on the dispatch group: 0


Dispatch Logic - number of cycles where we saw N micro opcodes dispatched:
[# dispatched], [# cycles]
 0,              20  (28.6%)
 4,              50  (71.4%)


Schedulers - number of cycles where we saw N micro opcodes issued:
[# issued], [# cycles]
 0,          3  (4.3%)
 2,          1  (1.4%)
 3,          66  (94.3%)

Scheduler's queue usage:
No scheduler resources used.


Retire Control Unit - number of cycles where we saw N instructions retired:
[# retired], [# cycles]
 0,           3  (4.3%)
 2,           1  (1.4%)
 3,           66  (94.3%)

Total ROB Entries:                128
Max Used ROB Entries:             59  ( 46.1% )
Average Used ROB Entries per cy:  32  ( 25.0% )


Register File statistics:
Total number of mappings created:    100
Max number of mappings used:         29


Resources:
[0.0] - TSV110UnitAB
[0.1] - TSV110UnitAB
[1]   - TSV110UnitALU
[2]   - TSV110UnitFSU1
[3]   - TSV110UnitFSU2
[4.0] - TSV110UnitLdSt
[4.1] - TSV110UnitLdSt
[5]   - TSV110UnitMDU


Resource pressure per iteration:
[0.0]  [0.1]  [1]    [2]    [3]    [4.0]  [4.1]  [5]    
0.66   0.67   0.67    -      -      -      -      -     

Resource pressure by instruction:
[0.0]  [0.1]  [1]    [2]    [3]    [4.0]  [4.1]  [5]    Instructions:
0.33    -     0.67    -      -      -      -      -     mov w0, #1
0.33   0.67    -      -      -      -      -      -     ret


Timeline view:
Index     0123456789

[0,0]     DeER .   .   mov  w0, #1
[0,1]     DeER .   .   ret
[1,0]     DeER .   .   mov  w0, #1
[1,1]     D=eER.   .   ret
[2,0]     .DeER.   .   mov  w0, #1
[2,1]     .DeER.   .   ret
[3,0]     .D=eER   .   mov  w0, #1
[3,1]     .D=eER   .   ret
[4,0]     . DeER   .   mov  w0, #1
[4,1]     . D=eER  .   ret
[5,0]     . D=eER  .   mov  w0, #1
[5,1]     . D=eER  .   ret
[6,0]     .  D=eER .   mov  w0, #1
[6,1]     .  D=eER .   ret
[7,0]     .  D=eER .   mov  w0, #1
[7,1]     .  D==eER.   ret
[8,0]     .   D=eER.   mov  w0, #1
[8,1]     .   D=eER.   ret
[9,0]     .   D==eER   mov  w0, #1
[9,1]     .   D==eER   ret


Average Wait times (based on the timeline view):
[0]: Executions
[1]: Average time spent waiting in a scheduler's queue
[2]: Average time spent waiting in a scheduler's queue while ready
[3]: Average time elapsed from WB until retire stage

      [0]    [1]    [2]    [3]
0.     10    1.7    1.7    0.0       mov    w0, #1
1.     10    2.0    2.0    0.0       ret
       10    1.9    1.9    0.0       <total>