SPARC V8 体系结构第一章介绍

  • 原文来源
  • 英文原文
    • 1.1. SPARC Attributes
    • 1.2. SPARC System Components
    • 1.3. SPARC Compliance Definitions
    • 1.4. SPARC Features
    • 1.5. Conformability to SPARC
  • 全文翻译
    • 1.1. SPARC Attributes
    • 1.2. SPARC System Components
    • 1.3. SPARC Compliance Definitions
    • 1.4. SPARC Features
    • 1.5. Conformability to SPARC

原文来源

《The SPARC Architecture Manual (Version 8)》
Revision SAV080SI9308
第一章介绍(Introduction)前5节
下载地址 https://download.csdn.net/download/ScilogyHunter/85154119

英文原文

1.1. SPARC Attributes

SPARC is a CPU instruction set architecture (ISA), derived from a reduced
instruction set computer (RISC) lineage. As an architecture, SPARC allows for a
spectrum of chip and system implementations at a variety of price/performance
points for a range of applications, including scientific/engineering, programming,
real-time, and commercial.

Design Goals
SPARC was designed as a target for optimizing compilers and easily pipelined
hardware implementations. SPARC implementations provide exceptionally high
execution rates and short time-to-market development schedules.

Register Windows
SPARC, formulated at Sun Microsystems in 1985, is based on the RISC I & II
designs engineered at the University of California at Berkeley from 1980 through
1982. the SPARC “register window” architecture, pioneered in UC Berkeley
designs, allows for straightforward, high-performance compilers and a significant
reduction in memory load/store instructions over other RISCs, particularly for
large application programs.

For languages such as C++, where object-oriented programming is dominant,
register windows result in an even greater reduction in instructions executed.
Note that supervisor software, not user programs, manages the register windows.
A supervisor can save a minimum number of registers (approximately 24) at the
time of a context switch, thereby optimizing context switch latency.

One difference between SPARC and the Berkeley RISC I & II is that SPARC
provides greater flexibility to a compiler in its assignment of registers to program
variables. SPARC is more flexible because register window management is not
tied to procedure call and return (CALL and JMPL) instructions, as it is on the
Berkeley machines. Instead, separate instructions (SAVE and RESTORE)
provide register window management.

1.2. SPARC System Components

The architecture allows for a spectrum of input/output (I/O), memory management unit (MMU), and cache system sub-architectures. SPARC assumes that
these elements are optimally defined by the specific requirements of particular
systems. Note that they are invisible to nearly all user application programs and
the interfaces to them can be limited to localized modules in an associated
operating system.

Reference MMU
The SPARC ISA does not mandate that a single MMU design be used for all system implementations. Rather, designers are free to use the MMU that is most
appropriate for their application — or no MMU at all, if they wish. A SPARC
“Reference MMU” has been specified, which is appropriate for a wide range of
applications. See Appendix H, “SPARC Reference MMU Architecture,” for
more information.

Supervisor Software
SPARC does not assume all implementations must execute identical supervisor
software. Thus, certain supervisor-visible traits of an implementation can be
tailored to the requirements of the system. For example, SPARC allows for
implementations with different instruction concurrency and different exception
trap hardware.

Memory Model
A standard memory model called Total Store Ordering (TSO) is defined for
SPARC. The model applies both to uniprocessors and to shared-memory multiprocessors. The memory model guarantees that the stores, FLUSHes, and
atomic load-stores of all processors are executed by memory serially in an order
that conforms to the order in which the instructions were issued by processors.
All SPARC implementations must support TSO.

An additional model called Partial Store Ordering (PSO) is defined, which allows
higher-performance memory systems to be built.

Machines (including all early SPARC-based systems) that implement Strong
Consistency (also known as Strong Ordering) automatically satisfy both TSO and
PSO. Machines that implement TSO automatically satisfy PSO.

1.3. SPARC Compliance Definitions

An important SPARC International Compatibility and Compliance Committee
function is to establish and publish SPARC Compliance Definitions (SCDs) and
migration guidelines between successive definitions. SCD use accelerates
development of binary-compatible SPARC/UNIX systems and software for both
system vendors and ISV members. SPARC binaries executed in user mode
should behave identically on all SPARC systems when those systems are running
an operating system known to provide a standard execution environment.

AT&T and SPARC International have developed a standard Application Binary
Interface (ABI) for the development of SPARC application code. Software conforming to this specification will produce the same results on every SPARC
ABI-compliant system, enabling the distribution of ‘‘shrink-wrapped’’ SPARC
software. Although different SPARC systems will execute programs at different
rates, they will generate the same results.

The formulation of SPARC Compliance Definitions (SCD 1.0 and SCD 2.0) by
SPARC International allows member companies to verify compliance of a broad
base of SPARC/UNIX products through openly agreed-upon, standard
definitions. SCD 2.0 is a superset of the SPARC ABI.

SCD 1.0 compliance is the formal beginning of migration to SCD 2.0, based on
the industry-standard UNIX System V Release 4 operating system from AT&T
and the OPEN LOOK graphical user interface. SPARC International’s Compatibility and Compliance Committee works to make this migration as smooth and as
representative of the members’ interests as possible.

The System V ABI from AT&T consists of two components: the processor
independent generic specification and the processor (SPARC)-specific supplement. (Consult the AT&T manuals for strict adherence to the SCD 2.0 binary
interface conventions.)

SPARC International participates in all ABI specification reviews, and tests for
ABI compliance as part of the SCD 2.0 verification process. For more details on
SCD 2.0, contact SPARC International, 535 Middlefield Road, Suite 210, Menlo
Park, California 94025.

1.4. SPARC Features

SPARC includes the following principal features:

  • A linear, 32-bit address space.
  • Few and simple instruction formats — All instructions are 32 bits wide, and
    are aligned on 32-bit boundaries in memory. There are only three basic
    instruction formats, and they feature uniform placement of opcode and register address fields. Only load and store instructions access memory and I/O.
  • Few addressing modes — A memory address is given by either “register +
    register” or “register+immediate.”
  • Triadic register addresses — Most instructions operate on two register
    operands (or one register and a constant), and place the result in a third
    register.
  • A large “windowed” register file — At any one instant, a program sees 8
    global integer registers plus a 24-register window into a larger register file.
    The windowed registers can be described as a cache of procedure arguments,
    local values, and return addresses.
  • A separate floating-point register file — configurable by software into 32
    single-precision (32-bit), 16 double-precision (64-bit), 8 quad-precision
    registers (128-bit), or a mixture thereof.
  • Delayed control transfer — The processor always fetches the next instruction after a delayed control-transfer instruction. It either executes it or not,
    depending on the control-transfer instruction’s “annul” bit.
  • Fast trap handlers — Traps are vectored through a table, and cause allocation of a fresh register window in the register file.
  • Tagged instructions — The tagged add/subtract instructions assume that the
    two least-significant bits of the operands are tag bits.
  • Multiprocessor synchronization instructions — One instruction performs an
    atomic read-then-set-memory operation; another performs an atomic
    exchange-register-with-memory operation.
  • Coprocessor — The architecture defines a straightforward coprocessor
    instruction set, in addition to the floating-point instruction set.

1.5. Conformability to SPARC

An implementation that conforms to the definitions and algorithms given in this
document is an implementation of the SPARC ISA.

The SPARC architecture is a model which specifies unambiguously the behavior
observed by software on SPARC systems. Therefore, it does not necessarily
describe the operation of the hardware in any actual implementation.

An implementation is not required to execute every instruction in hardware. An
attempt to execute a SPARC instruction that is not implemented in hardware
generates a trap. If the unimplemented instruction is nonprivileged, then it must
be possible to emulate it in software. If it is a privileged instruction, whether it is
emulated by software is implementation-dependent. Appendix L, “Implementation Characteristics,” details which instructions are not in hardware in existing
implementations.

Compliance with this specification shall be claimed only by a collection of components which is capable of fully implementing all SPARC opcodes, through any
combination of hardware or software. Specifically, nonprivileged instructions
which are not implemented in hardware must trap to the software such that they
can be implemented in software. For the implementation to be complete, by
default the implementation must trap and report all undefined, unimplemented,
and reserved instructions.

Some elements of the architecture are defined to be implementation-dependent.
These elements include certain registers and operations that may vary from
implementation to implementation, and are explicitly identified in this document.

Implementation elements (such as instructions or registers) that appear in an
implementation but are not defined in this document (or its updates) are not considered to be SPARC elements of that implementation.

Note that a “SPARC Architecture Test Suite” and a “SPARC Architectural
Simulator” (SPARCsim) are available.

全文翻译

1.1. SPARC Attributes

SPARC 特性
SPARC is a CPU instruction set architecture (ISA), derived from a reduced
instruction set computer (RISC) lineage. As an architecture, SPARC allows for a
spectrum of chip and system implementations at a variety of price/performance
points for a range of applications, including scientific/engineering, programming,
real-time, and commercial.

PARC是一个CPU指令集体系结构(ISA),从一个简化的指令集计算机(RISC)派系。作为一种体系结构,SPARC允许在一系列应用程序中以各种价格/性能点进行芯片和系统实现,包括科学/工程、编程、实时和商业应用程序。

Design Goals
设计目标
SPARC was designed as a target for optimizing compilers and easily pipelined
hardware implementations. SPARC implementations provide exceptionally high
execution rates and short time-to-market development schedules.
SPARC被设计为优化编译器和易于流水线的硬件实现的目标。SPARC的实现提供了异常高的执行率和较短的上市时间开发时间表。

Register Windows
寄存器窗口
SPARC, formulated at Sun Microsystems in 1985, is based on the RISC I & II
designs engineered at the University of California at Berkeley from 1980 through
1982. the SPARC “register window” architecture, pioneered in UC Berkeley
designs, allows for straightforward, high-performance compilers and a significant
reduction in memory load/store instructions over other RISCs, particularly for
large application programs.

SPARC于1985年在Sun微系统公司制定,基于加州大学伯克利分校1980年至1982年设计的RISCI&II设计。SPARC“注册窗口”架构,在加州大学伯克利分校设计中首创,允许直接、高性能的编译器,并比其他RISC显著减少内存负载/存储指令,特别是对于大型应用程序。

For languages such as C++, where object-oriented programming is dominant,
register windows result in an even greater reduction in instructions executed.
Note that supervisor software, not user programs, manages the register windows.
A supervisor can save a minimum number of registers (approximately 24) at the
time of a context switch, thereby optimizing context switch latency.

对于像C++这样的语言,面向对象编程占主导地位,寄存器窗口会导致更大的指令执行减少。请注意,管理注册窗口的是主管软件,而不是用户程序。主管软件可以在上下文切换时保存最少数量的寄存器(大约24个),从而优化上下文切换延迟。

One difference between SPARC and the Berkeley RISC I & II is that SPARC
provides greater flexibility to a compiler in its assignment of registers to program
variables. SPARC is more flexible because register window management is not
tied to procedure call and return (CALL and JMPL) instructions, as it is on the
Berkeley machines. Instead, separate instructions (SAVE and RESTORE)
provide register window management.

SPARC和BerkleyRISCI和II之间的一个区别是,SPARC在向程序变量分配寄存器时为编译器提供了更大的灵活性。SPARC更灵活,因为寄存器窗口管理不像过程调用和返回(CALL和JMPL)指令绑定,因为它是在伯克利机器上。相反,单独的指令(保存和恢复)提供了寄存器窗口管理。

1.2. SPARC System Components

SPARC系统组成
The architecture allows for a spectrum of input/output (I/O), memory management
unit (MMU), and cache system sub-architectures. SPARC assumes that
these elements are optimally defined by the specific requirements of particular
systems. Note that they are invisible to nearly all user application programs and
the interfaces to them can be limited to localized modules in an associated
operating system.

该架构允许包括输入/输出(I/O)、内存管理单元(MMU)和缓存系统子架构。SPARC假设这些元素是由特定系统的特定需求最优定义的。请注意,它们对几乎所有的用户应用程序都是不可见的,而且与它们相关的接口可以仅限于相关联的操作系统中的本地化模块。

Reference MMU
The SPARC ISA does not mandate that a single MMU design be used for all system
implementations. Rather, designers are free to use the MMU that is most
appropriate for their application — or no MMU at all, if they wish. A SPARC
“Reference MMU” has been specified, which is appropriate for a wide range of
applications. See Appendix H, “SPARC Reference MMU Architecture,” for
more information.

SPARCISA并没有要求对所有系统实现都使用单一的MMU设计。相反,设计师可以自由地使用最适合他们的应用程序的MMU——或者如果他们愿意的话,根本不使用MMU。已指定了一个SPARC“参考MMU”,它适用于广泛的应用程序。有关更多信息,请参见附录H,“SPARC参考MMU体系结构”。

Supervisor Software
主管软件
SPARC does not assume all implementations must execute identical supervisor
software. Thus, certain supervisor-visible traits of an implementation can be
tailored to the requirements of the system. For example, SPARC allows for
implementations with different instruction concurrency and different exception
trap hardware.

SPARC并不假设所有的实现都必须执行相同的主管软件。因此,实现的某些监督可见特征可以根据系统的需求进行定制。例如,SPARC允许使用不同的指令并发性和不同的异常陷阱硬件进行实现。

Memory Model
内存模型
A standard memory model called Total Store Ordering (TSO) is defined for
SPARC. The model applies both to uniprocessors and to shared-memory multiprocessors. The memory model guarantees that the stores, FLUSHes, and
atomic load-stores of all processors are executed by memory serially in an order
that conforms to the order in which the instructions were issued by processors.
All SPARC implementations must support TSO.

为SPARC定义了一个称为总存储排序(TSO)的标准内存模型。该模型既适用于单处理器,也适用于共享内存的多处理器。内存模型保证所有处理器的存储、FLUSHEs和原子加载存储都由存储器按照符合处理器发出指令的顺序串行执行。所有的SPARC实现都必须支持TSO。

An additional model called Partial Store Ordering (PSO) is defined, which allows
higher-performance memory systems to be built.

定义了一个称为部分存储排序(PSO)的附加模型,它允许构建更高性能的内存系统。

Machines (including all early SPARC-based systems) that implement Strong
Consistency (also known as Strong Ordering) automatically satisfy both TSO and
PSO. Machines that implement TSO automatically satisfy PSO.

实现强一致性(也称为强排序)的机器(包括所有早期基于sparc的系统)会自动满足TSO和PSO。实现TSO的机器会自动满足PSO的要求。

1.3. SPARC Compliance Definitions

SPARC合规定义
An important SPARC International Compatibility and Compliance Committee
function is to establish and publish SPARC Compliance Definitions (SCDs) and
migration guidelines between successive definitions. SCD use accelerates
development of binary-compatible SPARC/UNIX systems and software for both
system vendors and ISV members. SPARC binaries executed in user mode
should behave identically on all SPARC systems when those systems are running
an operating system known to provide a standard execution environment.

其功能是在连续的定义之间建立和发布SPARC遵从性定义(SCDs)和迁移指南。SCD的使用加速了为系统供应商和ISV成员提供的与二进制兼容的SPARC/UNIX系统和软件的开发。当所有SPARC二进制系统运行的操作系统时,这些SPARC系统上的行为应该相同。

AT&T and SPARC International have developed a standard Application Binary
Interface (ABI) for the development of SPARC application code. Software conforming to this specification will produce the same results on every SPARC
ABI-compliant system, enabling the distribution of ‘‘shrink-wrapped’’ SPARC
software. Although different SPARC systems will execute programs at different
rates, they will generate the same results.

AT&T和SPARC国际公司已经开发了一个标准的应用程序二进制接口(ABI),用于开发SPARC应用程序代码。符合本规范的软件将在每个符合SPARCabi的系统上产生相同的结果,从而能够分发“收缩包装”的SPARC软件。尽管不同的SPARC系统将以不同的速率执行程序,但它们将产生相同的结果。

The formulation of SPARC Compliance Definitions (SCD 1.0 and SCD 2.0) by
SPARC International allows member companies to verify compliance of a broad
base of SPARC/UNIX products through openly agreed-upon, standard
definitions. SCD 2.0 is a superset of the SPARC ABI.

SPARC国际制定了SPARC合规定义(SCD1.0和SCD2.0),允许成员公司通过公开同意的标准定义来验证广泛的SPARC/UNIX产品的合规性。SCD2.0是SPARCABI的一个超集。

SCD 1.0 compliance is the formal beginning of migration to SCD 2.0, based on
the industry-standard UNIX System V Release 4 operating system from AT&T
and the OPEN LOOK graphical user interface. SPARC International’s Compatibility and Compliance Committee works to make this migration as smooth and as
representative of the members’ interests as possible.

SCD1.0合规是迁移到SCD2.0迁移的正式开始,基于AT&T的行业标准UNIX系统V版本4操作系统和OPENLOOK图形用户界面。SPARC国际的兼容性和合规委员会致力于使这次迁移尽可能顺利,并尽可能代表成员的利益。

The System V ABI from AT&T consists of two components: the processor
independent generic specification and the processor (SPARC)-specific supplement. (Consult the AT&T manuals for strict adherence to the SCD 2.0 binary
interface conventions.)

AT&T的SystemVABI由两个组件组成:处理器独立的通用规范和处理器(SPARC)特定的补充。(有关严格遵守SCD2.0二进制接口约定,请参考AT&T手册。)

SPARC International participates in all ABI specification reviews, and tests for
ABI compliance as part of the SCD 2.0 verification process. For more details on
SCD 2.0, contact SPARC International, 535 Middlefield Road, Suite 210, Menlo
Park, California 94025.

作为SCD2A.0验证过程的一部分,SPARCI国际参与了所有ABI规范审查,以及ABI符合性的测试。有关SCD2.0的更多细节,请联系SPARC国际,米德尔菲尔德路535号,210室,门洛帕克,加州94025。

1.4. SPARC Features

SPARC功能
SPARC includes the following principal features:
SPARC包括以下主要功能

  • A linear, 32-bit address space.
    一个32位的线性地址空间。
  • Few and simple instruction formats — All instructions are 32 bits wide, and
    are aligned on 32-bit boundaries in memory. There are only three basic
    instruction formats, and they feature uniform placement of opcode and register address fields. Only load and store instructions access memory and I/O.
    很少和简单的指令格式——所有的指令都是32位宽的,并且在内存中的32位边界上对齐。只有三种基本的指令格式,它们的特点是操作码和寄存器地址字段的统一放置。只有加载和存储指令才能访问内存和I/O。
  • Few addressing modes — A memory address is given by either “register + register” or “register+immediate.”
    少数寻址模式——内存地址由“寄存器+寄存器”或“寄存器+立即”给出。
  • Triadic register addresses — Most instructions operate on two register
    operands (or one register and a constant), and place the result in a third
    register.
    三元寄存器地址——大多数指令在两个寄存器操作数(或一个寄存器和一个常数)上操作,并将结果放在第三个寄存器中。=
  • A large “windowed” register file — At any one instant, a program sees 8
    global integer registers plus a 24-register window into a larger register file.
    The windowed registers can be described as a cache of procedure arguments,
    local values, and return addresses.
    一个大的“窗口”寄存器文件——在任何一个时刻,一个程序都会看到8个全局整数寄存器和一个24个寄存器窗口进入到一个更大的寄存器文件中。窗口寄存器可以描述为过程参数、本地值和返回地址的缓存。
  • A separate floating-point register file — configurable by software into 32
    single-precision (32-bit), 16 double-precision (64-bit), 8 quad-precision
    registers (128-bit), or a mixture thereof.
    一个独立的浮点寄存器文件,可通过软件配置为32个单精度(32位)、16个双精度(64位)、8个四精度寄存器(128位)或它们的混合物。
  • Delayed control transfer — The processor always fetches the next instruction after a delayed control-transfer instruction. It either executes it or not,
    depending on the control-transfer instruction’s “annul” bit.
    延迟控制传输—处理器总是在延迟控制传输指令后获取下一条指令。它可以执行或不执行它,这取决于控制传输指令的“取消”位。
  • Fast trap handlers — Traps are vectored through a table, and cause allocation of a fresh register window in the register file.
  • 快速陷阱处理程序——陷阱通过一个表进行矢量处理,并导致在寄存器文件中分配一个新的寄存器窗口。
  • Tagged instructions — The tagged add/subtract instructions assume that the
    two least-significant bits of the operands are tag bits.标记指令-标记的加减指令假设操作数中两个最不重要的位是标记位。
  • Multiprocessor synchronization instructions — One instruction performs an
    atomic read-then-set-memory operation; another performs an atomic
    exchange-register-with-memory operation.
    多处理器同步指令—一条指令执行原子读取后设置的内存操作;另一条指令执行原子与内存交换寄存器操作。
  • Coprocessor — The architecture defines a straightforward coprocessor
    instruction set, in addition to the floating-point instruction set.
    协处理器——除了浮点指令集之外,该体系结构还定义了一个简单的协处理器指令集。

1.5. Conformability to SPARC

与SPARC的兼容性
An implementation that conforms to the definitions and algorithms given in this
document is an implementation of the SPARC ISA.
符合本文档中给出的定义和算法的实现是SPARCISA的实现。
The SPARC architecture is a model which specifies unambiguously the behavior
observed by software on SPARC systems. Therefore, it does not necessarily
describe the operation of the hardware in any actual implementation.
SPARC架构是一个明确指定SPARC系统上软件观察到的行为的模型。因此,它不一定描述任何实际实现中硬件的操作。

An implementation is not required to execute every instruction in hardware. An
attempt to execute a SPARC instruction that is not implemented in hardware
generates a trap. If the unimplemented instruction is nonprivileged, then it must
be possible to emulate it in software. If it is a privileged instruction, whether it is
emulated by software is implementation-dependent. Appendix L, “Implementation Characteristics,” details which instructions are not in hardware in existing
implementations.

在硬件中执行每一条指令都不需要一个实现。尝试执行未在硬件中实现的SPARC指令会产生一个陷阱。如果未实现的指令是非特权的,那么它必须能够在软件中模拟它。如果它是一个特权指令,那么它是否被软件模拟就依赖于实现。附录L,“实现特性”,详细说明了在现有实现中没有使用硬件的指令。

Compliance with this specification shall be claimed only by a collection of components which is capable of fully implementing all SPARC opcodes, through any
combination of hardware or software. Specifically, nonprivileged instructions
which are not implemented in hardware must trap to the software such that they
can be implemented in software. For the implementation to be complete, by
default the implementation must trap and report all undefined, unimplemented,
and reserved instructions.

只有通过一组能够通过任何硬件或软件的组合来完全实现所有SPARC操作码的组件来要求符合本规范。具体来说,没有在硬件中实现的非特权指令必须陷阱到软件上,以便它们可以在软件中实现。为了完成实现,默认情况下,实现必须捕获并报告所有未定义、未实现和保留的指令。

Some elements of the architecture are defined to be implementation-dependent.
These elements include certain registers and operations that may vary from
implementation to implementation, and are explicitly identified in this document.

体系结构中的某些元素被定义为依赖于实现的元素。这些元素包括某些寄存器和操作,它们可能因实现而异,并在本文档中得到明确标识。

Implementation elements (such as instructions or registers) that appear in an
implementation but are not defined in this document (or its updates) are not considered to be SPARC elements of that implementation.

在实现中出现但未在本文档(或其更新)中进行定义的实现元素(如指令或寄存器)不被认为是该实现的SPARC元素。
Note that a “SPARC Architecture Test Suite” and a “SPARC Architectural
Simulator” (SPARCsim) are available.

请注意,这里有一个“SPARC体系结构测试套件”和一个“SPARC体系结构模拟器”(SPARCsim)。

【002】SPARC V8 体系结构第一章介绍相关推荐

  1. 第一章 介绍-机器学习老师板书-斯坦福吴恩达教授

    第一章 介绍 1.1 欢迎 1.2 什么是机器学习 1.3 监督学习 1.4 无监督学习 1.1 欢迎 1.2 什么是机器学习 1.3 监督学习 1.4 无监督学习

  2. CG系统提交Java程序_Cg使用说明 第一章 介绍

    Cg使用说明 第一章介绍 本章有以下四个部分: "什么是Cg?"介绍Cg编程语言 "顶点.片段和图形管线"描述现代显示硬件的数据流,以及Cg如何与之融为一体的使 ...

  3. After Effects CC SDK 使用指南(二)—— 第一章 介绍 (上)

    其他文章链接 序 第一章 介绍-上 第一章 介绍-下 第一章 介绍 欢迎使用Adobe®After Effects®CC软件开发工具包!这是一个全新的文档,并不断更新.SDK的最新公共版本地址:htt ...

  4. 敏捷整洁之道 -- 第一章 介绍敏捷

    敏捷整洁之道 -- 第一章 介绍敏捷 1. 敏捷的历史 2. 敏捷中心思想 3. 敏捷全貌 3.1 铁十字 3.2 墙上的图 3.3 需要知道的第一件事 3.4 分析.设计.实施阶段 3.5 敏捷项目 ...

  5. vtk教程第一章介绍

    可视化-"2:用视觉术语解释或将其转化为视觉形式的行为或过程",<韦伯斯特第九部新大学词典>收录. 1.1什么是可视化 想象是我们日常生活的一部分.从天气图到娱乐行业令 ...

  6. ACPI Specification 第一章 介绍

    目录 1.1主要目标 1.2电源管理基本原理 1.3传统的支持 1.4 OEM实现策略 1.5电源和休眠按钮 1.6 ACPI规范和ACPI结构 1.7 操作系统和平台遵从性 1.7.1 acpi定义 ...

  7. 有关H5的第一章介绍

    第一章 1.HTML也成为超文本标记语言,扩展名为.html或.htm 2.修改文件名的快捷键:F2 , 注释的快捷键:ctrl+shift+/ 即 <!- - XXXX–> 3.空格:& ...

  8. Windows Forms 2.0 Programming 花边(002)——失算!第一章的下马威

    突然发现译书的感觉就像五小强打十二宫一样--译完一章又一章,没完没了的.不过,圣殿山底下躺着的是Athena,我这儿不一样-- 书堆儿里躺着的是咱们的编辑.(>_<) 译完前言和序言,直奔 ...

  9. 《Fundamentals of Computer Grahpics 4ed》虎书第四版翻译——第一章 介绍

    文章目录 1.1 图形学领域 1.2 主要应用 1.3 图形学API 1.4 图形管线 1.5 数值问题 1.6 效率 1.7 设计和编写图形程序 1.7.1 类设计 1.7.2 Float还是Dou ...

最新文章

  1. 行如风 Angular 初识3
  2. 参数修饰符 params、in
  3. python超出列表范围,(Python)列表索引超出范围 - 迭代
  4. 【程序5】 题目:利用条件运算符的嵌套来完成此题:学习成绩=90分的同学用A表示,60-89分之间的用B表示,60分以下的用C表示。 1.程序分析:(ab)?a:b这是条件运算符的基本例子。...
  5. ubuntu18.0.4 不能下载 libgd2-dev(ubuntu 20.04 安装perl 中GD 模块失败的解决办法)
  6. com.taobao.config.client.exception.ConfigClientException: cannot get serverlist, so exit jvm env=DEF
  7. 关于JVM默认内存的增加
  8. [转]面向对象的三个基本特征
  9. qq浏览器插件_惊艳与吐槽:QQ浏览器升级到 Chromium70 内核以后
  10. HDU2588 欧拉函数
  11. 斯坦福大学深度学习公开课cs231n学习笔记(2)线性分类器及最优化
  12. js刷新当前页面的几种方式
  13. 应届生求职简历HTML模板
  14. Kali 安装 xmapp、DVWA
  15. 金税盘没有及时清卡怎么办
  16. Oracle 官网JDK下载地址
  17. 最新传智播客nodejs入门到精通(基础就业)全套nodejs视频教程
  18. 假定系统四个进程,p1、p2、p3、p4三种资源r1、r2、r3数量分别为9、3、6在T0时刻资源分配为下表:
  19. linux系统mysql密码忘记了怎么办_Linux中MySQL密码忘了怎么办
  20. Java实现 蓝桥杯 算法训练 未名湖边的烦恼

热门文章

  1. 分布式系统论文精读2:GFS
  2. python认证教程_基于 Python+SendCloud 的邮箱认证
  3. 软件开发项目为什么要做第三方软件测试,软件测评机构怎么选择?
  4. 全国计算机一级选择题免费,全国计算机一级考试选择题试题与详细答案
  5. 8大蓝牙电路应用热门方案,快速简单实现近距离无线连接
  6. mysql数据库出现缓慢_MySQL查询缓慢的N种原因,以及N+1种解决方法
  7. 丙腈PEG丙腈, CN-PEG-C
  8. 2018 滴滴出行校招笔试(单词纠错)
  9. 现代密码学导论-10-EAV安全
  10. Docker managed volume