Memory Overlay

Hi,

I am trying to understand Memory Overlay. I got few links from internet , but they are not very elaborative.

Is there any other link / pdf that talks in detail about this Memory Overlay ?

Thx in advans, Karthik Balaguru

Reply to
karthikbalaguru
Loading thread data ...

I understand that by using the overlay technique, the different sections defined in the LDF (Linker Descriptor File / Linker Script / Linker Command File) can be loaded as part of a single memory image but run at the same memory address.

Even though we succeed in placing the different sections as part of single memory image, how is the particular section identified and loaded while execution ? Is this feature good compared to virtual memory ? But, how is this managed ? Is there any link in internet that talks in detail about these ?

Thx in advans, Karthik Balaguru

Reply to
karthikbalaguru

In GOOGLE I entered Memory Overlay Techniques and got about 312,000 results for Memory Overlay techniques. Among the top listings is one from IEEE which should help. Otherwise come back with some more specific questions and we can help.

Ed

Reply to
Ed Prochak

Thx for that info. :)

I understand overlay technique. But, My earlier queries were

1) in relation to selecting the correct one at the appropriate time. " Even though we succeed in placing the different sections as part of single memory image, how is the particular section identified and loaded while execution ? "

2) in comparison with vitual memory " Is this feature good compared to virtual memory ? "

Anyhow,Thx!!.Lot of links are in internet. I got a link that answers to my queries ->

formatting link

8.memory.pdf

" Even though we succeed in placing the different sections as part of single memory image, how is the particular section identified and loaded while execution ? "

How do we keep track of what is where ? Clearly, we can no longer simply call, say, procedure B. Instead, we must first ask whether or not B is present in memory; if not, B must be loaded. Then B can be entered in the usual way.

In practice, the ordinary programmer should not have to worry about the details, which are handled by software associated with the linker. The programmer does have to say which procedures are to be handled as overlays, because the decision must be based on an understanding of the flow of control through the programme, and that information is not necessarily available to the linker.

The information is available to the compiler; should it be made available to the system as a whole, so that memory management strategies can be made more precise ? That's a matter to be decided when designing the operating system. If the information is required, it must be laid down as a system standard requirement. To our knowledge, no system has stipulated that compiler code files should contain information of this sort.

And, the below lines answer to my query related with virtual memory and overlay " Is this feature good compared to virtual memory ? " ->

One difference between the different memory management techniques is in the binding time for addresses ( the time at which the actual address is determined ).

The major difference between overlay methods and the virtual memory systems which came later is that in virtual memory the transfer between memory and disc is managed by the operating system, but in an overlay system the responsibility for memory management lies with the programme itself.

in SPRAA46.pdf i got the below info wrt TI->

Two steps are required to overlay sections:

  1. The linker allocates the sections to a single memory range for running, but different memory ranges for loading.
  2. The application, at runtime, manages the process of copying a section, as needed, from the load memory range to the run memory range.

Implement step 1 with the UNION directive.

Implementing step 2 requires three pieces of information about each section in the overlay:

  • Load address
  • Run address
  • Length The assembler and linker provide support for managing this information in various forms. Such support includes the .label directive, and the linker operators START(), END(), and SIZE(). While useful, these constructs impose a large responsibility upon the user. Further, some operations, such as splitting the load allocation over multiple memory ranges, are not even possible.

Copy tables are a new and improved method for managing overlays.

formatting link
EE249v01.pdf has the below info wrt ADSP ->

In ADSP part of data / program code is loaded into internal memory during the booting process and the remaining part is placed in external memory. When program code (or data) in external memory has to be executed, it is loaded into internal memory and executed.

The memory address range where the overlay function resides in the external memory is called "live address space", and the memory address where the program is executed in internal memory is called "run address space". The code responsible for transferring the data / program code from external memory to internal memory at runtime is called an overlay manager. It typically resides in a reserved space of the DSP's internal memory.

The VisualDSP++ linker automatically generates overlay constants, which configure the BDMA parameters in the overlay manager. Each overlay has a word size, run-time address and live address used by the overlay manager to determine where the overlay resides and where it is executed. The linker-generated constants (where N is the ID# of the overlay) are:

- _ov_startaddress_N (live address space)

- _ov_word_size_run_N

- _ov_word_size_live_N

- _ov_runtimestartaddress_N (run addr. space) The linker is also responsible for resolving the symbol addresses of overlay data and labels.

The Linker Description File (.LDF) in an overlay project has a section called a procedure linkage table (PLIT). The PLIT is a jump table in root memory constructed by the linker. Each call to an overlay section is replaced by a call to the PLIT. The PLIT {} commands provide a template by which the linker generates distinct assembly code for each overlay section. Listing 3 shows an example PLIT section that would be defined in the .LDF file. This section is defined only once in the .LDF file. However, the linker generates separate PLIT code for each overlay function call (pm_ovlay_1 and pm_ovlay_2). In other words, the PLIT {} command in an .LDF file inserts assembly instructions that handle calls to functions in overlays.

There is a flowchart titled "Overlay Function Execution Flowchart", which gives an overall idea.

In the main code, the overlay functions are called similar to ordinary (non-overlay) functions. For the overlay functions, the linker replaces the actual overlay function call with a call to the PLIT code generated for that particular overlay function.

For example, the instruction: call Fast-LED-Blink; is replaced automatically by: call plt_1__.Fast_LED_Blink; Looking back at the code: plt_1__Fast_LED_Blink: AY0 = 0x0001; JUMP Overlay_Manager;

In the AY0=0x0001 instruction, the content of the AY0 register in the plt_1__Fast_LED_Blink table is used as a pointer to access the linkergenerated data in the overlay manager. The next instruction (jump Overlay_Manager ()) transfers program control to the overlay manager. As explained earlier, the overlay manager code initiates a BDMA transfer of the Fast-LEDBlink overlay function from external memory to internal memory. Finally, the overlay manager executes a JUMP instruction to transfer program control to the Fast-LED-Blink() overlay function in run space.

formatting link
res/14_mem_mgmt.ppt has the below info ->

Programmer breaks code into pieces that fit into RAM. Pieces, called overlays, are loaded and unloaded by the program .Does not require OS help

Overlay manager loads an overlay segment when it is not in RAM. Supports Static and Dynamic Overlays.

Static overlays

- One root segment

- 2 or more memory partitions (1 for the root partition which is always in RAM)

- Within each partition, any number of overlay segments

- Only 1 overlay segment can be in a partition at a given time

- Application writer specifies what is in each partition and segment

Dynamic Overlay

- Include re-location information with each overlay segment

- Have overlay manager allocate memory for an overlay segment when it is first loaded

- Load and unload overlay segments by explicit calls to overlay manager

- Each overlay segment is given its own name - linker links each as if it were in its own partition

Problems with Overlays ->

- Difficult for programmer to manage

- Not general - management of resources (RAM) is an operating system issue But many embedded systems do not have the space or power for a "real" OS

Solution -> Virtual Memory

Why is VM important?

- Cheap, no longer have to buy lots of RAM .

- Removes burden of memory resource management from the programmer

Reply to
karthikbalaguru

The issue of overlays, whether to use them and so, like anything in an engineering profession, is a balance of cost, performance, time, resources, and so on. It might just be that the MCU you use is limited to a 65K memory window and is the leat expensive one to do the job.

A simple technique like paging the 32K, so that different physical memory is mapped into it according to a page control register, would allow you to access greater than 64K. Just not at the same time. When creating a linker definition, you simply ensure that functions in paged segments do not access each other - if they must access a function out side its page - that function (or data) must be in the common (lower segment). This is not hard to do - but it requires care. These days though, there aren't too many of us left who are accustomed to working in constrained environments. I see examples of bloated code all the time....

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Gene

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.