Multi2sim：多核时钟精确仿真器官方手册

需积分: 11 120 浏览量更新于2024-07-30 收藏 4.55MB PDF 举报

"Multi2sim手册是一份详细指南，专注于多核时钟精确仿真器的使用，特别适用于异构计算。这份手册由Rafael Ubal、Julio Sahuquillo、Salvador Petit、Pedro L'opez、Zhongliang Chen和David R. Kaeli等人编写，涵盖了从安装到高级功能的全面介绍。" Multi2sim是一个强大的仿真工具，设计用于模拟多核系统，特别是那些包含CPU和GPU的异构环境。手册详细介绍了仿真在计算机科学中的两种主要范式：功能仿真和详细仿真。功能仿真主要关注程序的逻辑行为，而详细仿真则更深入，包括了硬件级别的时序和行为。开始使用Multi2sim，首先要进行安装，手册中提供了简单易懂的步骤指导。一旦安装完成，用户可以执行简单的仿真任务来快速熟悉工具。CPU统计总结部分提供了一个概述，帮助用户理解仿真过程中处理器的行为和性能。配置文件是控制仿真环境的关键，Context Configuration File部分详述了文件的格式和一个示例，使得用户能定制自己的仿真设置。处理器流水线章节解释了处理器如何处理指令，这对于理解性能和效率至关重要。为了使用Multi2sim进行源代码的编译和仿真，手册详细讲解了静态和动态链接的区别，以及如何观察仿真结果的差异。此外，它还讨论了执行的可变性，这在处理并行和并发时特别重要。当仿真自定义程序二进制文件时，手册也给出了可能出现错误信息的处理方法。处理器前端部分涵盖了分支预测、多分支预测、宏指令解码和trace cache等多个主题。分支预测是现代处理器优化性能的关键技术，手册列举了不同类型的分支预测器，如完美预测器、单次取值预测器、双模式预测器、两级自适应预测器和组合预测器。这些预测器的详细说明有助于理解其工作原理和性能差异。宏指令解码描述了如何将原始指令转换为更复杂的宏指令，以提高执行效率。而trace cache则是用来存储指令执行轨迹，减少内存访问，提升性能的一种技术。 Multi2sim手册为开发者和研究人员提供了一个全面的指南，帮助他们理解和利用这个工具进行多核系统的精确仿真，特别是在异构计算环境中的应用。通过深入学习和实践，用户可以有效地优化和分析他们的代码在各种硬件配置下的性能。

the statically linked program. As observed, one of the multiple initializations performed by the

program libraries, and speciﬁcally by glibc, involves getting a sequence of random bytes by reading

ﬁle /dev/urandom. Even though we do not really care what glibc needs this random numbers for,

we should assume that the following instructions will use these numbers to perform some actions,

which will vary depending on the actual values read. This would be a possible cause for slight

execution variability.

Another frequent source of variability can occur when the same program is executed in diﬀerent

paths. There is an environment variable called “ ” (underscore) that represents the current working

directory. When an execv system call (real system) or the program loader (Multi2Sim environment)

initializes a process image, the environment variables are copied into the new process’s stack. It

could perfectly happen that a speciﬁc version of glibc analyzes these variables by, for example,

performing a strlen operation on each of them for any purpose. In this case, the number of

iterations for each string would vary depending on the string lengths. Thus, the total number of

instructions executed in the program might depend on the current directory length, among others.

In conclusion, a small variability among diﬀerent execution instances of the same program

should be considered as a normal behavior, even if all “environment conditions” seem to be exactly

the same. Notice that this is not a behavior exclusively present in a simulated program, but also

incurred by a program’s native execution on the host machine.

1.6.4 Error Messages when Simulating your Program Binaries

A very extensive implementation is provided in Multi2Sim for both the x86 instruction set and

some more than the most common Unix system calls. The implementation of these features is

based on the usage of both instructions and system calls by the supported benchmarks and tested

executables. At the current point, many diﬀerent versions of gcc have been used to generate

executables, including diﬀerent versions of shared libraries and Linux kernels. During this process,

new instructions and system calls have been added, providing a pretty stable and complete version

for the functional simulation of a program.

However, it is possible that your speciﬁc combination of shared libraries and gcc compiler

generate an executable ﬁle that includes a speciﬁc instruction or system call that is not supported

by Multi2Sim. When you try to perform a functional simulation of the unsupported program, you

would obtain an error message like this:

fatal: context 1000 at 0x0804f800: instruction not implemented: 0f a1 b0 ...

— or —

fatal: not implemented system call ’tgkill’ (code 270) at 0x0802010

In any of these cases, don’t give up! We are very interested in increasing the support for any pro-

gram executable that a user might need to run. So please send an email to development@multi2sim.org,

and the problem will be solved as soon as possible. Since the origin of the simulator, the fact of

providing a complete implementation of the x86-based Linux ABI has been a priority for its devel-

opment.

Chapter 2

The Processor Front-End

2.1 Branch Predition

The branch prediction process is mainly implemented in ﬁle src/libcpuarch/bpred.c. There are

two diﬀerent components involved in branch prediction: the Branch Target Buﬀer (BTB) and the

branch predictor itself. The BTB is a set-associative cache indexed by a macroinstruction address.

If an address is present, i.e., the corresponding entry contains a tag equals to the address, the

contents of the entry specify the target of the branch. Moreover, it conveys additional information,

such as the type of branch: conditional, unconditional (or jump), call, or return. The variables

to specify the BTB characteristics are BTB.Sets and BTB.Assoc in section [ BranchPredictor ]. The

argument BTB.Sets is a power of 2 indicating the number of sets of the BTB, while BTB.Assoc refers

to the number of ways or associativity of the BTB, also a power of 2.

On the other hand, the branch predictor provides the direction of a branch located at a given

address, i.e., whether it is taken or not. The branch predictor kinds modeled in Multi2Sim are

Perfect, Taken, NotTaken, Bimodal, TwoLevel, and Combined. In the processor front-end, branch

instructions are identiﬁed by accessing the BTB. Afterwards, the branch predictor states if the

branch is actually taken or not. The branch predictor type is speciﬁed by means of the variables

Kind = {Perfect|Taken|NotTaken|Bimodal|TwoLevel|Combined}. Each type of predictor is described next.

2.1.1 Perfect branch predictor

The perfect predictor (variable Kind = Perfect) provides a totally accurate prediction with a 100%

hit ratio. Calls to the BTB-related functions always return the correct target address even if the

branch has not been committed before, and calls to the branch predictor functions always return

the right direction.

2.1.2 Taken branch predictor

The taken predictor (variable Kind = Taken) assumes that branches are always taken. However, those

branches whose target address is not contained in the BTB will not access the branch predictor,

and the ﬂow of fetched instructions will continue as if the branch had not been taken. Finally, the

not-taken predictor assumes that conditional branches are never taken. However, this predictor

is smart enough to consider as taken those branches that are certainly known as such, that is,

unconditional branches, calls, and returns.

Figure 2.1: Two-level adaptive branch predictor.

2.1.3 Bimodal branch predictor

A bimodal predictor (variable Kind = Bimodal) is a table indexed by the least signiﬁcant bits of an

instruction address. The entries of the table are 2-bit up-down saturating counters. A counter

represents the current prediction for a given branch. Values of 0 and 1 represent a not-taken

prediction, while values 0 and 2 mean that the branch is taken. The number of entries in the table

is a power of 2 given by the variable Bimod.Size.

2.1.4 Two-level adaptive predictor

A two-level adaptive predictor (variable Kind = TwoLevel) two tables, each corresponding to one

prediction level. There are three variables involved with this predictor, namely TwoLevel.L1Size,

TwoLevel.L2Size, and TwoLevel.HistorySize, which deﬁnes speciﬁc parameter of the predictor compo-

nents.

As shown in Figure 2.1, the ﬁrst accessed table is the Branch History Table (BHT). This table is

indexed by the least signiﬁcant bits of the branch instruction address, and contains TwoLevel.L1Size

entries (power of 2). Each entry contains a branch history register of TwoLevel.HistorySize bits that

indicates the behavior of the last TwoLevel.HistorySize occurrences of the branch. Every time a

branch commits, this register is shifted left, and the least signiﬁcant bit is set or cleared according

to whether the branch was actually taken or not.

The contents of the history register obtained from the BHT is used to index the row of a

second two-dimensional table called Pattern History Table (PHT). Because the history register has

TwoLevel.HistorySize bits, the PHT is forced to have 2ˆTwoLevel.HistorySize entries. The column of

the PHT is also indexed by the least signiﬁcant bits of the branch instruction address. The number

of columns in the PHT is given by the TwoLevel.L2Size parameter. Each entry in the PHT contains

a 2-bit up-down saturating counter that gives the ﬁnal prediction for the inquired branch.

By properly tunning the variables described above, one can form the four two-level adaptive

conﬁgurations commonly known as GAg, GAp, PAg, and PAp. See [1] for a more detailed descrip-

tion about these predictors. The table shown on the right of Figure 2.1 lists the restrictions that

need to fulﬁll the predictor parameters in order to be classiﬁed as each of the cited conﬁgurations.

2.1.5 Combined predictor

The combined predictor (option Kind = Combined) combines the bimodal and the two-level adaptive

predictors. On an inquiry, both components are looked up, and their corresponding predictions

are temporarily stored. Then, an additional table, called choice predictor, is accessed to decide

Figure 2.2: Multiple branch prediction.

whether to obey to the bimodal predictor statement or to the two-level predictor statement. The

variable Choice.Size speciﬁes the number of entries in the choice predictor (power of 2).

Each entry contains a 2-bit saturating counter. If its value is 0 or 1, the statement of the

bimodal predictor is considered. If its value is 2 or 3, the two-level predictor is used to give the

ﬁnal prediction. The choice predictor counters are updated at the commit stage only in the case

that the bimodal and the two-level predictors gave a contradicting prediction when looked up.

2.2 Multiple Branch Prediction

Multi2Sim supports the prediction of multiple non-consecutive branches in the same cycle by using

the so-called multiple branch prediction algorithms, as proposed in [2]. This advanced prediction

scheme is required by some other microarchitectural improvements, such as the trace cache. If

multiple non-contiguous basic blocks are fetched in the same cycle, it is necessary to predict the

behavior of the branches located at the end of each of these blocks.

The branch at the end of the ﬁrst basic block is referred to as primary branch, while the

branches located at the end of the second and third basic blocks following the execution path are

called secondary and tertiary branch, respectively. To make multiple prediction, a branch predictor

is needed which uses a branch history register. In Multi2Sim, multiple branch prediction is allowed

only when a two-level adaptive predictor is used.

Figure 2.2 shows a working scheme of multiple branch prediction. First, a branch history register

(BHR) is used to make the primary prediction. In the case of the two-level predictor, this register is

obtained either straightforwardly from the ﬁrst level when it uses global history, or by indexing the

branch history table (BHT) using the branch address when it uses per-address history. With the

obtained BHR, the PHT is indexed in the second level to obtain a counter that gives the inquired

prediction. This is the output for the primary branch.

To predict the second branch, the BHR is left shifted, and two new BHRs are obtained by ﬁlling

the least signiﬁcant position with 0 and 1. These BHRs are now used to index the PHT and obtain

the predictions for the two possible secondary branches. The choice between these predictions is

performed according to the output of the primary branch prediction.

The tertiary branch is again predicted by left shifting the BHR two positions, and obtaining four

predictions from the PHT, corresponding to the four possible paths that can reach four diﬀerent

tertiary basic blocks and branches. The choice between these predictions is made by means of

the output of the primary and secondary predictions. This mechanism can be generalized to any

number of additional predictions.

There is a chain connection between the outputs of the primary, secondary, tertiary, etc., pre-

dictions. However, notice that the accessed to the PHT are performed simultaneously. Moreover,

Uop name Functional unit Description

move None Copy the contents of one register.

add Integer adder Addition.

sub Integer subtracter Subtraction.

mult Integer multiplier Multiplication.

div Integer divider Division.

effaddr Address computer Eﬀective address computation prior to memory opera-

tions. This operation may involve shifting a physical reg-

ister (multiplication by a factor power of 2), and adding

an immediate value.

and, or, xor, not,

shift, sign

Logical operator Logical and, or, xor, negation, shift, and sign extension,

resp ectively.

fpmove None Copy the contents of one ﬂoating-point register.

fpsimple FP adder Simple ﬂoating-point instructions, such as absolute value

computation, or sign change.

fpadd FP adder Floating-p oint additions and subtractions.

fpcomp FP adder Floating-p oint comparisons modifying the FP status reg-

ister.

fpmult FP multiplier Floating-p oint multiplication.

fpdiv FP divider Floating-p oint division.

fpcomplex FP complex unit Complex ﬂoating-point operations, such as sinus, tan-

gent, or square root.

load Data cache Read access to memory.

store Data cache Write access to memory.

call None Function call.

ret None Function return.

jump None Unconditional jump.

branch None Conditional branch.

syscall None Generate a system call interrupt. Since Multi2Sim ab-

stracts the operating system, a system call is considered

a single uop modifying a set of logical registers and mem-

ory locations.

Table 2.1: Microinstruction set deﬁnition.

those predictions requiring multiple PHT accessed (e.g., four of a tertiary prediction) always read

consecutive positions in the PHT, since only least signiﬁcant bits in the BHR diﬀer.

2.3 Macroinstruction Decoding

The x86 architecture deﬁnes a CISC instruction set [3]. Each single instruction deﬁned in the x86

ISA has a size between 1 and 15 bytes, and can perform a wide set of diﬀerent actions. These

instructions are hard to directly execute, so hardware usually translates them into a machine-

speciﬁc set of microinstructions (uops) which perform single individual actions. Multi2Sim deﬁnes

its own set of uops in ﬁle src/libcpuarch/uop1.dat. Each uop is associated with the type of functional

unit it needs to be executed, and with a set of ﬂags describing some characteristics of the uop. The

uop set implemented in Multi2Sim is listed in Table 2.1.

Each uop has a maximum of four output dependences. They are formed of logical registers and

status ﬂags, but there can be at the most one logical register in this set. The maximum number of

input dependences for an uop is three, considering logical registers and status ﬂags, among which

a maximum of two elements can be logical registers.

剩余96页未读，继续阅读

树袋大熊

粉丝: 34
资源: 7

Multi2sim：多核时钟精确仿真器官方手册

Multi2Sim A Simulation Framework for CPU-GPU computing

Multi2sim-3.1.1.tar.gz

multi2sim user guide m2s-guide-4.2.pdf

multi sim数字秒表

ubunto下载multisim

介绍一下multi-sdr-gps-sim项目的用法

multi-sdr-gps-sim

MultiIndex怎么用

\begin{multicols}{2}

最新资源