In a general computing sense, overlaying means "replacement of a block of stored instructions or data with another"[1] Overlaying is a programming method that allows programs to be larger than the computer's main memory. An embedded system would normally use overlays because of the limitation of physical memory, which is internal memory for a system-on-chip and the lack of virtual memory facilities.
Contents |
The method assumes dividing a program into self-contained object code blocks called overlays. The size of an overlay is limited according to memory constraints. The place in memory where an overlay is loaded is called an overlay region or destination region. Although the idea is to reuse the same block of main memory, multiple region systems could be defined. The regions can be different sizes. An overlay manager, possibly part of the operating system, will load the required overlay from external memory into its destination region in order to be used. Some linkers provide support for overlays.[2]
Overlay programming requires the program designer to be very aware of the size of each part of the program. This means using programming languages or assemblers that allow the designer or architect control over the size of the program and more importantly, the size of the overlay. This constraint adds many design difficulties that do not exist with virtual memory.
As of 2007[update], most business applications are intended to run on platforms with virtual memory. A developer on such a platform can design a program as if the memory constraint does not exist unless the program's working set exceeds the available physical memory. Most importantly, the architect can focus on the problem being solved without the added design difficulty of forcing the processing into steps constrained by the overlay size. Thus, the designer can use higher-level programming languages that do not allow the programmer much control over size (e.g. Java, C++, Smalltalk).
Still, overlays remain popular in embedded systems because many cannot use virtual memory. Many embedded systems are real-time systems. When a program enters a part that has been paged out, the virtual memory may not respond in time, causing a real-time computing system to miss deadlines. The delay of loading an overlay is more predictable. In addition, paging hardware is not without cost, and in many embedded systems sold in millions of units, the reduction in manufacturing costs from simpler hardware outweighs the extra cost of programmer time. Even on platforms with virtual memory, software components such as codecs may be decoupled to the point where they can be loaded in and out as needed.
In the DOS era, overlays were popular because the operating system and many of the computer systems it ran on lacked virtual memory. Originally, PCs even lacked hard drives, so the only storage available for paging out virtual memory would have been 5-1/4" double-density floppy disk. IBM never sold a hard disk for the original IBM PC model 5150, for example, and the base model PC didn't even have a floppy disk drive and relied on cassette storage and BASIC in ROM. (Few of these diskless model 5150 PCs were actually sold.)
Early PCs also had very little RAM by current standards; while a double sided double density 5ΒΌ" floppy disk held 360K, the RAM in PCs as they came from the factory between 1981 and 1985 was rarely significantly more than that; most of those PCs shipped with 64K, 128K, 256K, or perhaps 384K of system RAM. The original PC had between 16K and 64K depending on configuration. If one chose to add RAM to one's system, conventional RAM maxed out at 640K. Adding more memory beyond the 640K of "conventional memory" required resorting to extension standards like EMS (expanded memory) and XMS (extended memory). (XMS was impossible before the introduction of the 80286 CPU, ca. 1983.) The memory added using these methods was installed on ISA expansion cards and was slower to access than conventional RAM, because it had to be copied into and out of a "page frame" in the lower 1 MB address space in order for its contents to be used under DOS (or used at all with a pre-286 CPU). It was in these times of very limited RAM that the overlay originated.[3] For DOS, the binary files containing memory overlays had a defacto standard extension, .OVL. This file type was used among others by WordStar and dBase.
The GFA BASIC compiler was able to produce .OVL files.