1.1.3 - RAM, ROM and virtual storage
A program needs working memory while it runs, instructions available when the machine starts, and somewhere to keep saved files. You will distinguish the roles of RAM and ROM, then follow a file stored remotely through a familiar local-looking drive. That also explains why virtual storage does not mean extra processor working memory.
RAM as working memory
RAM, random-access memory, holds instructions and data currently being used by a computer. Ordinary system RAM is volatile: its contents are lost when power is removed. The processor can read and write it while a program runs. “Random access” means locations can be addressed directly without working through preceding locations; it does not mean that the computer chooses addresses randomly.
When a user opens an editor, instructions are loaded from secondary storage into RAM and working data, such as the current document and program variables, are held there. Typing changes the working document. Saving writes a persistent copy to secondary storage. RAM holding the changed text is not evidence that the file has been saved. If power fails before saving, the volatile working changes may be lost even though an earlier saved file remains.
More RAM can allow a larger working set or more applications to remain in memory. It does not by itself make the CPU execute instructions at a higher clock rate, and it is not the capacity available for keeping saved photographs indefinitely. Improving performance depends on the bottleneck: adding RAM is useful when insufficient working memory is the problem.
RAM also has a role in an embedded controller. A door controller can keep the latest sensor reading and current “open/closed” state in RAM while its program runs. Those changing values need to be writable. If the controller must retain a configuration after a power cut, it requires a nonvolatile place for that configuration rather than relying only on RAM.
ROM and persistent startup instructions
ROM, read-only memory, is nonvolatile memory used for instructions or data that should remain available without power and should not change during ordinary operation. In the traditional model its contents are read rather than freely rewritten by a running application. RAM and ROM are distinguished by volatility and normal writing behaviour, not by claiming that only RAM permits direct access to locations.
Firmware is software stored in nonvolatile memory that controls or starts a device. Startup instructions must be available before the operating system has been loaded from secondary storage. Keeping them in ROM provides that starting point after the computer has been switched off. The instructions can initialise hardware and begin the process of loading other software into RAM.
The word ROM is often used for this persistent firmware role. Some implementations use electrically rewritable nonvolatile memory, such as flash, so controlled firmware updates are possible. That does not turn the firmware store into ordinary writable working RAM. Distinguish a protected update procedure from the rapid repeated changes to program variables while the device operates.
For a simple irrigation controller, the control program may be held in ROM and read each time the controller starts. RAM holds the latest moisture reading, timing counters and current decisions. Losing those RAM values on power-off differs from losing the whole control program. A configurable schedule that must survive shutdown also needs nonvolatile storage; being “data” does not automatically mean it belongs only in RAM.
Virtual storage that appears local
Virtual storage, in this specification's network-storage sense, appears to the user as local storage although the data is physically stored elsewhere on a network or remotely. For example, a school maps a server folder to a drive letter. A student opens and saves files through familiar file operations without selecting the server's physical disk directly.
On a save, the client sends the file data across the network and a remote system stores it. On an open, the remote system returns the required data. The software presents a logical view of that storage, hiding its physical location. The data must still be stored on real hardware somewhere; “virtual” does not mean that no device is used. The same idea can apply to storage reached through an internet connection.
The separation is useful. Several authorised users can access a shared collection; a student may reach the same files from different computers; and an administrator can manage capacity, permissions and backups centrally. A school can expand server capacity without fitting a larger local disk in every client. These are possibilities of the arrangement, not automatic guarantees that every service backs up correctly or grants everyone access.
The network adds dependencies. Opening a large file can be limited by network bandwidth and delay. If the connection or remote service fails, a file held only remotely may be unavailable. An explicitly synchronised local copy or cache might permit some offline use, but merely displaying a drive icon does not prove such a copy exists. Access also depends on authentication and permissions, and storage managed by another organisation raises control and confidentiality considerations.
A photographer working in a place with an unreliable connection may keep current photographs locally and copy them to remote storage when connected. A team with reliable network access may favour remote shared storage to keep one centrally managed collection. The choice follows the access requirement and failure conditions.
This is distinct from virtual memory, an operating-system memory-management technique using secondary storage to support a working address space when pages are not all in RAM. Virtual storage concerns where files are held and how they are presented; virtual memory concerns the running program's working memory. A larger mapped network drive does not automatically let the processor use it as additional RAM.