4. Instruction Set Architecture

Introduction and Context

An instruction set architecture (ISA) is the programmer-visible contract between software and a processor implementation. It specifies the operations a processor can perform, the operands on which those operations operate, the organization of registers and memory, the representation of instructions, the rules for control transfer, and the behavior of exceptions and privileged operations. Microarchitecture, by contrast, describes how a particular processor implements that contract using pipelines, caches, speculation, execution units, and control logic.

The distinction is fundamental. Several processors may implement the same ISA while differing greatly in clock frequency, pipeline depth, power consumption, and performance. Conversely, a change in ISA may require changes throughout compilers, operating systems, debuggers, binary tools, and application software. ISA design is therefore neither merely a matter of encoding opcodes nor solely a hardware concern. It is a long-term architectural decision involving performance, software compatibility, security, verification, energy, and ecosystem development.

For a postgraduate computer engineering student, ISA must be studied as a set of trade-offs. A rich instruction may reduce program length but complicate decoding. A large register file may reduce memory traffic but increase instruction encoding cost and hardware energy. Strong memory-ordering rules simplify concurrent software but restrict implementation freedom. Open ISAs can encourage innovation, yet a successful ecosystem requires more than publishing an instruction manual.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Explain the role and boundaries of an ISA.

2. Evaluate choices involving operations, operands, registers, addressing modes, and instruction formats.

3. Distinguish fixed-length, variable-length, RISC, CISC, and VLIW design approaches.

4. Analyze control flow, exceptions, interrupts, privilege levels, and memory-access rules.

5. Explain how ISA decisions affect compilers, operating systems, performance, security, and compatibility.

6. Compare proprietary and open ISAs, including the design principles of RISC-V.

7. Apply an ISA evaluation framework to a practical processor-design scenario.

The ISA as a Contract

An ISA defines the state visible to software. This state normally includes general-purpose registers, special registers, the program counter, status and control registers, memory, and sometimes vector, floating-point, or capability registers. It also defines the legal transitions between states when instructions execute.

An ISA specification must answer several questions. What values can an instruction manipulate? How are integers, floating-point numbers, addresses, and Boolean conditions represented? Are operands held in registers, in memory, or in an implicit stack? How is an address calculated? What happens when an instruction is illegal, an address is misaligned, or a page is inaccessible? How does software request an operating-system service? These questions collectively determine the programming model.

The ISA is not required to expose every implementation detail. Cache size, pipeline organization, branch-predictor algorithm, and the number of physical registers used by register renaming are normally microarchitectural matters. However, the ISA may expose constraints that affect these mechanisms, such as atomicity, memory ordering, instruction alignment, or precise exception behavior.

A useful design principle is separation of architectural state from implementation state. Architectural registers must appear to software, whereas speculative results, reorder buffers, cache tags, and reservation stations need not. This separation allows implementations to evolve without invalidating compiled programs.

Operations and Operand Organization

The operation repertoire is the first visible dimension of an ISA. Most instruction sets provide integer arithmetic, logical operations, shifts, comparisons, loads and stores, branches, procedure linkage, and system-control operations. Many also provide floating-point, vector, cryptographic, atomic, and bit-manipulation instructions.

An instruction may have zero, one, two, or more explicit operands. A stack ISA uses implicit top-of-stack operands. An accumulator ISA uses an implicitly selected accumulator. A register-memory ISA permits an arithmetic instruction to combine a register with a memory operand. A load/store ISA restricts memory access to explicit load and store instructions; arithmetic instructions operate only on registers.

The load/store approach simplifies dependence analysis and pipeline control. Consider the operation `R3 = R1 + R2`. Both source operands are available in a uniform register structure, and the instruction does not also require address generation or cache access. In contrast, an instruction that adds a value directly from memory can reduce instruction count but introduces additional work for decoding, address calculation, exception handling, and scheduling.

The number of operands is also a code-density issue. Three-operand instructions preserve both source values and place the result in a separate destination, which is convenient for compilers. Two-operand instructions may overwrite one source and therefore require additional moves. Fewer explicit operands reduce encoding size but increase dependence on implicit state.

Complex instructions can be valuable when they express frequently occurring operations, such as atomic read-modify-write sequences, vector multiply-accumulate operations, or cryptographic transformations. The central question is not whether an instruction is “complex” in the abstract, but whether its semantic value justifies its effects on decoding, verification, compiler support, and implementation flexibility.

Registers, Memory, and Addressing

Registers provide low-latency storage for values actively used by a computation. A larger register set can reduce spills to memory and expose more independent operations to a compiler. It also increases the number of bits needed to identify registers within an instruction. Register files consume area and energy, and multiported designs become increasingly expensive as the number of simultaneous reads and writes grows.

ISAs commonly distinguish general-purpose registers from special-purpose registers. General-purpose registers may hold integers or addresses. Floating-point and vector registers may have separate formats and instruction encodings. Special registers may contain the program counter, stack pointer, link address, condition codes, exception information, or control and status fields.

The choice between condition codes and explicit comparison results illustrates a broader trade-off. Condition codes allow arithmetic instructions to set implicit flags and branches to test them. This can produce compact code, but flags create hidden dependencies: a later instruction may depend on which earlier instruction last modified the flags. Explicit comparison instructions produce Boolean values in registers, making dependencies more visible and often simplifying out-of-order scheduling.

Addressing modes determine how an instruction identifies an operand. Common modes include:

• Immediate addressing, in which a constant is encoded in the instruction.
• Register addressing, in which a register contains the operand.
• Base-plus-offset addressing, widely used for arrays, structures, and stack frames.
• Register-indirect addressing, in which a register contains an address.
• PC-relative addressing, useful for position-independent code and nearby branches.
• Indexed or scaled addressing, useful for array elements and table lookup.

A rich collection of addressing modes can improve code density and reduce explicit address-calculation instructions. However, every mode adds cases to the decoder, compiler back end, verification environment, and exception model. Modern RISC designs often emphasize a small set of regular modes, relying on simple instructions to construct more elaborate addresses.

Memory itself is not simply an unlimited array of bytes. An ISA may define byte ordering, alignment requirements, atomicity, access permissions, virtual-address behavior, memory types, and ordering constraints. These rules are essential to operating systems and concurrent programs.

Instruction Encoding and Code Density

Instruction encoding maps operation and operand information into bits. A format must allocate fields for the opcode, registers, immediate values, function modifiers, and sometimes addressing information. Fixed-length instructions simplify fetch alignment, parallel decoding, and instruction-cache organization. Variable-length instructions can improve code density by using short encodings for common operations and longer encodings for less common forms.

Code density matters because smaller programs require less instruction-cache capacity and memory bandwidth. This can improve energy efficiency and performance, especially in embedded systems. Yet variable-length encoding complicates instruction boundaries, parallel fetch, branch-target prediction, and security analysis. Some complex instruction set processors translate variable-length instructions into internal micro-operations, effectively separating an externally dense ISA from a simpler internal execution model.

Encoding design must also consider future extensions. Reserved opcode space, extension prefixes, versioning rules, and defined illegal-instruction behavior determine whether an ISA can evolve without breaking existing tools. A successful extension should be discoverable, composable, and sufficiently precise that different implementations produce compatible results.

Control Flow and Procedure Support

Control-flow instructions alter the program counter. Conditional branches test a condition, direct jumps transfer to a known target, indirect jumps compute a target from a register or memory-derived value, and procedure calls preserve a return address. Some ISAs use a link register; others use a stack or a combination of mechanisms.

Branch instructions create challenges for pipelined processors because the next sequential instruction may be fetched before the branch outcome is known. ISA design influences how easily a processor can predict and recover from branches. PC-relative branches support position-independent code and compact relocation, while indirect branches are essential for function pointers, virtual dispatch, and return instructions.

The ISA must define whether a branch delay slot exists, how branch targets are aligned, and what happens when a target is invalid. Contemporary high-performance designs generally avoid exposing pipeline delay slots because such details constrain future implementations. Instead, the processor predicts control flow and discards incorrectly speculated work.

Procedure-call conventions are not always part of the ISA specification, but they depend strongly on it. A calling convention assigns arguments, return values, saved registers, stack frames, and link addresses to architectural resources. Stable conventions enable separately compiled modules and operating-system interfaces to interoperate.

Exceptions, Interrupts, and Precise State

An exception is a synchronous event caused by the current instruction, such as an illegal opcode, arithmetic fault, page fault, or protection violation. An interrupt is generally an asynchronous event, such as a timer signal or device notification. The ISA must define how control transfers to a handler, what state is saved, how the cause is reported, and how execution resumes.

Precise exceptions mean that software observes a state in which all instructions before the fault have completed and no instruction after it has changed architectural state. Precise behavior simplifies operating-system recovery, debugging, and virtual-memory management. It can nevertheless complicate speculative and out-of-order implementations, which must delay or reorder visible updates until an instruction is known to retire safely.

Not every event must be restartable. Some system operations deliberately produce architecturally defined side effects before reporting a condition. Therefore, exception specifications must state restart behavior carefully. Ambiguity in this area can create operating-system bugs and incompatibility between implementations.

Privilege, Protection, and Virtualization

A general-purpose processor must prevent an application from directly controlling the entire machine. Privilege levels divide software into domains with different authority. User mode may execute ordinary arithmetic and access permitted memory, whereas supervisor or kernel mode may configure page tables, handle interrupts, and access devices. Some systems add a machine or hypervisor level for firmware and virtualization.

Privilege is meaningful only when combined with protection mechanisms. Memory-management units translate virtual addresses, check permissions, and isolate processes. Control and status registers define privileged state. System calls provide controlled entry into the operating system, while return instructions restore less-privileged execution.

Virtualization requires the processor to distinguish guest operations from host-controlled operations. Hardware support may provide a second level of address translation, virtual interrupt handling, and traps for operations that a guest cannot perform directly. The ISA should specify which operations trap, which state is saved, and how software identifies the cause.

Security is increasingly an ISA concern. Atomic instructions support locks and concurrent data structures. Fences define ordering of memory operations. Privileged instructions protect page-table and interrupt configuration. Cryptographic extensions can reduce exposure to timing-sensitive software implementations, although they do not automatically guarantee a secure system. Speculative execution vulnerabilities demonstrate that architectural permission checks and microarchitectural information leakage are related but distinct concerns.

RISC, CISC, and VLIW as Design Approaches

Reduced instruction set computer (RISC) design emphasizes a relatively regular instruction set, a load/store organization, many registers, simple addressing modes, and encoding forms that support efficient pipelining. The objective is not necessarily to minimize the total number of instructions, but to make individual instructions predictable and implementation-friendly. Compiler quality and code size remain important considerations.

Complex instruction set computer (CISC) design traditionally provides many operations, addressing modes, and instruction lengths. The intent may be to improve code density and express high-level operations directly. The cost is greater decode complexity and a larger semantic specification. Modern CISC processors often translate complex instructions into simpler internal operations, showing that ISA style and microarchitecture are not identical.

Very long instruction word (VLIW) architectures place multiple operations in one instruction word and rely heavily on the compiler to identify instruction-level parallelism. This can simplify hardware scheduling, but it exposes machine assumptions such as functional-unit availability and operation latency. Binary compatibility becomes difficult when a later implementation changes the execution resources. VLIW is attractive in domains with predictable workloads and strong compiler control, but less suitable where dynamic behavior and unpredictable memory latency dominate.

The RISC–CISC distinction should therefore be treated as a spectrum rather than a binary classification. A meaningful evaluation considers code density, decode energy, compiler complexity, hardware scheduling, compatibility, verification effort, and workload characteristics.

Open ISAs and RISC-V

An open ISA is specified under terms that permit broad access to the specification and, depending on the governing license and implementation terms, enable independent implementations. Openness can reduce dependence on a single supplier and support customization for education, research, embedded systems, accelerators, and domain-specific computing.

RISC-V illustrates a modular open ISA approach. It defines a small base integer instruction set and optional extensions for areas such as multiplication and division, atomic operations, floating point, vectors, and compressed instructions. The modular model permits a small embedded core and a larger application processor to share a common foundation while selecting different capabilities.

Modularity creates responsibilities. Software must know which extensions are available; toolchains must generate compatible binaries; operating systems must manage heterogeneous implementations; and extension designers must avoid semantic overlap or inconsistent memory behavior. Open governance does not remove the need for conformance testing, stable profiles, documentation, and ecosystem investment.

An open ISA may also be extended for domain-specific purposes. Such extensions should be evaluated by asking whether they deliver substantial workload benefit, whether their behavior is precisely specified, whether compilers can exploit them, and whether software can detect their availability. An extension that is efficient in hardware but inaccessible to compilers or libraries has limited practical value.

A Framework for Evaluating ISA Choices

ISA evaluation should begin with the target workload and system constraints rather than with a preference for a fashionable design style. The following questions provide a practical framework:

1. Semantic suitability: Does the ISA express important operations directly and correctly?

2. Implementation cost: What are the effects on decode, execution units, verification, power, and area?

3. Compiler relationship: Can register allocation, instruction selection, scheduling, and optimization exploit the design?

4. Code density and bandwidth: How large are typical programs, and what is the impact on caches and memory traffic?

5. Operating-system support: Are exceptions, virtual memory, privilege, atomics, and debugging adequately defined?

6. Compatibility and evolution: Can extensions be added without fragmenting the software ecosystem?

7. Security: Does the architecture provide suitable isolation, ordering, cryptographic support, and observability?

8. Lifecycle economics: Are tools, skilled engineers, verification assets, and long-term maintenance available?

No single metric captures ISA quality. Instruction count alone ignores instruction latency and memory behavior. Clock frequency alone ignores useful work per cycle. Code size alone ignores decode energy and compiler complexity. A sound decision uses representative workloads, compiler-generated binaries, emulation or RTL prototypes, and measurements of performance, energy, area, and verification effort.

Applied Case: Selecting an ISA for an Industrial Edge Controller

Background

This illustrative case concerns a manufacturer designing an industrial edge controller for robotic assembly lines. The controller must run real-time control loops, communicate over industrial networks, process sensor data, and execute a Linux-based supervisory application. The product is expected to remain in service for more than a decade.

Situation and Problem

The engineering team is considering three options: license an established proprietary CISC-compatible processor, adopt an established RISC application ISA, or develop a processor using an open modular ISA. The controller requires deterministic interrupt response, memory protection, atomic operations, floating-point support for control algorithms, and optional vector processing for signal analysis. Cost and long-term supply are significant concerns.

Analysis

The proprietary option offers mature tools and a large software base, reducing initial integration risk. However, licensing costs and dependence on a supplier may restrict customization. The established RISC option provides strong compiler and operating-system support, but the team has less control over specialized extensions. The open modular option allows the company to select a small base, add floating-point and atomic extensions, and design a custom signal-processing extension. Its risks include toolchain validation, board-support maturity, and the need to maintain internal architectural expertise.

Real-time behavior must be assessed separately from average benchmark performance. Interrupt entry, privilege transitions, cache effects, atomic instructions, and memory ordering are more relevant than a headline instruction-per-second figure. The team also examines whether the chosen ISA has stable debugging support, virtualization options for future products, and a clear mechanism for reporting supported extensions.

Approach and Solution

The team adopts a staged evaluation. First, it compiles representative control, networking, and signal-processing workloads for each candidate. Second, it measures worst-case interrupt latency and memory-system behavior on prototype implementations. Third, it estimates verification effort for privilege, atomicity, exception restart, and custom extensions. Finally, it compares five-year ecosystem and supply risks.

The selected design uses a modular open ISA with a standard integer base, atomic and floating-point extensions, and a carefully limited custom vector operation. The custom operation is exposed through a compiler intrinsic and has a software fallback. The product specification requires conformance testing and prohibits application binaries from depending on undocumented implementation behavior.

Outcome

The decision provides architectural flexibility while preserving a standard software foundation. The custom operation improves the targeted signal-processing workload, but the fallback ensures portability. The organization accepts additional initial engineering work in exchange for control over product differentiation and supply strategy.

Learning Points

The case demonstrates that ISA selection is a system decision. Openness alone does not guarantee success; standard extensions, toolchains, operating-system support, verification, and lifecycle planning are equally important. It also shows why real-time constraints, security boundaries, and maintainability must be evaluated alongside performance.

Challenges, Risks, and Common Mistakes

A frequent mistake is treating ISA simplicity as equivalent to implementation simplicity. A small instruction set can still require difficult memory ordering, privilege, vector, or virtualization behavior. The opposite mistake is adding instructions for every benchmark without considering compiler exposure, software compatibility, and verification cost.

Another risk is under-specification. Undefined behavior may permit implementation freedom, but if software depends on accidental behavior, different processors will diverge. Specifications should distinguish guaranteed behavior, implementation-defined behavior, and genuinely unpredictable behavior.

Memory consistency is particularly difficult. Weak ordering may enable hardware performance, but programmers and language runtimes need synchronization primitives and fences whose semantics are precise. Atomic instructions must define size, alignment, ordering, and failure behavior.

Compatibility can also fragment. Optional extensions are useful only when software can identify them and when platforms publish coherent profiles. A proliferation of incompatible custom instructions may create multiple isolated ecosystems rather than a common architecture.

Finally, architectural security claims must not be confused with complete security. Privilege modes and page permissions provide essential foundations, but secure boot, firmware governance, side-channel resistance, supply-chain controls, and software engineering remain necessary.

Professional and Governance Considerations

ISA work requires collaboration among hardware architects, compiler developers, operating-system engineers, verification specialists, security professionals, and product managers. A change that appears local to the decoder may alter exception timing, debugger behavior, ABI conventions, or formal verification obligations.

Governance is especially important for open or extensible ISAs. Extension proposals should include precise semantics, encoding allocation, interaction with existing instructions, toolchain requirements, compliance tests, and migration plans. Documentation should be versioned, and errata should be communicated transparently. For safety-critical or regulated products, traceability from requirements to architectural behavior and verification evidence is essential.

Current Developments and Emerging Directions

Several trends are shaping ISA design. Vector and matrix extensions respond to machine learning, scientific computing, multimedia, and signal-processing workloads. Specialized cryptographic instructions seek to improve performance while reducing reliance on vulnerable software routines. Hardware support for memory tagging, capabilities, confidential computing, and stronger isolation addresses security concerns that were once treated mainly as software problems.

Heterogeneous systems increasingly combine general-purpose cores, accelerators, and specialized processing units. Their ISAs must define data movement, synchronization, interrupt routing, and memory sharing clearly. At the same time, energy efficiency and domain-specific computing encourage compact cores and tailored extensions.

The long-term direction is not simply toward more instructions. It is toward better coordination among ISA semantics, compiler abstractions, operating-system policy, security models, and heterogeneous execution. The most valuable ISA innovations are those that provide a stable contract while leaving implementations room to improve.

Best Practices for ISA Design and Evaluation

A disciplined ISA project should:

• Begin with representative workloads and measurable system requirements.
• Keep architectural semantics precise, especially for memory, exceptions, atomics, and privilege.
• Separate essential functionality from optional extensions.
• Reserve encoding space and define a coherent versioning strategy.
• Design with compilers, debuggers, operating systems, and formal verification in mind.
• Provide conformance tests and reference models early.
• Evaluate code size, performance, energy, area, security, and development cost together.
• Avoid exposing accidental microarchitectural details as architectural guarantees.
• Offer software fallbacks for optional or specialized operations where portability matters.
• Treat ecosystem governance and long-term maintenance as architectural requirements.

Chapter Summary

An instruction set architecture is the durable software-visible contract of a processor. It defines operations, operands, registers, addressing modes, encodings, control flow, memory behavior, exceptions, privilege, and extension mechanisms, while leaving many implementation details to the microarchitecture. ISA choices influence compiler quality, code density, pipeline design, energy, operating-system support, security, compatibility, and product economics.

Load/store organization, regular encodings, and explicit operands can simplify implementation, whereas richer instructions and variable-length formats may improve code density or express domain-specific work efficiently. RISC, CISC, and VLIW represent different trade-offs rather than absolute categories. Open modular ISAs such as RISC-V demonstrate how a common base can coexist with optional and specialized extensions, but successful adoption requires tools, profiles, conformance, governance, and software support. A sound ISA evaluation is workload-driven and considers the complete system lifecycle rather than a single performance metric.

Key Terms

ISA: The programmer-visible specification of a processor’s operations, state, encoding, and behavior.

Microarchitecture: The internal implementation of an ISA, including pipelines, caches, and execution units.

Load/store architecture: An organization in which only load and store instructions access memory.

Addressing mode: The rule used to locate an instruction operand or calculate an effective address.

Register file: The collection of architecturally visible processor registers.

Immediate operand: A constant encoded directly within an instruction.

Instruction encoding: The binary representation of an instruction and its fields.

Code density: The amount of useful program functionality represented per unit of code storage.

Control flow: The sequence of instruction addresses executed by a program.

Exception: A synchronous event caused by execution of an instruction.

Interrupt: An asynchronous event requesting processor attention.

Precise exception: An exception whose visible state reflects completion only of preceding instructions.

Privilege level: A hardware-defined authority domain controlling access to protected operations and state.

Memory ordering: Rules governing the visibility and relative order of memory operations.

Atomic instruction: An operation that appears indivisible with respect to specified observers.

RISC: A design approach emphasizing regular instructions, registers, and efficient implementation.

CISC: A design approach traditionally offering numerous operations, addressing modes, or variable-length instructions.

VLIW: An architecture in which a wide instruction encodes multiple operations scheduled largely by the compiler.

RISC-V: A modular open ISA based on a standard base and optional extensions.

ABI: The binary interface conventions governing calling, registers, data layout, and linkage between software components.

Review Questions

Short Answer Questions

1. Distinguish ISA from microarchitecture.

2. Why are load/store instructions useful in a pipelined processor?

3. What is a precise exception?

4. Define PC-relative addressing and state one use for it.

5. Why do optional ISA extensions require software-detection mechanisms?

Long Answer Questions

1. Explain how operations, operand organization, registers, and addressing modes jointly affect compiler and hardware design.

2. Compare fixed-length and variable-length instruction encodings with respect to code density, decoding, and implementation complexity.

3. Discuss the role of exceptions, interrupts, privilege levels, and virtual memory in a general-purpose ISA.

4. Compare RISC, CISC, and VLIW approaches, identifying the major trade-offs associated with each.

5. Explain the benefits and governance challenges of a modular open ISA such as RISC-V.

Analytical / Application Questions

1. A processor designer proposes adding a memory operand to every arithmetic instruction to reduce instruction count. Analyze the likely effects on decoding, pipelining, exceptions, compiler scheduling, and code density.

2. An embedded controller requires low power, deterministic interrupt response, protected memory, and occasional signal-processing acceleration. Develop an ISA evaluation framework and recommend the evidence that should be collected before selection.

3. Two processors implement the same ISA, but one has a deeper pipeline and a more aggressive branch predictor. Explain which properties remain identical at the ISA level and which performance behaviors may differ.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes an ISA from a microarchitecture?

A. The ISA specifies cache replacement, while the microarchitecture specifies source-code syntax.

B. The ISA defines programmer-visible behavior, while the microarchitecture describes its implementation.

C. The ISA controls manufacturing cost, while the microarchitecture defines operating-system policy.

D. The ISA is used only by compilers, while the microarchitecture is used only by debuggers.

Correct Answer: B. The ISA defines programmer-visible behavior, while the microarchitecture describes its implementation.

Question 2

Why does a load/store ISA generally simplify pipeline implementation?

A. It eliminates the need for registers.

B. It allows every instruction to access memory simultaneously.

C. It confines memory access to explicit instructions and keeps arithmetic operands in registers.

D. It guarantees that all branches are correctly predicted.

Correct Answer: C. It confines memory access to explicit instructions and keeps arithmetic operands in registers.

Question 3

What is a major advantage of PC-relative addressing?

A. It removes the need for a program counter.

B. It supports position-independent code and nearby control-flow targets efficiently.

C. It permits arithmetic instructions to ignore registers.

D. It guarantees virtual addresses are physically contiguous.

Correct Answer: B. It supports position-independent code and nearby control-flow targets efficiently.

Question 4

Which feature is most directly associated with precise exceptions?

A. The visible state appears as if instructions after the fault have not changed architectural state.

B. All instructions execute in exactly one clock cycle.

C. Every interrupt is converted into a branch delay slot.

D. Cache misses are prevented during privileged execution.

Correct Answer: A. The visible state appears as if instructions after the fault have not changed architectural state.

Question 5

A variable-length encoding is selected primarily to improve code density. What is a likely accompanying cost?

A. Simpler instruction-boundary detection

B. More complicated fetch and decode logic

C. Removal of all register fields

D. Inability to support procedure calls

Correct Answer: B. More complicated fetch and decode logic

Question 6

Which situation most strongly motivates explicit comparison results instead of implicit condition codes?

A. The designer wants hidden dependencies between instructions.

B. The processor must make data dependencies more visible to an out-of-order scheduler.

C. The ISA must prevent all conditional branches.

D. The processor has no general-purpose registers.

Correct Answer: B. The processor must make data dependencies more visible to an out-of-order scheduler.

Question 7

What is a defining characteristic of VLIW designs?

A. The compiler schedules multiple operations within a wide instruction word.

B. All instructions must access memory.

C. The processor has no instruction encoding.

D. The operating system schedules every arithmetic operation.

Correct Answer: A. The compiler schedules multiple operations within a wide instruction word.

Question 8

Which combination is most relevant when evaluating a privileged ISA design?

A. Page protection, controlled system entry, and exception handling

B. Screen resolution, keyboard layout, and file naming

C. Database indexing, application themes, and source-code comments

D. Printer speed, display color depth, and audio sampling rate

Correct Answer: A. Page protection, controlled system entry, and exception handling

Question 9

Why can an uncontrolled collection of custom ISA extensions harm compatibility?

A. Custom instructions always reduce hardware performance.

B. Different software ecosystems may depend on mutually unavailable operations.

C. Extensions prevent the processor from having registers.

D. Custom instructions cannot be represented in binary form.

Correct Answer: B. Different software ecosystems may depend on mutually unavailable operations.

Question 10

In the industrial controller case, why was a software fallback provided for the custom vector operation?

A. To ensure portability when the specialized extension is unavailable

B. To eliminate the need for a compiler

C. To make privileged instructions executable in user mode

D. To guarantee that the custom operation has no performance benefit

Correct Answer: A. To ensure portability when the specialized extension is unavailable