Question 1

Language processors: which software can be used to convert or directly execute high-level language instructions with respect to machine-level operations?

Accepted Answer

Introduction / Context: High-level languages (HLL) must ultimately drive machine-level operations. Two common approaches are compilation (translate entire source to machine/object code before execution) and interpretation (an engine reads HLL statements and executes them, mapping to machine operations on the fly). This question asks you to identify a software type that may be used for that conversion/execution process. Given Data / Assumptions: We are considering ways to run HLL programs on real hardware. The focus is on tools that bridge HLL statements and machine-level execution. Multiple categories exist (compiler, interpreter, JIT); only certain terms appear in the options. Concept / Approach: An interpreter processes high-level statements one by one (or in small units), carrying out the required actions by invoking machine-level routines. Although compilers are also common, the listed options include the explicit term “interpreter,” which is a canonical tool for converting/executing HLL instructions relative to the machine. Step-by-Step Solution: 1) Identify that we need a tool that bridges HLL and machine execution.2) Recognize that an interpreter parses statements and performs the corresponding machine-level actions, often without creating a separate executable file.3) Select “an interpreter” from the choices, as it explicitly performs the conversion/execution. Verification / Alternative check: Classic examples include Python and many BASIC dialects, where the interpreter reads source and executes. Even hybrid environments (JITs) conceptually interpret bytecode before optimizing, underscoring the interpretive pathway as a valid HLL-to-machine bridge. Why Other Options Are Wrong: System software: A broad category that includes interpreters and compilers but is not itself a specific tool. Applications software: End-user programs; not language processors. An operating environment: Provides services/abstractions; does not inherently translate HLL to machine instructions. None of the above: Incorrect because an interpreter fits. Common Pitfalls: Equating only “compiler” with translation. Interpreters are equally valid, especially for rapid development and scripting. The wording “might be used” admits interpretation as a correct choice. Final Answer: an interpreter.

Question 2

IBM System/370 assembler programming: which statement accurately characterizes a capability of the assembler language concerning address formation?

Accepted Answer

Introduction / Context: On IBM System/360/370-class architectures, addressing frequently uses a base register plus displacement. Assembler language exposes these details directly, giving the programmer precise control over which register serves as a base and what displacement is used for an operand. This question checks familiarity with that low-level capability. Given Data / Assumptions: Context is System/370 assembler, not high-level languages. We are discussing how effective addresses are specified. Other listed statements mix OS concepts or runtime environment features unrelated to the assembler syntax per se. Concept / Approach: System/370 assembler operands often take the form D(B), meaning an effective address computed as displacement D added to the contents of base register B. Programmers explicitly choose B (and sometimes index registers) and write the displacement in the source code. This is a hallmark of low-level control in assembler programming. Step-by-Step Solution: 1) Identify that the question asks about assembler language features, not OS features.2) Recall assembler operand formats such as D(B), D(X,B), where B is a base register.3) Conclude that the capability to specify base registers and displacements explicitly belongs to the assembler. Verification / Alternative check: Any System/370 assembler reference shows instruction formats where operands explicitly include base and displacement fields (e.g., using USING directives to establish base assumptions and explicit D(B) in operands), confirming this behavior. Why Other Options Are Wrong: Refers to control programs: That is terminology about the OS, not assembler syntax. “Remember which registers are available”: Register allocation tracking is a programmer's or assembler's convenience but not the defining capability highlighted; the key is that code explicitly states B and D. Multiple programs resident: That is a memory management/OS feature (multiprogramming), not assembler language capability. None of the above: Incorrect; option D is correct. Common Pitfalls: Conflating assembler features with OS facilities (e.g., multiprogramming) leads to incorrect associations. Keep the scope to source-level operand specification. Final Answer: It allows the programmer to write base registers and displacements explicitly in the source program.

Question 3

Compiler construction: during analysis of a PL/I program, lexical analysis refers to which specific activity in the front-end pipeline?

Accepted Answer

Introduction / Context: Compilers typically perform a front-end pipeline: lexical analysis (scanning), parsing (syntax analysis), and semantic analysis, followed by intermediate representation and code generation/optimization. This question focuses on the first step—lexical analysis—and asks you to identify its primary purpose. Given Data / Assumptions: Source language is PL/I, but the general principles apply to most languages. We are distinguishing scanning from parsing and later phases. Macro processing and code optimization are separate concerns. Concept / Approach: Lexical analysis converts a raw character stream into a sequence of tokens (uniform symbols) such as identifiers, keywords, literals, operators, and punctuation. This token stream is then consumed by the parser. The scanner also performs tasks like skipping whitespace/comments and possibly normalizing numeric literals or case, depending on language rules. Step-by-Step Solution: 1) Start with a character sequence from the source file.2) Group characters into meaningful units (tokens) using regular patterns (e.g., identifier = letter (letter|digit)*).3) Emit a stream of uniform symbols (token kind + lexeme/attributes) for the parser.4) Leave syntactic structure (grammar productions and reductions) to the parser, not the lexer. Verification / Alternative check: Standard compiler texts define lexical analysis (scanning) as tokenization. Tools like lex/flex embody this by generating scanners that recognize token patterns and return uniform symbols to the parser (yacc/bison). Why Other Options Are Wrong: Syntactic reductions: That is parsing (syntax analysis), not scanning. “Optional matrix”: Not a standard compiler term in this context. Macro processor: Preprocessing or macro expansion is separate and not lexical analysis. None of the above: Incorrect because token recognition and uniform symbol creation is exactly lexical analysis. Common Pitfalls: Blurring the boundary between lexing and parsing can cause design bugs; keep tokenization concerns distinct from grammar recognition and semantic checks. Final Answer: recognition of basic elements and creation of uniform symbols.

Question 4

Addressing modes: in which mode is the effective address of an operand obtained by adding a constant (displacement) to the contents of a register?

Accepted Answer

Introduction / Context: Instruction sets provide multiple addressing modes to balance code density, speed, and flexibility. Understanding how an effective address (EA) is computed helps in both assembly programming and compiler back-end design. This question targets the classic pattern “EA = register + constant.” Given Data / Assumptions: The CPU supports addressing modes with registers and displacements. The constant is part of the instruction (displacement or offset). The register holds a base or index value. Concept / Approach: Index (or base+displacement) addressing computes EA by adding a register value to an immediate displacement. Assemblers often notate this as D(R) or [R + D]. This contrasts with immediate mode (operand is in the instruction itself), absolute mode (EA is a fixed address), and indirect mode (instruction points to a memory cell that holds the EA). Step-by-Step Solution: 1) Identify form: EA must equal register value plus a constant displacement.2) Recognize this as the hallmark of index/base+displacement addressing.3) Exclude other modes: immediate (no memory EA), absolute (no register addition), indirect (adds a memory fetch level instead).4) Conclude the mode is index mode. Verification / Alternative check: Architectures like x86 (disp + base + index*scale) and IBM/370 (D(B)) show EA construction explicitly using register contents plus displacement, validating the answer. Why Other Options Are Wrong: Absolute: Uses a fixed address field; no register addition. Indirect: Uses a pointer in memory; EA is fetched, not formed by register + constant. Immediate: Operand value is encoded directly; no EA calculation. None of the above: Incorrect because index mode matches exactly. Common Pitfalls: Confusing base+displacement with indirect addressing; the former computes an EA arithmetically, the latter dereferences a memory location to obtain the EA. Final Answer: index mode.

Question 5

Operating systems and hardware evolution: what made multiprogramming (concurrent residence and progress of multiple jobs) practically possible on mainstream systems?

Accepted Answer

Introduction / Context: Multiprogramming—keeping multiple programs in memory and allowing them to make progress seemingly at once—was a landmark capability in computing. It relied on both hardware advancements (I/O subsystems) and software sophistication (operating systems). This question asks you to identify the necessary enablers. Given Data / Assumptions: “Multiprogramming” refers to overlapping CPU and I/O among several jobs. Hardware supports asynchronous I/O operations decoupled from CPU execution. An OS exists to schedule and control these activities. Concept / Approach: To realize multiprogramming, two pillars were required: (1) I/O devices and controllers capable of operating in parallel with the CPU (e.g., DMA, channels), so the CPU need not busy-wait; and (2) an operating system to manage memory, schedule jobs, handle interrupts, and coordinate context switches. Without either, true multiprogramming would stall or be unmanageable. Step-by-Step Solution: 1) Identify hardware need: independent I/O so CPU can compute while devices transfer data.2) Identify software need: OS to manage ready/blocked states, interrupts, and resource allocation.3) Conclude that both hardware capability and OS software are required. Verification / Alternative check: Historical systems (e.g., IBM 7090 → 360 series) introduced channel I/O and sophisticated OSes (e.g., MVT/MVS), demonstrating that only with both elements could multiprogramming flourish, improving utilization and throughput. Why Other Options Are Wrong: Only I/O hardware: Without OS control, concurrency degenerates into chaos. Only OS: Without independent I/O, CPU remains a bottleneck waiting for devices. Neither: Contradicted by practice and theory. None of the above: Incorrect because both are necessary. Common Pitfalls: Confusing multiprogramming with multiprocessing (multiple CPUs). Multiprogramming can occur on a single CPU by overlapping CPU and I/O, but it requires both I/O autonomy and OS scheduling. Final Answer: both (a) and (b).

Question 6

Program relocation concepts: which statement best defines a self-relocating program with respect to address-sensitive code and execution location?

Accepted Answer

Introduction / Context: Relocation is the process of adjusting address-sensitive code and data so that a program can execute correctly no matter where it is loaded in memory. Loaders, linkers, and sometimes programs themselves participate in relocation. This question distinguishes a self-relocating program from other relocation scenarios. Given Data / Assumptions: We are considering executable images that may be placed at varying memory addresses at load time. Address-sensitive portions include absolute addresses and pointer-like references embedded in the code/data. Relocation can be performed by external tools or by the program itself. Concept / Approach: A self-relocating program contains logic to adjust its own address-sensitive references when it starts (or as it loads). It computes the load-time delta and patches internal tables or code/data locations accordingly. This contrasts with non-relocatable programs (must reside at a fixed address) and relocatable programs that rely on an external relocating loader with relocation information. Step-by-Step Solution: 1) Identify the essence of “self-relocating”: relocation performed by the program itself.2) Exclude fixed-location programs, which cannot relocate at all.3) Exclude programs that merely carry relocation info but depend on an external loader.4) Conclude: the correct description is that the program can itself relocate its address-sensitive parts. Verification / Alternative check: Bootstrapping code (e.g., certain loaders or resident monitors) historically demonstrated self-relocation: upon start, they compute the current load base, add offsets to pointers, and continue execution correctly regardless of placement. Why Other Options Are Wrong: Cannot execute elsewhere: This defines non-relocatable code, the opposite of self-relocating. Program plus relocation info: That describes relocatable objects processed by a relocating loader, not self-relocation. All of the above: Mutually inconsistent statements; only one is correct. None of the above: Incorrect because self-relocation (option C) is correct. Common Pitfalls: Confusing “relocatable” (has info for an external loader) with “self-relocating” (performs its own relocation). The presence of relocation entries does not imply the program will patch itself at runtime. Final Answer: can itself perform the relocation of its address-sensitive portions.

Question 7

Advantages of assembly language over pure machine language: identify the most accurate summary of benefits to a programmer.

Accepted Answer

Introduction / Context: Assembly language sits one level above machine code, providing human-friendly mnemonics and symbolic features while still mapping closely to hardware instructions. Understanding why assembly is superior to raw opcodes clarifies why assemblers remain useful for embedded systems, boot code, and performance-critical routines. Given Data / Assumptions: Comparison with pure machine language (numeric opcodes and absolute addresses). Traditional assembler features: mnemonics, labels, directives, macros. Target context: general microprocessors and microcontrollers. Concept / Approach: Assembly introduces symbolic mnemonics (e.g., MOV, ADD) instead of numerical opcodes, labels for addresses, and directives to define constants, reserve storage, and include data. These features reduce cognitive load, cut errors, and improve maintainability without sacrificing control over hardware. Step-by-Step Solution: Readability: mnemonics and labels make intent clear (e.g., LOOP_START vs. address 0x1F3A).Symbolic addressing: the assembler resolves labels to absolute addresses, easing relocation and code changes.Data handling: directives (DB, DW, EQU, ORG) and pseudo-ops streamline embedding constants, tables, and buffers.Therefore, all listed benefits apply simultaneously. Verification / Alternative check: Practical development flows show fewer errors and faster iteration in assembly compared with entering hex opcodes by hand. Listing files and symbol maps from assemblers demonstrate automatic address resolution. Why Other Options Are Wrong: Each single item (a), (b), or (c) is true, but they are incomplete individually.None of the above: incorrect because all items are true and collectively summarize assembly’s advantages. Common Pitfalls: Assuming assembly is as hard to maintain as machine code; overlooking that assemblers provide macros, conditional assembly, and structured comments that significantly aid development. Final Answer: All of the above

Question 8

In a compiler's storage assignment phase (also called memory allocation within the compiler back end), which responsibilities are included? Select all that apply to a typical language implementation: assigning addresses to user variables, reserving …

Accepted Answer

Introduction / Context: Storage assignment in a compiler (sometimes called memory layout or allocation) maps program objects to specific locations. This includes source-level variables, compiler-generated temporaries, and literal constants that must exist at runtime. Understanding this phase clarifies how compiled code accesses data efficiently and safely. Given Data / Assumptions: A conventional compiled language (for example, PL/I, C, or similar). Targets that use stack, static/global areas, and possibly a heap managed by runtime. Literals (such as string or numeric constants) may require read-only or static storage with initialization. Concept / Approach: The compiler back end assigns addresses or offsets. It lays out activation records for procedures, creates slots for temporaries produced during expression evaluation, and emits data segments for constants. It ensures alignment, size, and lifetime rules are respected (static vs. automatic), often guided by calling conventions and ABI requirements. Step-by-Step Solution: Identify user variables: allocate stack offsets for locals and static addresses for globals.Introduce temporaries: create transient locations to hold intermediate values during code generation.Handle literals: place them in a data or read-only section and emit initial bytes so they are available at program start. Verification / Alternative check: Inspect generated assembly: look for symbol table entries, .data/.rodata segments for literals, and stack frame (prologue/epilogue) indicating local and temporary allocations. Why Other Options Are Wrong: Each individual option (a), (b), and (c) describes a genuine storage assignment task; hence selecting only one is incomplete.“None of the above” is incorrect because all listed responsibilities apply. Common Pitfalls: Confusing runtime heap allocation (done by allocators at execution time) with compile-time storage assignment; overlooking that literals also require addresses and initial contents. Final Answer: All of the above.

Question 9

In the compilation of a PL/I program, the term “machine-independent optimization” refers to optimizations applied on an intermediate representation (IR) before code is tailored to a specific CPU. Which choice captures this idea most closely?

Accepted Answer

Introduction / Context: Modern compilers typically divide optimization into two broad classes: machine-independent and machine-dependent. Machine-independent optimization operates on an intermediate representation (IR) and is agnostic of specific instruction sets, pipelines, or microarchitectural details. This question focuses on recognizing that distinction in the PL/I compilation pipeline. Given Data / Assumptions: PL/I or a similar high-level language. Standard multi-phase compiler: lexical analysis, parsing, IR generation, optimization, and code generation. “Matrix” refers to an IR form (three-address code, quadruples, or similar). Concept / Approach: Machine-independent optimizations include constant folding, common subexpression elimination, dead code elimination, copy propagation, loop-invariant code motion, and strength reduction performed on IR. They improve efficiency regardless of the final hardware, whereas machine-dependent steps tune instruction selection, scheduling, and register allocation to a particular target. Step-by-Step Solution: Separate concerns: front-end builds a correct IR; optimizer refines it in a target-neutral way.Identify examples: remove redundant calculations, fold constants, and hoist invariants in loops.Result: a “more optimal matrix/IR” ready for target-specific code generation. Verification / Alternative check: Compare outputs with and without optimization flags at the IR level; improvements are visible even before register allocation or instruction selection occur. Why Other Options Are Wrong: (a) Parsing reductions are part of syntax analysis, not optimization.(b) Lexical analysis creates tokens/uniform symbols; not optimization.(d) Macro processing is a separate preprocessing technique and is not the core of machine-independent optimization.(e) Incorrect because (c) correctly states the concept. Common Pitfalls: Conflating macro processing or parsing with optimization; assuming optimization must be tied to a specific CPU rather than performed generically on IR. Final Answer: creation of more optimal intermediate code (matrix) independent of the target machine.

Question 10

Macro processing essentials: which tasks must a macro processor perform during assembly or compilation?

Accepted Answer

Introduction / Context: Macro processors extend an assembler or compiler by allowing parameterized code templates (macros). They reduce repetition, encode patterns, and improve maintainability. Understanding their essential duties clarifies how macro expansion integrates into the translation flow. Given Data / Assumptions: The source includes macro definitions and macro invocations. The macro processor runs before or as part of translation. Arguments in calls replace formal parameters in definitions. Concept / Approach: A proper macro system must parse and record macro definitions, differentiate normal statements from macro calls, and perform argument substitution to yield expanded, concrete source lines that downstream phases can assemble/compile normally. Step-by-Step Solution: Recognize: scan input to detect macro-definition boundaries and macro call sites.Store: keep definitions in a macro definition table (MDT) and maintain a macro name table (MNT) for lookups.Expand: on encountering a call, create the appropriate expansion with actual parameters substituted into the macro body. Verification / Alternative check: Preprocessed output (listing) shows calls replaced by expanded code identical to hand-written code, demonstrating correct recognition, storage, and expansion. Why Other Options Are Wrong: Each single task (a), (b), or (c) alone is insufficient; a functioning macro processor must do all.“None of the above” is incorrect because all listed tasks are indeed required. Common Pitfalls: Confusing macro expansion with inline functions or templates at compile time; forgetting argument substitution rules, default parameters, or nesting behavior. Final Answer: All of the above.

Question 11

System programs: what do we call the program that combines separately compiled modules (objects) and prepares them for execution by resolving external references and arranging them in memory?

Accepted Answer

Introduction / Context: Large software systems are built from multiple object modules. Before execution, these modules must be combined, external symbols resolved, and final addresses assigned. The system program that performs this step bridges the gap between separate compilation and a runnable image. Given Data / Assumptions: Multiple object files produced by independent compilations. External references (functions/variables) across modules. Target environment expecting a single loadable/executable image. Concept / Approach: A linking loader (or linker/loader combination) resolves external symbols, performs relocation as needed, and arranges code/data into the final memory image. An assembler translates assembly to object code but does not combine multiple modules. A cross compiler produces code for a different architecture. “Load and go” refers to immediate assembly-to-load workflows without a separate link step across many objects. Step-by-Step Solution: Collect object modules and libraries.Resolve undefined symbols using symbol tables.Relocate addresses according to placement decisions.Produce a loadable image for execution. Verification / Alternative check: Toolchains (e.g., ld, link.exe) demonstrate this process: invoking the linker merges objects and emits an executable that the loader places in memory at run/start time. Why Other Options Are Wrong: Assembler: translates source to object, not multi-module linking.Cross compiler: changes target architecture, not linking modules.Load and go: a style of assembler/loader integration, not the general multi-module linker role. Common Pitfalls: Equating loading (placing into memory) with linking (resolving symbols); many systems combine them, but the roles remain distinct. Final Answer: linking loader.

Question 12

Absolute loading scheme: which traditional loader function is instead handled by the assembler (i.e., performed at assembly time rather than by the loader)?

Accepted Answer

Introduction / Context: Different loading schemes distribute responsibilities among assembler, linker, and loader. In an absolute loading scheme, the assembler emits code with fixed absolute addresses, changing the usual division of labor for relocation. Given Data / Assumptions: Absolute loader: places the program into memory without adjusting addresses. Assembler knows target starting addresses via origin directives or fixed layout. No late binding of external symbols or relocation at load time. Concept / Approach: Relocation is the process of adjusting address-sensitive instructions and data when the final load address is determined. In an absolute scheme, the assembler precomputes and fixes addresses; hence the loader does not relocate. The loader simply copies the image to memory and transfers control. Step-by-Step Solution: Recognize absolute output: object code already contains final addresses.Map loader duties: minimal—read into memory and start execution.Conclude: relocation duty shifts to the assembler phase. Verification / Alternative check: Examine object format: absence of relocation records indicates assembler-fixed addresses; the loader has no relocation patches to apply. Why Other Options Are Wrong: Allocation at load time: not characteristic of absolute loaders; addresses are predetermined.Linking: absolute scheme often assumes a single module or prelinked image.Loading: still a loader task—reading image into memory and starting execution.None of the above: incorrect since relocation is indeed done by the assembler here. Common Pitfalls: Confusing absolute with relocatable or dynamic loading; assuming all loaders must relocate regardless of scheme. Final Answer: Relocation of address-sensitive parts.

Question 13

Relocatable program forms: which description best characterizes a relocatable program?

Accepted Answer

Introduction / Context: Object modules frequently need to be placed at different memory addresses at load time. To support this flexibility, a relocatable program includes metadata that enables a loader to adjust address-sensitive fields appropriately. Given Data / Assumptions: Standard relocatable object format with relocation records. Loader capable of processing relocation entries. No requirement that the program begins at a fixed address. Concept / Approach: A relocatable program has symbolic references and marked address fields. The loader, when choosing a load address, applies relocation by adding the chosen base to address-sensitive locations. This differs from absolute programs (fixed addresses) and self-relocating programs (which contain code to relocate themselves at runtime). Step-by-Step Solution: Identify relocation information in the object (e.g., relocation entries, symbol tables).Loader selects a base address at load time.Loader patches all marked fields so the program runs correctly at its new location. Verification / Alternative check: Relocation maps demonstrate consistent adjustment of code and data references by an offset equal to the load base, confirming relocatability. Why Other Options Are Wrong: (a) Describes an absolute (non-relocatable) program.(c) Describes a self-relocating program that performs its own relocation logic.(d) Cannot be true because (a) and (b) are mutually exclusive. Common Pitfalls: Assuming “relocatable” means the program moves itself; typically, the loader performs relocation using supplied metadata. Final Answer: consists of a program plus relocation information so it can be placed at various addresses.

Question 14

In compiler construction terminology, which table is a permanent database that keeps an entry for every terminal symbol of the grammar used by the language front end?

Accepted Answer

Introduction / Context: Language processors maintain several tables to speed up analysis and translation. Distinguishing among terminal, literal, and identifier tables clarifies how lexical and syntactic information is organized for efficient parsing and semantic analysis. Given Data / Assumptions: Grammar-based front end (lexer + parser). Terminals are tokens such as keywords, operators, and punctuation. Literals and identifiers are distinct token classes with their own tables. Concept / Approach: The terminal table (sometimes part of the token specification) enumerates all terminal symbols of the grammar. The literal table stores unique literal constants (numbers, strings). The identifier table records user-defined names and, later, semantic attributes placed in a symbol table. “Reductions” refers to parser actions, not a table. Step-by-Step Solution: Identify role of terminals: fixed set of tokens known at compiler build time.Associate each terminal with token codes and attributes (e.g., precedence).Keep literal and identifier information in their respective tables, separate from terminals. Verification / Alternative check: Inspect parser generators (e.g., yacc/bison) where token definitions correspond to a fixed terminal set, distinct from runtime-populated literal/identifier pools. Why Other Options Are Wrong: Literal table: stores constants, not the universe of terminals.Identifier table: stores user symbols, not grammar terminals.Reductions: parser operations, not a database of symbols.None of the above: incorrect because “Terminal table” is correct. Common Pitfalls: Confusing language-defined terminals (finite, fixed) with program-defined identifiers (unbounded, discovered during scanning). Final Answer: Terminal table.

Question 15

Assembler variants: which system program skips writing a separate object file and instead generates absolute machine code directly in memory, loading it into main storage so execution can start immediately after assembly?

Accepted Answer

Introduction / Context: Assembly toolchains vary in how they deliver executable code. Traditional assemblers emit object modules for later linking, while specialized workflows shorten the cycle for rapid testing or educational use by loading code directly into memory for immediate execution. Given Data / Assumptions: Goal: execute the assembled program right away without a separate link/load step. Memory image is written directly to the execution location. Absolute addresses are used or resolved during assembly. Concept / Approach: A load-and-go assembler combines assembly with direct loading. It forgoes producing an object file and emits executable bytes directly into designated memory, then transfers control to the entry point. This accelerates turnaround but sacrifices modular linking flexibility. Step-by-Step Solution: Assemble source → produce absolute code in memory.Perform minimal relocation (if any) during assembly, not at load time.Jump to program start address immediately after assembly completes. Verification / Alternative check: Historical educational assemblers and monitor programs on early microcomputers exemplify load-and-go behavior: assemble, then run—no object file persists. Why Other Options Are Wrong: Two-pass assembler: typically emits an object/module for later linking/loading.Macroprocessor: performs macro expansion, not loading.Compiler: produces object or intermediate files; loading is a separate concern.None of the above: incorrect because load-and-go is the precise term. Common Pitfalls: Assuming all assemblers produce object files; overlooking environments that privilege immediacy over modularity. Final Answer: load-and-go assembler.

Question 16

System startup: when a computer is powered on or restarted, which special absolute loader is executed to initialize hardware, locate the operating system, and start the boot process?

Accepted Answer

Introduction / Context: Right after power-on, a computer cannot rely on an operating system already residing in memory. A minimal program stored in firmware or a predefined location must take control, test hardware, and bring in the operating system. This early-stage program is a specialized, minimal loader. Given Data / Assumptions: Bootstrapping begins from immutable or semi-immutable storage (ROM/flash). The program can access devices to fetch the OS loader or kernel. Absolute addressing is typically used because the loader is built for a fixed location. Concept / Approach: The bootstrap loader initializes essential hardware, identifies a boot device, loads a more capable secondary loader or OS image into RAM, and transfers execution. It acts as a tiny absolute loader, not a general-purpose linker or full dynamic loader. Step-by-Step Solution: Execute firmware-resident boot code immediately on reset.Probe or follow configured boot order to locate a boot sector/loader.Load the operating system or second-stage loader to memory and jump to it. Verification / Alternative check: BIOS/UEFI on PCs, boot ROMs on embedded devices, and bootloaders like U-Boot implement these steps and embody the bootstrap concept. Why Other Options Are Wrong: Loader (generic): too broad; the early-stage specialized loader is called the bootstrap loader.Linker: resolves symbols and creates executables, not used at power-on.None of the above: incorrect because “bootstrap loader” is the standard term.IPL card: a historical medium or mechanism, not the general term for the program itself. Common Pitfalls: Confusing generic loaders with the minimal, firmware-invoked bootstrap stage; assuming the OS is present in RAM at power-on. Final Answer: bootstrap loader.

Question 17

Compiler design — lexical analysis phase: Which tasks are performed during lexical analysis (also called scanning) before syntax analysis begins?

Accepted Answer

Introduction / Context: In compiler design, the lexical analysis (scanner) phase is the front-door of the compilation pipeline. It transforms raw source code characters into a structured stream of tokens and prepares auxiliary tables that later phases use. This question tests recognition of the standard responsibilities of lexical analysis. Given Data / Assumptions: A conventional multi-phase compiler pipeline is assumed. Lexical analysis precedes syntax (parsing) and semantic analysis. Standard artifacts such as token streams, literal tables, identifier tables, and uniform symbol tables are used. Concept / Approach: Lexical analysis groups characters into lexemes and maps them to tokens (keywords, identifiers, literals, operators). Alongside tokenization, it typically records encountered identifiers and constants in tables, assigns token codes, and produces a uniform symbol representation consumed by later stages. Step-by-Step Solution: Recognize lexemes and emit tokens for the parser.Record identifiers (names) and literals (constants) into dedicated tables with attributes.Produce a uniform symbol table or token stream with references into those tables to standardize later processing.Therefore, all listed tasks (tokenization, tables, uniform symbols) belong to lexical analysis. Verification / Alternative check: Most textbooks separate scanning (lexical) from parsing (syntax). Anything involving grammar productions is parser work; anything involving raw character grouping is scanner work. Why Other Options Are Wrong: (e) Target code generation is a back-end activity, far beyond lexical analysis. Common Pitfalls: Confusing parsing with scanning, or assuming code generation happens during tokenization. Also, some projects split table-building across phases; nevertheless, establishing identifiers/literals at scan time is standard. Final Answer: All of the above.

Question 18

Programming fundamentals: A sequence of instructions written in a computer language to achieve a desired result is called what?

Accepted Answer

Introduction / Context: Precise terminology matters in software engineering. We distinguish between abstract problem-solving steps and their concrete expression in a programming language. This question tests recognition of the term used when the instructions are explicitly “in a computer language.” Given Data / Assumptions: The instructions are explicitly written in a computer language (for example, C, Java, Python). The goal is to achieve a particular result by executing these instructions. Concept / Approach: An algorithm is a language-independent, finite sequence of steps. When that algorithm is translated into a specific programming language and can be executed by a computer, the artifact is a program. Decision tables and flowcharts are specification tools, not executable artifacts by themselves. Step-by-Step Solution: Identify the key phrase: “in a computer language.”Match to terminology: executable description → program.Eliminate alternatives: algorithm (language-neutral), decision table/flowchart (design aids). Verification / Alternative check: Compilers and interpreters accept programs (source code) as input, not raw algorithms or diagrams. Why Other Options Are Wrong: (a) An algorithm is not tied to a specific programming language. (b) Decision tables structure logic but are not executable code. (d) “All of the above” is incorrect because only one fits the stated condition. (e) Flowcharts diagram control flow but are not code. Common Pitfalls: Equating algorithm and program; forgetting that “in a computer language” implies code ready for compilation or interpretation. Final Answer: Program.

Question 19

Assembly to machine code (assumed format): Convert the instruction “CHARI h#000F, s” into its hexadecimal machine-language form (use the standard opcode+immediate format where applicable).

Accepted Answer

Introduction / Context: Translating assembly mnemonics into machine code requires knowing the target instruction set architecture (ISA), including opcode values and operand encodings. In many accumulator or stack-oriented ISAs, immediate-addressing instructions place the opcode byte(s) first, followed by the immediate operand in hexadecimal. Given Data / Assumptions: Instruction: CHARI h#000F, s (character or data immediate to a stack or status target). We assume a conventional layout: opcode byte(s) followed by a 16-bit immediate operand. Little further ISA context is provided; we apply a recovery-first, minimal-assumption mapping. Concept / Approach: Look for an option whose hex form plausibly encodes an immediate operand of 000F, since the assembly explicitly shows h#000F. Among the options, only those containing “000F” are structurally consistent with an immediate operand carrying the value 0x000F. A typical encoding is “OP IMM16”. Step-by-Step Solution: Identify the immediate value: 0x000F.Scan choices for immediate presence: only “DA000F” (and not others) embeds 000F directly following a likely opcode byte DA.Select DA000F as the plausible opcode+operand sequence. Verification / Alternative check: With an ISA reference, one would verify opcode DA corresponds to CHARI with an immediate to the selected destination. In the absence of that manual, choosing the encoding that preserves the explicit immediate value is the most defensible recovery. Why Other Options Are Wrong: (a), (b) do not reflect the immediate 000F; (d) is a single byte and cannot carry a 16-bit immediate; (e) “D0000F” would imply a different opcode and is not supported by the stated mnemonic. Common Pitfalls: Ignoring operand width or selecting a code without the required immediate field. Final Answer: DA000F.

Question 20

Operating systems — process manager responsibilities: What must the Process Manager keep track of for each executing program?

Accepted Answer

Introduction / Context: The process manager (part of an operating system kernel) handles process creation, scheduling, and termination. It must maintain essential metadata to make correct dispatching and resource-allocation decisions. Given Data / Assumptions: Conventional OS with a scheduler and per-process control blocks. Each program runs as a process or thread with attributes. We focus on core tracking responsibilities, not developer tooling. Concept / Approach: Key items maintained include process state (new, ready, running, waiting, terminated), CPU registers, program counter, memory maps, and scheduling parameters such as priority. These are stored in data structures like the process control block (PCB) or task control block (TCB). Step-by-Step Solution: Identify necessary scheduling data: priority is required to choose which process runs next.Identify necessary state data: status allows the scheduler to know whether a process can run.Conclude that both status and priority are core responsibilities. Verification / Alternative check: Standard OS texts list PCB contents; status and priority are universally present, while documentation support is not part of the process manager. Why Other Options Are Wrong: (c) Information management support is tooling, not kernel-level process tracking. (e) Device address catalogs belong to I/O subsystems and hardware abstraction layers, not strictly to per-process tracking. Common Pitfalls: Confusing OS developer utilities with kernel responsibilities; assuming memory maps alone suffice without state/priority. Final Answer: both (a) and (b).

Language Processors Questions