FIT1047 Chap.7 Memory, Input/Output, Boot and Operating Systems
Memory, Input/Output, Boot and Operating Systems
Computer systems organise storage into a hierarchy of registers, caches, main memory and persistent storage, trading proximity and speed against capacity, cost and persistence. Locality explains why caching can hide slower levels, while hits, misses, write policies and victim state explain actual transitions.
The chapter then connects asynchronous devices through controllers, polling, interrupts, direct transfers and buffering. Boot is a chain of trust and availability from processor reset through firmware, loader and operating-system kernel. The OS provides protected abstractions—processes, virtual address spaces, files and device interfaces—while scheduling CPU time and validating privileged services.
Virtual memory separates a process's addresses from physical placement through pages, frames, permissions and page faults. All explanations are original standard canon bounded by published outcomes; no platform-specific sizes, commands or scheduling policy are attributed to FIT1047 without current Moodle evidence.
The common reasoning pattern is a state transition with ownership: identify the current layer, the requested resource, the event or check, the state change and the responsible component. Cache misses, interrupts, blocked processes, boot hand-offs and page faults are not interchangeable delays.
The available A2 evidence names explanation of program, process and memory concepts as purpose only; it does not support claims about the Demonstration's exact questions, platform, timings, rubric or materials.
What this chapter covers
- 01
Memory hierarchy and locality
- 02
Cache hits, misses and write policies
- 03
Main memory versus persistent storage
- 04
Controllers, polling, interrupts and buffers
- 05
Firmware, loader and operating-system boot
- 06
Kernel/user authority and system calls
- 07
Processes, threads and scheduling states
- 08
Virtual pages, physical frames and faults
- 09
Event ownership across system transitions
- 10
Completion, readiness and dispatch as separate states
- 11
Validation before virtual-memory residency checks
AskSia-authored practice weighting (not an official mark scheme): Fresh page-fault and process-state trace
- validateValidate mapping and read permission before treating the event as a recoverable non-resident page.
- stateBlock the process while the OS selects a frame and initiates page input.
- loadPreserve a dirty victim if required, load the requested page and update page-table/translation state.
- resumeOn completion, move the process to ready; scheduling later returns it to running.
- checkRetry the original virtual address and verify its unchanged offset reaches the new frame.
Key terms
- Temporal locality
- The tendency to reuse recently accessed information.
- Spatial locality
- The tendency to access addresses near a recent access.
- Interrupt
- An event that redirects control to privileged handling while preserving resumable context.
- Process
- A protected, scheduled execution context with state and resources.
- Virtual address
- An address in a process view translated through mappings and permissions.
- Page fault
- A controlled event raised when a virtual-memory access needs OS handling, including valid non-resident cases.
- Ready versus running
- A ready process is eligible for CPU time but is not currently executing. Completion of an awaited event can move a process from blocked to ready, while a separate scheduling and dispatch decision determines when it becomes running.
- Virtual-memory validation
- The ordered checks that determine whether a virtual access is mapped, permitted and resident. A valid permitted but nonresident page can trigger retrieval; an invalid or forbidden access is not repaired merely by loading storage contents.
Memory, Input/Output, Boot and Operating Systems FAQ
What is the difference between memory and storage?
Main memory holds actively addressed state and is typically volatile; persistent storage retains files/system data. Use exact level names rather than one ambiguous word.
Is a blocked process just waiting for CPU?
No. A blocked process cannot progress until an event such as I/O completion. A ready process can run but awaits scheduling.
What happens during an interrupt?
The system preserves required context, enters a handler with appropriate authority, services/records the event and restores or schedules work under policy.
Why is a page fault not always an error?
A valid permitted page may simply be non-resident. The OS can load it, update mapping state and retry. Invalid or forbidden accesses are different failures.
Does a successful boot prove the system is secure?
No. Boot shows enough stages worked to start; trust depends on verification, key/policy integrity and later system security. Diagnose the last successful stage.
Why is an interrupt not the same as immediate process execution?
An interrupt transfers control so the operating system can identify and handle an event. Handling may acknowledge a device, move data or make a blocked process ready. The scheduler still decides when an eligible process runs.
Which assessment claims are supported for these system concepts?
Only the published A2 purpose of explaining program, process and memory concepts is used. Exact Demonstration questions, platform behaviour, scheduling policy, trace format, marks and permitted resources remain unknown here and belong to current Moodle guidance.
Assessment move
Draw storage levels with capacity, persistence and transition arrows, then trace one access as hit or miss under stated starting state. For cache drills, include victim valid/dirty state and distinguish write-through from write-back. Build an I/O timeline showing producer, controller, buffer, interrupt and process state. Reconstruct boot as hand-offs with expected input, validation and next entry point.
For OS work, pair program-visible abstraction with implementing resource and protection mechanism. Practise process state tables with two processes so I/O completion, ready state and dispatch remain distinct. For virtual memory, split virtual page/offset, check validity/permission, map to frame, preserve the offset and retry. Do not invent platform-specific numerical policies.
Add a reference-sequence exercise with a declared empty cache, block membership and repeated accesses; predict spatial and temporal hits and record every eviction. Compare a clean and dirty write-back victim while keeping the request constant. For I/O, draw both data transfer and completion notification because the device/controller can move bytes before interrupt handling makes a process ready.
For boot, write the last trusted stage and distinguish discovery, verification, loading and transfer-of-control failures. For system calls, mark untrusted user arguments, validation and privileged resource ownership; follow both success and error cleanup.
In a two-process schedule, ensure only one process is running on one processor, blocked work awaits its event, and completion changes eligibility rather than guaranteeing dispatch. For a page fault, check mapping/permission before residency and invalidate stale cached translations after a mapping change. This sequence links performance, protection and state instead of memorising OS vocabulary.
Use the course-developed text for topic scope and standard terminology, then redraw all hierarchies, state diagrams and access traces in original form. Do not copy its paragraphs, figures, tables or worked scenarios. Recheck current Moodle for A2 instructions rather than converting this standard-canon workflow into a predicted assessment template.
Working through Memory, Input/Output, Boot and Operating Systems in FIT1047? Sia is AskSia’s AI Computer Science tutor — ask any FIT1047 Memory, Input/Output, Boot and Operating Systems question and get a clear, step-by-step explanation grounded in how FIT1047 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
