YOUR REVISION ROUTE
Read the summaries, then close your notes and explain each idea in your own words. Use the flashcards to identify uncertain points and build a lesson-linked revision list.
4.1 | TYPES OF SOFTWARE AND INTERRUPTS
System software supports the computer’s operation; application software performs tasks required by users. Startup code brings the OS into operation, and interrupts allow appropriate responses to events.
4.1.1 | SYSTEM AND APPLICATION SOFTWARE
| Category | Purpose | Examples |
|---|---|---|
| System software | Provide services required by the computer | Operating system; backup and anti-malware utilities |
| Application software | Provide services required by the user | Word processor; spreadsheet; browser; CAD |
A word processor creates a report. The OS manages resources and supplies file services. The saved report is data; the keyboard is hardware.
Utilities maintain, manage or protect the system. A downloaded backup utility is still system software in this course; a preinstalled browser is still an application.
4.1.2 | ALL NINE OS FUNCTIONS
| Function | What it does |
|---|---|
| Files | Organise files and support save, copy, move and delete |
| Interrupts | Arrange suitable responses to attention requests |
| Interface | Provide interaction through visual controls or commands |
| Peripherals and drivers | Coordinate device communication |
| Memory | Allocate, track, protect and reclaim working memory |
| Multitasking | Schedule processor time between tasks |
| Application platform | Provide services for compatible programs |
| System security | Check identity and enforce access rules |
| User accounts | Maintain users, settings and access rights |
On a single core, rapid switching allows several tasks to make progress over time. Multiple cores can allow parallel execution. A driver is software, not the physical peripheral.
Authentication checks identity; authorisation concerns permitted access. A successful login does not automatically give administrator rights.
Virtual memory uses secondary storage as backing space. It does not create physical RAM and frequent page transfers can reduce performance.
4.1.3 | FIRMWARE AND BOOTLOADER
Firmware is software closely associated with hardware control and retained in non-volatile memory. Some firmware can be updated; non-volatile does not mean permanently unchangeable.
A bootloader loads an OS, or starts the next loading stage, and transfers control. In the syllabus’s simplified model, it is described as firmware running on hardware.
| Startup stage | Role |
|---|---|
| Initial firmware | Prepare the hardware and start the boot process |
| Bootloader | Load required OS code and hand over control |
| Operating system | Manage resources and start required services |
| Application | Use OS services to perform a user task |
The CPU executes instructions at all these stages. A typical computer retains OS and application files on secondary storage and loads needed code into memory. It does not keep the whole OS permanently in ordinary RAM.
4.1.4 | INTERRUPTS
An interrupt requests processor attention. An interrupt service routine (ISR) contains the instructions used to handle the event.
| Source | Syllabus examples |
|---|---|
| Hardware | Keyboard key press; mouse movement |
| Software / exceptional execution event | Division by zero; conflicting or invalid access to a memory location |
Normal handling: recognise and check the request → save relevant execution state → run the appropriate ISR → restore state → resume when appropriate.
State includes information such as register values and a return position. Saving it preserves what the task needs; it is not a document backup. Error events can instead lead to an error response or termination.
Priority and system rules affect when requests are handled. Interrupts can avoid repeated polling of idle devices, but handling takes processor time.
4.2 | LANGUAGES, TRANSLATORS AND IDEs
Language level changes how much processor detail the programmer manages. Translators connect source code to execution. IDE tools support development, but testing remains essential.
4.2.1 | HIGH AND LOW LEVEL LANGUAGES
| Comparison | High-level | Low-level |
|---|---|---|
| Read and write | Generally easier; abstractions express tasks | More processor-specific detail |
| Debug | Generally easier to relate source to intention | Often trace registers and addresses |
| Machine independence | Source often portable with suitable support | Closely tied to the instruction set |
| Hardware control | More abstraction | Close control of instructions and resources |
Python and Java are high-level examples. Assembly and machine code are low-level. High-level source still needs a suitable execution system; portable source does not guarantee a portable executable.
Low-level code is not automatically faster. Algorithm, implementation, compiler optimisation and hardware affect performance.
4.2.2 | ASSEMBLY AND MACHINE CODE
Assembly uses mnemonics such as ADD. Machine code encodes instructions the matching CPU can execute. An assembler translates assembly; it does not execute every calculation while translating.
| Teaching instruction | Meaning |
|---|---|
| LOAD 20 | Copy the value at address 20 into ACC |
| ADD 21 | Add the value at address 21 to ACC |
| STORE 22 | Copy ACC to address 22 |
If memory 20 holds 7 and memory 21 holds 5, ACC becomes 7 then 12, and memory 22 receives 12. Address 21 is not the literal number being added.
A mnemonic is the source name; an opcode is the encoded operation field; an operand identifies data or a location according to the format. Both assembly and machine code depend on the target instruction set.
4.2.3–4 | COMPILER AND INTERPRETER
| Point | Compiler model | Interpreter model |
|---|---|---|
| Operation | Translate the whole source before execution | Translate and execute as it goes |
| Output | Executable after successful compilation | No separate standalone executable first in this model |
| Error report | Detected source errors reported before executable runs | Stop at an encountered error |
| Repeat runs | Use unchanged executable without recompiling | Interpreter involved when source runs |
| Changes | Compile again to update executable | Edit and rerun with suitable support |
An interpreted workflow is often useful during development for quick changes and feedback. The syllabus highlights compiling the final program for distribution or repeated execution. These are common uses rather than a rule banning compilation during development.
Syntax errors break language rules. Runtime errors occur during execution. Logic errors produce unintended behaviour even when the code is valid. No translator guarantees every logic error is found.
A compiler may detect an obvious constant division by zero, but a divisor from user input can cause a fault only when the executable runs. The programmer must still validate and test.
4.2.5 | THE SEVEN IDE FEATURES
| Feature | Remember its job |
|---|---|
| Code editor | Enter, edit and save source |
| Run-time environment | Provide execution facilities |
| Translators | Compile, interpret or assemble as appropriate |
| Error diagnostics | Explain detected problems |
| Auto-completion | Suggest or finish entries |
| Auto-correction | Fix or offer fixes for recognised problems |
| Prettyprint | Improve consistent layout |
Completion and correction are different. Prettyprint improves readability, not the algorithm. Diagnostics cannot guarantee correct logic.
Many IDEs also offer breakpoints, stepping and variable inspection. If price = 12 and quantity = 3 but total = 9, inspection can reveal subtraction where multiplication was intended. A successful correction still needs further tests.
COMMON MISTAKES
- Classifying software by whether it is visible or preinstalled.
- Calling the OS a physical processor.
- Confusing a bootloader with the full OS.
- Confusing an interrupt request with its service routine.
- Adding an address as a literal value when the operand selects memory.
- Assuming a compiled executable works on every target.
- Assuming successful translation proves correct logic.
- Confusing auto-completion, auto-correction and prettyprint.
READY TO TEST YOURSELF?
Explain an OS function, describe startup, trace normal interrupt handling, compare translators and justify an IDE feature. Select cards where you cannot yet give a precise answer.