ieee transactions on computers, vol. 59, no. 8, august ... · it classifies the code of the...

Scratchpad Memory Management Techniquesfor Code in Embedded Systems

without an MMUBernhard Egger, Member, IEEE, Seungkyun Kim, Student Member, IEEE, Choonki Jang,

Jaejin Lee, Member, IEEE, Sang Lyul Min, Member, IEEE, and Heonshik Shin, Member, IEEE

Abstract—We propose a code scratchpad memory (SPM) management technique with demand paging for embedded systems that

have no memory management unit. Based on profiling information, a postpass optimizer analyzes and optimizes application binaries in

a fully automated process. It classifies the code of the application including libraries into three classes based on a mixed integer linear

programming formulation: External code is executed directly from the external memory. Pinned code is loaded into the SPM when the

application starts and stays in the SPM. Paged code is loaded into/unloaded from the SPM on demand. We evaluate the proposed

technique by running 14 embedded applications both on a cycle-accurate ARM processor simulator and an ARM1136JF-S core. On

the simulator, the reference case, a four-way set-associative cache, is compared to a direct-mapped cache and an SPM of comparable

die area. On average, we observe an improvement of 12 percent in runtime performance and a 21 percent reduction in energy

consumption. On the ARM11 board, the reference case run on the 16-KB four-way set-associative cache is compared to the demand

paging solution on the 16-KB SPM, optionally supported by the cache. The measured results show both a runtime performance

improvement and a reduction of the energy consumption by 23 percent, on average.

Index Terms—Compilers, postpass optimization, code placement, demand paging, scratchpad memory, embedded systems.

Ç

1 INTRODUCTION

IMPROVING runtime performance and reducing energyconsumption in mobile embedded systems remains a

hot topic. Excluding peripherals such as LCD displays, thememory subsystem consumes a substantial portion of thetotal device power. Keeping the most frequently accesseddata close to the CPU avoids costly accesses to the next levelin the memory hierarchy and thereby improves runtimeperformance and energy consumption. Therefore, systemdesigners implement hierarchical memory systems with thefastest, most expensive and smallest memory located closestto and the slowest, cheapest, and biggest memory farthestfrom the CPU.

The level-one (L1) memory is usually either implementedas a hardware cache or as scratchpad memory (SPM).Hardware caches are mostly transparent to the application,however, their behavior is unpredictable to the programmerand the cache management logic and parallel subbankaccesses consume a significant additional amount of energy.SPM, on the other hand, provides a fixed access latency at a

low energy consumption, but its contents need to bemanaged by software. To use the SPM efficiently frequentlyaccessed code and/or data needs to be placed in the SPMwhich requires a careful analysis of the application’s memoryaccess patterns prior to its execution.

While desktop systems execute a wide variety ofapplications that would be difficult to profile and optimize,embedded systems often serve a specific purpose. Softwareis configured and installed on the device before it ships andis rarely changed thereafter. This allows the designers tocustomize embedded applications to a particular hardwareconfiguration. Therefore, the use of scratchpad memory inembedded systems is widespread. Examples of processorswith SPM include some ARMv5 cores [1], ARMv6 cores [2],Intel’s IXP Network Processor [3], the XScale processor [4],Philips’ LPC3180 microcontroller [5], and many more.

Previous studies [6], [7], [8], [9], [10], [11], [12], [13], [14],[15], [16], [17], [18] propose various approaches to mapcode and/or data to the SPM with the goal of reducedenergy consumption or increased runtime performance.Dynamic SPM allocation techniques utilize the given SPMspace better than static techniques which map the mostfrequently executed parts to the SPM and do not change itscontents thereafter. Nevertheless, only a few studies [10],[14], [18], [19] address dynamic code mapping. While thedynamic approaches in [14] and [18] are fully automatic,they require analysis of the application’s source code, andthus, cannot handle library code unless the source code ofthe library is available. In [19], the authors use programtraces to compute the most beneficial set of basic blocks andcould, therefore, handle libraries. However, their frame-work does not produce executable images; instead, it

IEEE TRANSACTIONS ON COMPUTERS, VOL. 59, NO. 8, AUGUST 2010 1047

. B. Egger is with the Samsung Advanced Institute of Technology, San 14-1,Nongseo-dong, Giheung-gu Yongin-si, Gyeonggi-do 446-712, South Korea.E-mail: [email protected].

. S. Kim, C. Jang, J. Lee, S.L. Min, and H. Shin are with the School ofComputer Science and Engineering, Seoul National University, 301 dong554 ho, Seoul 151-742, South Korea.E-mail: {seungkyun, choonki}@aces.snu.ac.kr, [email protected],[email protected], [email protected].

Manuscript received 10 Dec. 2008; revised 4 Nov. 2009; accepted 13 Nov.2009; published online 28 Dec. 2009.Recommended for acceptance by F. Lombardi.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number TC-2008-12-0611.Digital Object Identifier no. 10.1109/TC.2009.188.

0018-9340/10/$26.00 � 2010 IEEE Published by the IEEE Computer Society

analytically computes the expected performance and en-ergy metrics. The approach presented in [10], finally,focuses on high-end embedded systems with a memorymanagement unit (MMU).

In this work, we propose a fully automatic code SPMmanagement technique with demand paging for low-endembedded systems that, due to power and die area con-straints, do neither have an MMU nor a data cache but only aninstruction SPM. A postpass optimizer analyzes applicationbinaries including libraries. Based on profiling information, itdetermines the instruction fetch count for each code block. Amixed integer linear programming (ILP) formulation approx-imates our demand paging algorithm and takes the SPM sizeplus the size and instruction count of each code block asinputs. It classifies each code block into one of three classes:External code resides in and is executed directly from externalmemory. Pinned code is loaded into the SPM when theapplication starts and is SPM-resident for the whole durationof the application’s execution. Paged code, finally, is loadedinto and unloaded from the SPM on demand while theapplication is running. The SPM itself is divided into twoareas: the part that contains the pinned code and the part thatcontains the execution buffer. The execution buffer can beviewed as software-managed buffers that are used to holdpaged code at runtime.

To increase the utilization of the SPM, the postpassoptimizer extracts natural loops from the code andabstracts them as separate code blocks. The ILP solvercan thus assign the less frequently executed sequential codebefore and after the loop body to the external memory,and only the natural loop with a high fetch count perinstruction is loaded into the SPM. While the location ofexternal and pinned code is constant over the course of anapplication’s execution, paged code may reside in theexternal memory or be present the SPM’s execution buffer.Control transfers (i.e., branches) to paged code must beintercepted at runtime and, if necessary, the branch targetmust be loaded into the execution buffer before its code canbe executed. For this purpose, the postpass optimizer linksa small paging manager to the application binary thatintercepts control transfers to paged code, keeps track ofthe contents of the execution buffer, and loads paged codeinto the SPM on demand. To avoid costly runtime checks,the paging manager maintains a jump table that transferscontrol directly to the paged function as long as it is presentin the SPM.

The contributions of this paper are as follows: First, ourapproach is based on compiler postpass optimizations thatoperate directly on the object code or binary executableimage. This makes our technique applicable to wholeprograms, including libraries.

Second, our postpass optimizer extracts natural loopsfrom the application binary and abstracts them as func-tions. This technique is similar to function abstraction orfunction outlining [20]. While placing loops in the SPM issimilar to the loop cache approach [21], [22], our placementis controlled at runtime by software which makes moreeffective use of the SPM.

Third, we approximate the dynamic code mapping fordemand paging with a mixed integer linear programming(ILP) formulation. The classical 0-1 Knapsack formulation is

extended to model our demand paging mechanism. Thesolution of the mixed ILP formulation determines asuboptimal placement of the outlined functions and originalfunctions in the SPM. The solution is suboptimal because theILP formulation conservatively assumes that each controltransfer to paged code will result in loading the code into theexecution buffers, while in reality the code may already bepresent in the SPM, and thus, does not need to be loaded.

Finally, we run the SPM-optimized application binarieson real hardware, an ARM1136JF-S processor. The runtimeperformance is measured by querying the processor’shardware performance counters and is not based onsimulation. The memory access numbers are obtained byrunning the applications on our cycle-accurate ARM simu-lator FaCSim [23]. We explore different L1 instructionmemory configurations consisting of only cache, only SPM,or a mix of both and compare them in terms of runtimeperformance and energy consumption.

We evaluate the proposed technique by running 14embedded applications both on a cycle-accurate ARMprocessor simulator and an ARM1136JF-S core. On thesimulator, the reference case is defined by running theunmodified application on a four-way set-associative cache.It is compared to running the application on a direct-mappedcache and to the proposed demand paging technique on anSPM of comparable die area. On average, we observe animprovement of 12 percent in runtime performance and a21 percent reduction in energy consumption. On the ARM11board, the reference case is obtained by executing the originalapplication on the 16-KB four-way set-associative cache. Wecompare it to our demand paging solution run on the internal16-KB SPM, optionally supported by a 4-KB direct-mappedor the 16-KB four-way set-associative instruction cache. Themeasured results show both a runtime performance im-provement and a reduction of the energy consumption by23 percent, on average.

The rest of this paper is organized as follows: Section 2describes the on demand paging SPM management. Section 3describes the compile-time optimizations. Section 4 presentsour ILP formulation in detail. Section 5 describes theexperimental setup. Sections 6 and 7 discuss the experi-mental results obtained on the simulator and the ARMboard. Section 8 lists related work. Finally, Section 9concludes the paper.

2 RUNTIME SPM MANAGEMENT

The code of an SPM-optimized application binary is dividedinto three classes: external, pinned, and paged code. While thelocation of external and pinned code is fixed for the durationof an application’s run, paged code is loaded into the SPM ondemand by a paging manager. This section explains thepaging manager, its data structures and operation in detail.The postpass optimizer that disassembles the originalapplication and generates an SPM-optimized binary isexplained in Section 3, and the mixed integer linearformulation that is used to classify the code is describedin Section 4.

2.1 Memory Organization and Data Structures

At runtime, the SPM-optimized image is first loaded frompermanent storage into the external memory and the SPM.An SPM-optimized application image contains a small

1048 IEEE TRANSACTIONS ON COMPUTERS, VOL. 59, NO. 8, AUGUST 2010

relocation table that indicates the location of the differentcode sections. Both the external and the paged code sectionare placed in external memory, while the pinned codesection is loaded directly into the SPM (Fig. 1).

The SPM is managed by a paging manager that is linked tothe SPM-optimized application by the postpass optimizer.The paging manager first loads the pinned code section intothe SPM and then passes control to the application’s mainfunction. Control transfers to and from functions in thepaged code segment are modified by the postpass optimizerto pass through the paging manager that will load therequested function into the SPM on demand.

Fig. 2 displays the runtime memory organization and thedata structures of the paging manager that are used tomanage the dynamic contents of the SPM at runtime. Theactual data structures of the page table, the paged functiontable, and the execution buffer are shown shaded. Valuesshown in italic are computed at compile-time by thepostpass optimizer. The table indices in Fig. 2b, 2c, and2d are shown for convenience.

The paged code section. In an SPM-optimized applica-tion image, functions that are to be loaded into the SPM ondemand are grouped together in the paged code section. Theexample in Fig. 2a shows four paged functions.

The page table. The page table contains one entry for eachfunction in the paged code segment (Fig. 2b). Each entrycontains the following information about the correspondingfunction:

. the location of the function in the external memory,

. the size, i.e., the number of pages of the function, and

. if the function is currently loaded into the executionbuffer, this entry contains the index of the first pagein the execution buffer.

The values of the first two columns of the page table arecomputed and initialized by the postpass optimizer atcompile-time. In the example in Fig. 2b, function 1 is twopages long and is currently loaded into the execution bufferstarting at index 1. Since function 4 is not currently presentin the execution buffer, its execution buffer index is not set.

The paged function table. The postpass optimizermodifies each control transfer to functions in the paged codesegment to pass through the paged function table (Fig. 2c). Thistable thus contains one entry for each call and return to afunction in the paged code segment. Each entry is oneinstruction long (i.e., 4 bytes). The contents of a pagedfunction’s entry change at runtime and depend on the currentlocation of the paged function as follows: For functions thatcurrently reside in the execution buffer, the instruction in thepaged function table entry is an unconditional branch to thecurrent location of the callee in the SPM. This scenario iscalled a paged function table hit. In Fig. 2c, functions 1 to 3 arecurrently loaded into the execution buffers, thus, their pagedfunction table entry contains an unconditional branch to theaddress of the function in the execution buffer. When afunction does not currently reside in the execution buffer, theentry in the paged function table contains a SWI (softwareinterrupt) instruction (function 4 in Fig. 2c). The function’sindex in the page table and a target offset are encoded into theimmediate field of the SWI. The SWI exception is thenintercepted by the paging manager. This scenario is called apaged function table miss.

The execution buffer page table. This table contains oneentry per page in the execution buffer (Fig. 2d). Each entryin the execution buffer page table contains the index of thepage currently allocated to the corresponding executionbuffer page. In the example shown in Fig. 2d, the first twopages are currently occupied by function 1, the third page

EGGER ET AL.: SCRATCHPAD MEMORY MANAGEMENT TECHNIQUES FOR CODE IN EMBEDDED SYSTEMS WITHOUT AN MMU 1049

Fig. 1. Application image and runtime memory map.

Fig. 2. Runtime memory organization and paging manager data structures. The actual data structures of the page table (b), the paged function table(c), and the execution buffer table (c) are shaded. Values shown in italic are computed at compile-time.

by function 3, and so on. The paging manager implements asimple round-robin page replacement policy for the execu-tion buffer. More sophisticated replacement policies, suchas LRU, can obtain lower paged function table miss ratesbut increase the complexity of the paging manager andresult in more page manage overhead at runtime.

The execution buffer. The portion of the SPM thatremains unallocated after the pinned code section has beenloaded constitutes the execution buffer (Fig. 2e). The execu-tion buffer resembles a software cache for paged code. Tofacilitate allocation (and deallocation) of paged code tothe execution buffer, both the paged code and the executionbuffer are logically divided into uniformly-sized pages. Theminimal SPM allocation unit is thus one page, however,paged functions may consist of multiple pages.

2.2 Demand Paging

On a paged function table miss, the paging manager firstextracts the function index from the SWI instruction. Usingthe function index, it accesses the page table to determinethe location of the function in the external memory, lext, andthe size of the function in pages, s. If necessary, the pagingmanager then unloads functions currently residing in theSPM’s execution buffer in a round-robin fashion until atleast s pages are available. Then, it loads the requestedfunction from external memory into the execution buffer.The entry in the paged function table is modified so thatsubsequent calls are immediately redirected to the functionresiding in the execution buffer as described in theparagraph above. Similarly, the entries in the paged functiontable of functions that are unloaded from the executionbuffer are replaced by an SWI instruction so that calls to thenow nonresident functions will generate a paged functiontable miss and trigger reloading the function.

Function calls via function pointers cannot be managedwith an indirect jump to the paged function table since thetarget function is not known at compile time. The pagingmanager identifies the callee by the control transfer targetaddress. It then performs a binary search over the pagetable to determine if and what paged function is to becalled. If the target function is not a paged function, controlis transferred directly to the target address. Otherwise, ifnecessary the paged function is loaded first, and executioncontinues from the SPM.

Function returns to paged functions are handled in asimilar fashion. When calling an other function from a pagedfunction, the return address is modified to point to the correctentry in the paged function table. On a paged function table hit,the page table entry already contains the correct returnstatement. On a paged function table miss, the paging managerloads the function into the execution buffer and replaces theSWI instruction with a jump to the instruction following thefunction call. In contrast to function calls where control istransferred to the first statement of the loaded function, thereturn address is usually located somewhere within thefunction’s code. For this reason, not only the function index,but also the offset between the start of the function and thepoint of return is encoded into the immediate field of the SWI.The target address is computed by adding the offset to thefunction’s start address.

Functions called by different callers, i.e., a paged functionand a pinned function, do not pose any problems since onlythe function call of the caller is modified and the actual returnstatement in the callee remains unchanged (Section 3.2).

3 COMPILE-TIME OPTIMIZATIONS

Our code SPM management technique with demand pagingloads code segments that have been classified as paged intothe SPM on demand. At compile time, a postpass optimizerthat operates on application binaries including librariesanalyzes the code based on profile information. It thengenerates an SPM-optimized application binary containinga small paging manager that manages the SPM at runtime.This section describes the postpass optimizer, its optimiza-tions, and the specific code transformations necessary fordemand paging in detail.

3.1 The Postpass Optimizer

A postpass optimizer has several advantages over source-level transformations. First, any binary can be optimizedsince access to the source code and recompilation of theapplication is not necessary. Second, a postpass optimizercan perform whole program optimization including li-braries, which is virtually impossible at the source level.Finally, since code layout optimizations are of low-levelnature, postpass code arrangement is well-suited for thispurpose. Fig. 3 displays the organization of our postpassoptimizer framework called SNACK-pop. SNACK-pop ispart of the Seoul National University Advanced CompilerTool Kit [24].

The postpass optimizer takes application binaries andlibraries as its inputs. To enable relocation of code and data,SNACK-pop disassembles the code into basic blocks andreplaces hard-coded offsets of branches and load/storeinstructions by relocation information. After the code and/or data transformations are performed, the postpassoptimizer re-assembles the application by resolving allrelocations and outputs an executable binary. Currently,


Fig. 3. The postpass optimizer.

SNACK-pop supports the ARM instruction set [25], andinput and output files are stored in ARM ELF format.

To generate an SPM-optimized binary with demandpaging, SNACK-pop first runs the unmodified referenceimage on a functional instruction set simulator to obtaininstruction and memory traces. It then analyzes the instruc-tion traces to construct the dynamic call/return profiles.Several profiles and instruction traces can be generated withdifferent training input sets to get binaries that are notspecifically optimized towards one specific input.

From the execution profiles SNACK-pop then generatesinput files for an ILP solver and runs the solver. The storageclass of each function (pinned, external, or paged) is deter-mined by the ILP (Section 4 describes the ILP formulation indetail). SNACK-pop rearranges the code according to theresult of the ILP and generates an SPM-optimized ELFbinary that also contains the paging manager and its datastructures (see Section 2).

In order to extract natural loops and relocate code atruntime, special care needs to be taken (a) when argumentsto functions contain references to constant pools and (b) inthe case of jump tables. SNACK-pop handles these twocases as follows:

Constant data. ARM compilers embed data, so-calledconstant pools, in between code sections because of thelimited immediate offsets imposed by the instruction set.Consider a function foo(), for example, that calls the strcmp()string comparison function with a hard-coded string as oneof the arguments. The character data of the string is placedin foo’s constant pool (Fig. 4a). If both foo() and strcmp() areclassified as paged code, then loading strcmp() into the SPMon demand might cause foo() to be evicted from the SPM.The argument pointing to the string in foo’s constant poolwould now point to an invalid location in the SPM that doesnot contain the string anymore. SNACK-pop, therefore,

extracts data in local data pools that is referenced from

external functions and places it in the global data section.

The original data is replaced by a reference to the global

data (Fig. 4b).PC-relative data table accesses. Data accesses to tables

using PC-relative addressing also require special care

because the offset between the instruction accessing the

data and the data itself must not change. This hinders

extraction of natural loops from functions. An example of

such a data table access is shown below

0�20 add r0; pc;#0�18; ¼ 0�400�24 ldrb r2; ½r0; . . .�

. . .

. . .0�50 dcd 0�160919810�54 dcd 0�22051975

The add instruction computes the base address of the data

table (r0=0�40 since the PC contains the address of the

current instruction þ 8), which is not necessarily identical

to the start address of the actual data (0�50) to be

accessed. The following ldrb instruction uses the base

address in r0 as the base register for the data access, i.e.,

the table offset is computed relative to the location of the

add instruction. In order to be able to independently move

both the code block containing the add, ldrb sequence as

well as the data block containing the table, SNACK-pop

inserts a symbol to the beginning of the data table, and

adds a relocation object with the correct offset to the add

instruction as follows:

0�20 add r0; pc; freloc to :datatab-0�10g0�24 ldrb r2; ½r0; . . .�

. . .

:datatab0�88 dcd 0�160919810�8c dcd 0�22051975

i.e., the base address of the table access is now computed

relative to the data table, and not relative to the add

instruction any more.

3.2 Call/Return Expansion

To enable demand paging at runtime (Section 2), SNACK-

pop needs to modify all control transfers to paged

functions. This includes not only function calls but also

function returns to paged functions because the caller (i.e.,

the paged function) may have been paged out during the

execution of the callee and may need to be reloaded into the

SPM when the function call returns.SNACK-pop identifies all control transfers to paged

functions based on the static call graph. For control transfers

from and to functions classified as external or pinned no code

patching is necessary since the location of the code is fixed

and known at compile-time. Thus, for any pair ðfo; ftÞ,where fo denotes the caller and ft the callee that is either

paged or unknown at compile-time (i.e., a call through a

function pointer), SNACK-pop modifies the control transfer

as follows:


Fig. 4. Constant data extraction from local constant pools.

Subroutine calls (Fig. 5). Subroutines are invoked withthe bl target (branch-and-link) instruction. The linkregister (LR) is set to the instruction following the branch,and the program counter (PC) is set to target. When thecallee returns, it sets the PC to the value stored in the linkregister (mov pc, lr), and execution continues immedi-ately after the caller’s subroutine invocation (that is, thebranch instruction). SNACK-pop replaces the direct call byone to the callee’s paged function table entry (Section 2.1). Forstatic callers, i.e., callers in external or pinned, no furtherchanges are necessary. If the caller itself is also paged,however, the control transfer from the callee back to thecaller must go through the paged function table as wellbecause the caller might not reside in the SPM anymorewhen the call returns. SNACK-pop therefore modifies thecall as shown in the bottom right part of Fig. 5. First, theaddress of the paged function table entry back to the caller isloaded into the link register (ldr lr, =L1), then executioncontinues at the callee’s paged function table entry. When thecallee returns, control is transferred to said return entry inthe paged function table. If the caller has been paged outduring the execution of the callee, the paging managerreloads the caller, then, execution continues in the caller.

Subroutine calls via function pointers (Fig. 6). Sub-routine calls via function pointers are usually invoked bymanually setting the link register (mov lr, pc) and thenbranching to the function pointer stored in a register, b rx

(Note that on ARM systems, the PC contains the address ofthe current instruction þ 8). Since the callee is not known atcompile-time, calls via function pointers cannot go throughthe paged function table because the postpass optimizer doesnot know which entry to access. Instead, such calls are

handled at runtime by the paging manager. For this purpose,SNACK-pop first pushes the target address of the functionto be called onto the local stack from where it is retrieved bythe paging manager. The function pointer address is thenused as the key in a binary search over all paged functions.As soon as the callee has been identified, control is directlytransferred to it. Depending on whether the caller itself is apaged function or not, the return mechanism from the calleehas to be modified in the same manner as shown in theprevious paragraph for subroutine calls.

Branches (Fig. 7). For tail-call optimized function callsthat are encoded as simple branches, SNACK-pop modifiesthe branch target to the corresponding paged function table

entry. This transformation is independent of the location ofthe caller.

Fig. 8 displays a call/return scenario to a paged functionfooðÞ from a static caller as well as a paged function barðÞ.Whereas the call to fooðÞ in the static caller simply points tothe paged function table entry of fooðÞ, the one in the pagedfunction also includes modifying the return address topoint to the paged function table entry of the return fromfooðÞ to the caller barðÞ. Depending on the current locationof the pageable functions, control is immediately forwardedto the paged function or, if the target function is notcurrently present in the execution buffer, it is first loaded bythe paging manager before execution continues. Similarly,when fooðÞ returns to the static caller, the program counteris set to the link register. When fooðÞ returns to the pagedcaller, the link register contains the address of bar_ret inthe function table.

3.3 Natural Loop Extraction

To most effectively exploit the SPM, the instruction fetchesper word (FPW ) ratio should be as high as possible. Basedon this observation, the postpass optimizer extracts naturalloops from functions. Each natural loop is abstracted into itsown function and the original code is replaced with abranch to the loop function.

Natural loops (or loop nests) are abstracted as functionswhen their dynamic instruction fetch count is bigger thanthe static instruction count, i.e., FPW > 1. A loop nest is notabstracted if its code size exceeds r percent of the totalfunction size. This is to obtain a higher number of smallerfunctions with a high FPW ratio which results in bettersolutions of the ILP formulation. We use r ¼ 50.


Fig. 5. Call/return expansion for subroutine calls.

Fig. 6. Call/return expansion for function pointers.

Fig. 7. Call/return expansion for branches.

4 ILP FORMULATION

A simple and intuitive solution to SPM code placementwithout paging is mapping it to the 0-1 Knapsack problem[7], [8], [15], [26]. The objective is to maximize performanceand/or minimize the energy consumed by memory accesses.Such a 0-1 Knapsack formulation gives an optimal mappingfor SPM. We extend the formulation later to approximate ourdemand paging mechanism.

4.1 0-1 Knapsack Problem

The problem is mapped to the 0-1 knapsack problem asfollows: There are N functions in the program. For everyfunction fi, we denote the size in bytes of fi by Si and thedynamic number of instruction fetches plus the number ofaccesses to the read-only data located within fi by Ai, whereboth Si and Ai are integers. The problem to be solved is:given the SPM size M bytes, what function placementmaximizes the number of instructions fetches and local datareads from the SPM?

Since SPM (i.e., on-chip SRAM) and external memory(i.e., SDRAM) differ by an order of magnitude in bothaccess time and energy consumption, finding the solution tothe 0-1 knapsack problem involves minimizing energyconsumption and maximizing performance simultaneously.Here we formulate the 0-1 Knapsack problem as a binaryinteger linear programming problem whose solution givesthe optimal solution for a static SPM allocation. Similarformulations are used to map code into the SPM in [7], [8],[15]. In our formulation, the following symbols are used:

Ai The number of instruction fetches and read-only

data word accesses located in a function fi;

Si The size of a function fi in bytes;

N The number of functions in the application;

Sspm The size of the SPM in bytes;

Espm The energy consumed to fetch an instruction

(or read a word) from the SPM;

Eext The energy consumed to fetch an instruction

(or read a word) from the external memory.

For each function fi, the binary integer variables Ispm and

Iext are defined by

IspmðiÞ ¼1; if fi is placed in the SPM0; otherwise;

�

IextðiÞ ¼1; if fi is placed in the external memory0; otherwise:

�

The objective function to be minimized is the total energy

consumption of all memory accesses caused by instruction

fetches:

Xi¼1;N

ðIspmðiÞ �Ai � Espm þ IextðiÞ � Ai � EextÞ;

Since each function can be placed in only one memory

location (i.e., either in the SPM or the external memory, but

not both),

IspmðiÞ þ IextðiÞ ¼ 1 for all 0 < i � N;

In addition, the total size of all functions placed in the SPM

must not exceed the size of the SPM

XNi¼1

IspmðiÞ � Si � Sspm;

If we intend to maximize performance rather than

minimize energy consumption, we can define Espm and Eext


Fig. 8. Call/return scenario to a paged function foo().

as the memory access times to fetch an instruction from theSPM and external memory, respectively.

The objective function with the above constraints issolved with an integer ILP solver. The result, i.e., the valuesof the binary integer variables denoting the memorylocation for each function (IspmðiÞ and IextðiÞ) are used bythe postpass optimizer to generate the SPM-optimizedapplication binary (Section 3).

4.2 Extension to Demand Paging

When it comes to demand paging, we have another class offunctions: paged. Functions in this class reside in the externalmemory, but are copied into the execution buffer in theSPM on demand before they are executed. In terms of theILP formulation, we define a third memory location calledpaged and modify the object function of the ILP. The binaryILP formulation now becomes a mixed integer linearprogramming formulation. First, we define a binary integervariable Ipaged for paged memory as follows:

IpagedðiÞ ¼1; if fi is in paged0; otherwise:

�

The constraints for the execution buffer size and the factthat the execution buffer must be large enough to hold thelargest paged function are given by:

0 � Ibuffer � P � Sspm;IpagedðiÞ � Si � Ibuffer � P;

where P is the page size and Ibuffer is a new general integervariable representing the size of the execution buffer inpage units. The objective function then becomes

Xi¼1;N

ðIspmðiÞ �Ai � Espm þ IextðiÞ �Ai � Eext

þ IpagedðiÞ � ½Ai � Espm þ Penaltyi�Þ;

where Penaltyi is the energy consumed by copying functionfi from the external memory into the SPM:

Penaltyi ¼ ðCi þRiÞðEspm þ EextÞðdSi=PeðP=4ÞÞþ CiEc þRiEr;

with

Ci Number of calls to fi;

Ri Number of returns to fi;

Ec Energy consumed by extra instructions generated

by the call expansion;

Er Energy consumed by extra instructions generatedby the return expansion.

where P=4 is the number of words in a page, anddSi=PeðP=4Þ is the total number of words to be copied.

Similar to the formulation in Section 4.1, each functioncan be located in exactly one place, which gives thefollowing constraint:

IspmðiÞ þ IextðiÞ þ IpagedðiÞ ¼ 1 for all 0 < i � N:

In addition, the sum of the sizes of the functions placedin the SPM cannot exceed the size of the SPM minus theexecution buffer size.

Xi¼1;N

IspmðiÞ � Si � Sspm � Ibuffer � P:

We conservatively assume that a each function in pagedneeds to be loaded into the execution buffer whenever it iscalled or returned to. In reality, the function might stillreside in the execution buffer. For this reason, our mixedinteger linear programming model produces a suboptimalsolution to the dynamic scratchpad memory allocationproblem. The optimal solution is not computable unless weknow the exact order in which the function calls occur.

To make our demand paging more effective, we break afunction into inner natural loops of a size smaller than apredefined threshold value St if the outlined functionconstructed from a natural loop is too big. In our case,St ¼ 256 bytes. This makes the execution buffer size smallerand results in better SPM space utilization.

5 EXPERIMENTAL SETUP

We have evaluated the proposed SPM allocation scheme withdemand paging on a cycle-accurate ARM9 simulator as wellas real hardware, an ARM1136 core. The experiments basedon simulation analyze the performance of our SPM allocationscheme under tight resource constraints (Section 6), whereasthe board experiments examine how much performanceimprovement we get on given hardware in Section 7.

This section describes the benchmark applications andthe energy model.

5.1 Applications

We study the performance and energy consumption of theproposed SPM allocation scheme with a total of 19 em-bedded applications. We use multimedia benchmarks fromMIbench [27], MediaBench [28], EEMBC [29], the standardMP3 decoder [30], a H.264 decoder [31], and a public-keyencryption/decryption tool [32]. We combine six smallapplications from MIbench and MediaBench, quicksort,dijkstra, sha, adpcm-enc, adpcm-dec, and bitcount into oneapplication called combine to represent an application withdistinct phases. Each of the six applications is executed once.

5.2 Performance Metrics

We use the total execution time as the performance metricand the total energy consumed by the core and the memorysubsystem as the energy metric. The execution time iscomputed by dividing the measured number of core clocksby the core clock frequency

Ttotal ¼# core clocks

core frequency:

The consumed energy is computed by summing up the coreenergy, the on-chip memory system with the instructiondata cache, the SPM, the off-chip bus, and the externalmemory (SDRAM)

Etotal ¼ Ecore þEicache þ ESPM þEext static þ Eext dynamic:

The core energy is computed by

Ecore ¼ Ttotal � Pcore � fcore;


where fcore is the core frequency in MHz and pcore the power

per MHz parameter from Table 1. The energies consumed bythe cache and the SPM, respectively, are computed by

Ecache ¼ ecacheðhitþmiss � linesizeÞ;ESPM ¼ eSPMðreadþ writeÞ;

where ecache, and eSPM are taken from Table 1. Hit and miss

denote the number of hits and the number of misses for the

corresponding memory structures, respectively.The SDRAM energy is composed of static and dynamic

energy [33]. We have modeled the low power 64 MBSamsung K4X51163PC SDRAM [34] with a memory busfrequency fmem ¼ 66 MHz and a supply voltage Vdd ¼ 1:8V .The static energy consumption, Eext static, includes thestandby power and the power to periodically refresh theSDRAM cells and is computed by

Eext static ¼ Ttotal � Pstandby;

where Pstandby is the static power consumption of theSDRAM (Table 1). The dynamic energy,

Eext dynamic ¼ ereadrandom � readrandomþ ereadburst � readburstþ ewriterandom � writerandomþ ewriteburst � writeburst

includes both SDRAM dynamic energy and the memorybus energy. The energies eread=writerandom=burst denote the per-word access energy for a random/burst read/writeaccess, respectively.

Table 1 lists the values used for the energy calculations.All energy parameters are the energy required per word (4 byte)

access, including the values for SDRAM read/write burst.The cache and SPM access energies were computed for0:13 �m technology using CACTI 3.2 [35]. Access energies forSPM sizes not a power of two are interpolated. The corepower consumption for a 0:13 �m ARM926EJ-S core withoutcaches was taken from [36], and that for the ARM1136 corefrom [37]. The static and dynamic energy of the SDRAM werecomputed using the System Power Calculator from [38], andthe bus energy was taken from [39].

6 EVALUATION BASED ON SIMULATION

We first evaluate the proposed SPM allocation schemeunder tight resource constraints on a cycle-accurate ARM9simulator [23]. We show that demand paging outperforms astatic SPM allocation, a four-way set-associative cache, anda direct-mapped cache.

6.1 Experimental Environment

The purpose of the simulated results is to show that ourSPM allocation scheme with demand paging surpasses theoptimal static SPM allocation, a four-way set-associativecache, and a direct-mapped cache on comparable die area.For each benchmark, we set the SPM size so that 90 percentof all instruction fetches go to the SPM with the optimalstatic allocation. Once the SPM size has been determined,we set the sizes of the four-way set-associative and thedirect-mapped cache such that the caches occupy acomparable die area to the SPM. The SPM is allocated in512-byte blocks, and the size of the caches is a power of two.Table 2 shows the on-chip memory configuration: columntwo lists the size of the executed code. Column three showsthe SPM size. Columns four and five list the size and diearea in comparison to the SPM of the four-way set-associative cache. Columns six and seven show the samedata for the direct-mapped cache. Column eight shows thenumber of paged functions for the allocation scheme withdemand paging. If the number of paged functions is zero,the ILP produced the identical SPM allocation for the staticand the demand paging allocation schemes. Column nineshows the number of pages in the execution buffer. The last


TABLE 1Per-Word Access Energy and Power Parameters

TABLE 2Application Code, SPM, Cache,Page Manager, and Table Sizes

two columns, finally, list the overhead of the pagingmanager (code and static data) and that of the requiredruntime data structures (see Section 2.1). For many bench-marks, the required die area of the caches is significantlybigger than the SPM because we have chosen the nextbigger cache size if the smaller size required less than90 percent of the SPM area. This is a conservative approachsince it favors the cache.

The benchmark applications are run on FaCSim [23], acycle-accurate ARM core simulator. FaCSim models the five-stage pipeline of the ARM9 core and includes cycle-accuratemodels for caches, SPM, the memory management unit(MMU), translation lookaside buffers (TLB), as well as AMBAand AIX buses. The external memory and several peripheralcomponents are also modeled accurately. The CPU core clockis set to 200 MHz, and the bus clock is 66 MHz. The resultingaccess latencies for the different memories are shown inTable 3. The CPU core energy of an ARM9 core without MMUand TLBs is assumed to be similar to the 0:13 �m ARM7EJ-Schip that neither contains caches, nor an MMU or TLBs(Table 1). The energy consumption of the cache, SPM, andexternal memory are computed as shown in Section 5.2.

6.2 Results

Figs. 9 and 10 compare the normalized energy consumptionand the normalized die area of the reference case, denotedcache_4way and obtained by running the benchmark on afour-way set-associative cache, to a setup with a direct-mapped cache (denoted cache_direct), and to the optimalstatic (static) and the demand paging (paging) SPM alloca-tion technique run on a core with scratchpad memory only.


TABLE 3Access Latencies in CPU Cycles

Fig. 9. Normalized energy consumption and normalized die area for the reference image with a four-way set-associative cache, cache_4way,compared to a direct-mapped cache, cache_direct, and the optimal static, nloop, and the proposed SPM allocation technique with demand paging,paging.

The application image used for the cache_4way and the

cache_direct configuration is the unmodified applicationbinary as generated by an ARM compiler. The SPM-

optimized image in the nloop configuration is generated by

applying the optimal static SPM allocation after natural loop

extraction with our postpass optimizer (Sections 3 and 4.1).Similarly, the SPM-optimized image for the paging config-

uration is produced by solving the ILP with the extension to

demand paging as described in Section 4.2. The sizes for the

four-way set-associative and direct-mapped cache and theSPM are shown in Table 2.

The normalized energy consumption in Figs. 9 and 10shows the energy consumption of the processor core and

the memory subsystem. Each bar is normalized to the value

of the reference case, cache_4way. In each bar, CPU core

represents the amount of energy consumed by the CPU

core. SDRAM is the amount of energy consumed by the

external memory and includes both static and dynamic

energy. For configurations with a cache, icache stands forthe instruction cache energy consumption, and for config-

urations with an SPM, SPM denotes the energy consumed

by the scratchpad memory.

Since CPU core is obtained by multiplying the (constant)

CPU core power consumption by the runtime, CPU core isproportional to the execution time. Thus, the height of CPU

core also represents the execution time of each case relative

to the execution time of the reference case.Figs. 9 and 10 show that for most benchmarks, the SPM

achieves a significant reduction in energy consumption. This

is thanks to the faster runtime and the reduced energyconsumption of the on-chip memory system. Additionally,

the number of external memory accesses, and thus, the

overall runtime, can be lowered considerably for some

benchmarks that contain a lot of local data accesses to localdata pools (containing constant values or pointers to global

variables) since our technique allocates those pools to the

SPM as well whereas with a cache accesses to the local datapools often go to external memory due to the relatively short

cache line. For unepic, the direct-mapped cache outperforms

the static as well as the dynamic SPM allocation because the

size of the direct-mapped cache (4 KB) is bigger than theSPM size (3.5 KB). For pgpd, both the cache size as well as the

SPM size are relatively small (512 B and 1 KB, respectively).

For such small sizes, caches with their small linesize of 16 or


Fig. 10. Normalized energy consumption and normalized die area for the reference image with a four-way set-associative cache, cache_4way,compared to a direct-mapped cache, cache_direct, and the optimal static, nloop, and the proposed SPM allocation technique with demand paging,paging.

32 bytes are better able to map the hot code than SPMallocation schemes that operate on much bigger chunks ofcode (in our case, the minimal unit for static placement is afunction).

Table 4 summarizes the runtime performance andenergy consumption of cache_direct, static, and pagingrelative to the reference case, cache_4way. All three casesoutperform the reference case. The direct-mapped cacheruns, on average, 9 percent faster and requires 16 percentless energy. The optimal static SPM allocation runs 6 percentfaster and reduces the energy consumption by 14 percent.The proposed dynamic SPM allocation technique withdemand paging, finally, outperforms all other cases andachieves a reduction of 12 percent in runtime performanceand 19 percent in energy consumption. In our configura-tion, the direct-mapped cache outperforms the staticSPM allocation. This is not a contradiction to earlier resultsthat show that for similar die area requirements the optimalstatic SPM allocation outperforms a cache because in oursetup, on average, the size and the die area of the direct-mapped cache are 5 percent, respectively 20 percent largerthan those of the SPM (Table 2).

7 EVALUATION ON THE ARM1136 CORE

In this section, we evaluate the proposed SPM allocationscheme on real hardware, an ARM1136JF-S processor, andshow that the demand paging technique achieves significantenergy savings and runtime performance improvements.

7.1 Experimental Environment

While in the previous section we have shown that thedynamic SPM allocation scheme with demand pagingperforms well under tight resource constraints, in thissection we examine the performance of the proposedscheme on an ARM1136JF-S processor. The ARM1136JF-S’L1 memory system consists of a 16-KB four-way set-associative cache and a 16-KB SPM on the instruction aswell as on the data side. Both the cache and the SPM have anaccess latency of one cycle. We use ARM’s RealViewEmulation Baseboard with an ARM1136JF-S core tile [37].

The CPU core clock is set to 280 MHz and the core-clock-to-bus-clock divider is set to 14.

We run each benchmark in four different configura-tions: 16-KB four-way set-associative cache, 16-KB SPM,16-KB SPM plus 4-KB direct-mapped cache, and 16-KBSPM plus 16-KB four-way set associative cache. To obtain a4-KB direct-mapped cache, we disable three of the fourways of the instruction cache. The data cache and theMMU are turned off in all configurations.

The runtime performance of each configuration ismeasured by directly reading the CPU’s performancecounters. The memory access numbers are obtained froma functional simulator. The ARM1136JF-S core powerconsumption is listed in Table 1. The on-chip and off-chipmemory system energy consumption is computed as shownin Section 5.2.

7.2 Results

Fig. 11 compares the normalized energy consumption andruntime performance of the reference case, denoted16K Icache and obtained by running the benchmark on the16-KB four-way set-associative instruction cache, to a setupwith the 16-KB SPM only (16K SPM), to the 16-KB SPM witha 4-KB direct-mapped cache (denoted 4K Direct-IC+16KSPM) and the 16-KB SPM with the 16-KB four-way set-associative instruction cache (16K IC+16K SPM). In the16K Icache setup, the original reference image is used. Forthe configurations with SPM, we have generated thebenchmarks images applying the proposed dynamic SPMallocation scheme with demand paging.

The normalized energy consumption shows the energyconsumption of the processor core and the variousmemories. Each bar is normalized to the value of thereference case, 16K Icache. In each bar, CPU core representsthe amount of energy consumed by the CPU core. SDRAMis the amount of energy consumed by the external memoryand includes both static and dynamic energy. For config-urations with a cache, icache stands for the instructioncache energy consumption, and for configurations with anSPM, SPM denotes the energy consumed by the scratch-pad memory. The runtime is measured directly on theboard and is reflected by the height of CPU core.Unfortunately, it is not possible to measure the energydirectly on the evaluation baseboard because the variouscomponents cannot be measured independently. Further-more, the evaluation board is not built for low-power, sothe power consumption by the core and memory system istoo small in comparison to the total board powerconsumption to be significant. We have therefore com-puted the energy consumption of the core and the memorysubsystem analytically.

Fig. 11 shows that for all benchmarks a significantimprovement in runtime performance can be achieved bysubstituting the instruction cache with an SPM. Since theinstruction cache miss ratio is already very low for mostbenchmarks, the runtime improvements stem not only fromthe reduced cache misses but also (and mostly) from readsto local data pools that go to the SPM. For most bench-marks, the presence of a 4-KB direct-mapped or a 16-KBfour-way set-associative cache does not improve perfor-mance further because most of the instruction fetches can be


TABLE 4Simulated Energy Consumption and Runtime Performance

covered by the (in comparison to the benchmarks) relatively

big SPM. Notable exceptions are h264 and mp4e. Not

surprisingly, these are two of the biggest benchmarks with

code sizes well beyond 16 KB.Table 5 summarizes the runtime performance and

energy consumption of 16K SPM, 4K Direct-IC+16K SPM,

and 16K IC+16K SPM relative to the reference case,

16K Icache. The energy consumption is clearly dominated

by the runtime performance. The 16-KB SPM case runs, on

average, 23 percent faster and consumes 23 percent less

energy. The configurations with 4-KB direct-mapped and

16-KB four-way set-associative cache achieve a reduction in

runtime performance and energy consumption of 24 per-cent, on average. This difference is mostly caused by h264

and mp4e which both profit most from the added cache.

8 RELATED WORK

Steinke et al. [14] proposed a technique that dynamicallycopies code sections into the SPM. At selected programpoints, they insert copying function calls that copy acorresponding program part (i.e., a loop or a functionbody) into the SPM. Their technique automatically selectsthe copy points and program parts that can be active at thesame time in the SPM. After determining the candidates for


Fig. 11. Normalized energy consumption and runtime performance for the reference image with a 16-KB four-way set-associative cache, 16K Icache,compared to 16-KB SPM, 16K SPM, a 16-KB SPM plus a 4-KB direct-mapped cache, 4K Direct-IC+16K SPM, and a 16-KB SPM with a 16-KB four-way set-associative cache, 16K IC+16K SPM.

copy points and program parts, they compute energy costsand select an optimal set of program parts for dynamiccopying by solving an ILP problem. Verma et al. [18]proposed a technique to share the SPM between variousmemory objects (e.g., global variables, nonscalar localvariables, and code segments) using the overlay technique.Their approach is capable of handling both instructions anddata in a dynamic way at the same time. They performlifetime analysis on memory objects by analyzing memorytraces to assign the SPM space. The memory objects arecopied into the SPM when they are required.

While the approaches in [14] and [18] require theapplication’s source code, our approach requires only objectcode or binary code. The SPM space is shared betweenfunctions and loops in the whole program, includinglibraries, resulting in better utilization of the SPM space.Automatic code overlay [40], [41] could be used with ourapproach instead of demand paging. However, automaticcode overlay incurs a code copy cost, and it requires theSPM size to be greater than the sum of the function sizes inthe application’s maximum call chain.

Recently, Janapsatya et al. [19] proposed a dynamic SPMallocation strategy based on the so-called concomitancemetric. Concomitance is a measure to indicate how tempo-rally related two code blocks are. The concomitance iscomputed based on profiling information, and the resultingdynamic SPM allocation is evaluated using several energymodels without producing a running version of the SPM-enabled application.

In [10], Egger et al. proposed a dynamic SPM manage-ment technique for systems with virtual memory. Apostpass optimizer groups code that is to be run from theSPM into pages and places them in a special memoryregion. At runtime, the memory management unit’s pagefault exception mechanism is used to track the course of theprogram and copy the code to the SPM on demand.

Beyond these dynamic approaches, some studies havebeen done on static code mapping to SPM. Steinke et al. [15]proposed a static and optimal selection algorithm. Thealgorithm selects beneficial program parts (e.g., basicblocks) and variables that can be placed in the SPM to save

energy. Their mapping problem is formulated as aKnapsack problem. Angiolini et al. [6], [7] proposed apostpass and static approach, based on dynamic program-ming, to find an optimal set of frequently accessedinstruction blocks to map to the SPM. Their formulation isa variant of the Knapsack problem, which considers extrainstructions to relocate the code blocks. Verma et al. [18]proposed a static algorithm and an ILP formulation that canbe applied to embedded systems with caches in addition toSPM in order to reduce the energy consumed by instructionfetches. Our approach is different from the static solutionsin that we focus on a dynamic code placement techniquethat is based on demand paging and an approximatedmixed ILP formulation.

Many studies on SPM management techniques focus onassigning data objects to the SPM statically or dynamically.Udayakumaran and Barua [16] proposed a compiler algo-rithm for dynamically managing the SPM to place globaland stack variables. Avissar and Barua [8] proposed a staticdata partitioning algorithm between SPM and externalmemory to improve performance. Their technique is basedon a binary ILP formulation. Francesco et al. [11] proposed aruntime mechanism that uses direct memory access (DMA)engines to reduce the cost of dynamically copying data tothe SPM and provides an application programmer’s inter-face (API) to utilize them. Kandemir et al. [12], [13] proposeda compiler technique based on loop transformations thatdynamically manages SPM for arrays. Panda et al. [42]introduced techniques to partition on-chip memory intoSPM and cache areas. To improve performance, theystatically assign critical data in the program to the SPM.

9 CONCLUSION

This paper proposes and evaluates a dynamic code SPMmanagement technique with demand paging for embeddedprocessors. In a fully automated process, a postpassoptimizer generates optimized binaries that load frequentlyexecuted code into the SPM on demand. The codeplacement is based on a mixed ILP formulation for anextended Knapsack problem.

We have evaluated the proposed dynamic SPM manage-ment technique on a cycle-accurate simulator as well as anARM1136JF-S processor with 14 embedded applications,including an H.264 video decoder, an MP3 decoder, anMPEG-4 video encoder/decoder, and a public-key encryp-tion/decryption tool. Run in a resource-constrained envir-onment, the simulated results show the superiority of thedemand paging technique over a four-way set-associativecache, a direct-mapped cache, and the optimal static SPMallocation. Compared to the set-associative cache, thedynamic SPM allocation technique with demand pagingachieves a 12 percent improvement in runtime and a19 percent reduction in energy consumption, on average.The results obtained on the ARM1136JF-S processor confirmthe simulated results. Compared to the 16-KB four-way set-associative cache, the SPM-optimized benchmarks run23 percent faster and consume 23 percent less energy, onaverage.

Our results show that using SPM with compilerassistance increases both performance and energy savings


TABLE 5Board Energy Consumption and Runtime Performance

for embedded systems compared to the case using instruc-tion caches. For resource constrained systems, processorswith instruction SPM combined with postpass optimizationtechniques are thus a promising alternative to processorswith instruction caches.

ACKNOWLEDGMENTS

The authors would like to thank the anonymous reviewersfor their helpful comments and suggestions. This work wassupported in part by the Creative Research Initiatives(Center for Manycore Programming, 2009-0081569) ofMEST/KOSEF and by the Ministry of Education, Scienceand Technology under the BK21 Project. ICT at SeoulNational University provided research facilities for thisstudy. A preliminary version of this paper appeared in theproceedings of the 2006 International Conference onCompilers, Architecture and Synthesis for EmbeddedSystems (CASES ’06).

REFERENCES

[1] “ARM Architecture Version 5 (ARMv5),” http://www.arm.com,1996.

[2] “ARM Architecture Version 6 (ARMv6),” http://www.arm.com,2002.

[3] “The Intel IXP Network Processor,” http://developer.intel.com/technology/itj/2002/volume06issue03/, 2002.

[4] “Intel XScale Architecture,” http://www.intel.com, 2002.[5] “Philips LPC3180 Microcontroller,” http://www.standardics.

philips.com/, 2006.[6] F. Angiolini, L. Benini, and A. Caprara, “Polynomial-time

Algorithm for On-Chip Scratchpad Memory Partitioning,” Proc.2003 Int’l Conf. Compilers, Architecture and Synthesis for EmbeddedSystems (CASES ’03), pp. 318-326, 2003.

[7] F. Angiolini, F. Menichelli, A. Ferrero, L. Benini, and M. Olivieri,“A Post-Compiler Approach to Scratchpad Mapping of Code,”Proc. 2004 Int’l Conf. Compilers, Architecture, and Synthesis forEmbedded Systems (CASES ’04), pp. 259-267, 2004.

[8] O. Avissar and R. Barua, “An Optimal Memory AllocationScheme for Scratchpad-Based Embedded Systems,” IEEE Trans.Embedded Computing Systems, vol. 1, no. 1, pp. 6-26, Nov. 2002.

[9] R. Banakar, S. Steinke, B.-S. Lee, M. Balakrishnan, and P.Marwedel, “Scratchpad Memory: A Design Alternative for CacheOn-Chip Memory in Embedded Systems,” Proc. 10th Int’l Symp.Hardware/Software Codesign (CODES), May 2002.

[10] B. Egger, J. Lee, and H. Shin, “Dynamic Scratchpad MemoryManagement for Code in Portable Systems with an MMU,” Trans.Embedded Computing Systems, vol. 7, no. 2, pp. 1-38, 2008.

[11] P. Francesco, P. Marchal, D. Atienza, L. Benini, F. Catthoor, andJ.M. Mendias, “An Integrated Hardware/Software Approach forRuntime Scratchpad Management,” Proc. 41st Ann. Conf. DesignAutomation (DAC ’04), pp. 238-243, 2004.

[12] M. Kandemir and A. Choudhary, “Compiler-Directed Scratch PadMemory Hierarchy Design and Management,” Proc. 39th Conf.Design Automation (DAC ’02), pp. 628-633, 2002.

[13] M. Kandemir, J. Ramanujam, M.J. Irwin, N. Vijaykrishnan, I.Kadayif, and A. Parikh, “Dynamic Management of Scratch-PadMemory Space,” Proc. 38th Conf. Design Automation (DAC ’01),pp. 690-695, 2001.

[14] S. Steinke, N. Grunwald, L. Wehmeyer, R. Banakar, M.Balakrishnan, and P. Marwedel, “Reducing Energy Consumptionby Dynamic Copying of Instructions Onto Onchip Memory,”Proc. 15th Int’l Symp. System Synthesis (ISSS ’02), pp. 213-218, 2002.

[15] S. Steinke, L. Wehmeyer, B.-S. Lee, and P. Marwedel, “AssigningProgram and Data Objects to Scratchpad for Energy Reduction,”Proc. Conf. Design, Automation and Test in Europe (DATE ’02),p. 409, 2002.

[16] S. Udayakumaran and R. Barua, “Compiler-Decided DynamicMemory Allocation for Scratch-Pad Based Embedded Systems,”Proc. 2003 Int’l Conf. Compilers, Architecture and Synthesis forEmbedded Systems (CASES ’03), pp. 276-286, 2003.

[17] M. Verma, L. Wehmeyer, and P. Marwedel, “Cache-AwareScratchpad Allocation Algorithm,” Proc. Int’l Conf. Design, Auto-mation and Test in Europe (DATE), Feb. 2004.

[18] M. Verma, L. Wehmeyer, and P. Marwedel, “Dynamic Overlay ofScratchpad Memory for Energy Minimization,” Proc. Int’l Conf.Hardware/Software Codesign and System Synthesis, Sept. 2004.

[19] A. Janapsatya, A. Ignjatovic, and S. Parameswaran, “A NovelInstruction Scratchpad Memory Optimization Method Based onConcomitance Metric,” Proc. 2006 Conf. Asia South Pacific DesignAutomation (ASP-DAC ’06), pp. 612-617, 2006.

[20] R. Muth, S. Debray, S. Watterson, and K.D. Bosschere, “Alto : ALink-Time Optimizer for the Compaq Alpha,” Software Practiceand Experience, vol. 31, pp. 67-101, 2001.

[21] A. Gordon-Ross, S. Cotterell, and F. Vahid, “Exploiting FixedPrograms in Embedded Systems: A Loop Cache Example,” Proc.IEEE Computer Architecture Letters, Jan. 2002.

[22] L.H. Lee, B. Moyer, and J. Arends, “Instruction Fetch EnergyReduction Using Loop Caches for Embedded Applications withSmall Tight Loops,” Proc. 1999 Int’l Symp. Low Power Electronicsand Design (ISLPED ’99), pp. 267-269, Feb. 1999.

[23] J. Lee, J. Kim, C. Jang, S. Kim, B. Egger, K. Kim, and S. Han,“Facsim: A Fast and Cycle-Accurate Architecture Simulator forEmbedded Systems,” Proc. 2008 ACM SIGPLAN/SIGBED Conf.Languages, Compilers and Tool Support for Embedded Systems(LCTES), June 2008.

[24] “Seoul National University Advanced Compiler Tool Kit,” http://aces.snu.ac.kr/snack.html, 2004.

[25] ARM, “ARM Ltd.,” http://www.arm.com, 2010.[26] T.H. Cormen, C.E. Leiserson, and R.L. Rivest, Introduction to

Algorithms. The MIT Press, 1990.[27] M.R. Guthaus, J.S. Ringenberg, D. Ernst, T.M. Austin, T. Mudge,

and R.B. Brown, “Mibench: A Free, Commercially RepresentativeEmbedded Benchmark Suite,” Proc. Fourth Ann. Workshop Work-load Characterization, Dec. 1998.

[28] C. Lee, M. Potkonjak, and W.H. Mangione-Smith, “Mediabench: ATool for Evaluating and Synthesizing Multimedia and Commu-nications Systems,” Proc. Int’l Symp. Microarchitecture, pp. 330-335,1997.

[29] T.E.M.B. Consortium, “EEMBC Benchmark,” http://www.eembc.org, 2008.

[30] “MP3 Reference Decoder,” http://www.mp3-tech.org/programmer/sources/dist10.tgz, 1996.

[31] “H.264 Video Codec,” http://www.itu.int/rec/T-REC-H.264,2003.

[32] “Pretty Good Privacy (PGPi),” http://www.pgpi.org/, 2002.[33] Micron Technology, Inc., “Mobile SDRAM Power Calc 10,”

http://www.micron.com/systemcalc, 2004.[34] Samsung Semiconductor, “K4X51163PC Mobile DDR SRAM,”

http://www.samsung.com/products/semiconductor/MobileSDRAM/, 2005.

[35] S. Wilton and N. Jouppi, “CACTI: An Enhanced Cache Access andCycle Time Model,” IEEE J. Solid State Circuits, vol. 31, no. 5,pp. 677-688, May 1996.

[36] “ARM926EJ-S Jazelle-Enhanced Macrocell,” http://www.arm.com/products/CPUs/ARM926EJ-S.html, 2001.

[37] “ARM1136JF-S Processor,” http://www.arm.com/products/CPUs/ARM1136JF-S.html, 2002.

[38] Micron Technology, Inc, “MT48H8M16LF Mobile SDRAM,”http://www.micron.com/products/dram/mobilesdram/, 2003.

[39] A. Shrivastava, I. Issenin, and N. Dutt, “Compilation Techniquesfor Energy Reduction in Horizontally Partitioned Cache Archi-tectures,” Proc. 2005 Int’l Conf. Compilers, Architectures andSynthesis for Embedded Systems (CASES ’05), pp. 90-96, 2005.

[40] R. Cytron and P.G. Loewner, “An Automatic Overlay Generator,”IBM J. Research and Development, vol. 30, no. 6, pp. 603-608, 1986.

[41] A. Silberschatz, P. Galvin, and G. Gagne, Applied Operating SystemConcepts. John Wiley and Sons, Inc., 2003.

[42] P.R. Panda, N.D. Dutt, and A. Nicolau, Memory Issues in EmbeddedSystems-on-Chip: Optimizations and Exploration. Kluwer AcademicPublishers, 1999.


Bernhard Egger received the MS degree incomputer science from the Swiss Federal In-stitute of Technology (ETH Zurich) in 2001, andthe PhD degree in computer science from SeoulNational University (SNU) in 2007. He is now withthe Samsung Advanced Institute of Technology(SAIT), Samsung Electronics’ central R&D cen-ter. His research interests include programminglanguages, compilers, operating systems, andarchitectures. He is a member of the IEEE.

Seungkyun Kim received the BS degree incomputer science and engineering from SeoulNational University, Korea, in 2005. He iscurrently working toward the PhD degree incomputer science and engineering at SeoulNational University. His research interests in-clude compiler postpass optimization and de-bugging technique for muticores. He is a studentmember of the IEEE.

Choonki Jang received the BS degree incomputer science and engineering from SeoulNational University, Seoul, Korea, in 2003, andis currently working toward the PhD degree incomputer science and engineering at SeoulNational University. His research interests in-clude compilers and explicitly managed memorysystems. More information can be found athttp://aces.snu.ac.kr/.

Jaejin Lee received the BS degree in physicsfrom SNU in 1991, the MS degree in computerscience from Stanford University in 1995, andthe PhD degree in computer science from theUniversity of Illinois at Urbana-Champaign(UIUC) in 1999. His PhD study was supportedin part by graduate fellowships from IBM andKorea Foundation for Advanced Studies. Afterobtaining the PhD degree, he spent a half yearat the UIUC as a visiting lecturer and post-

doctoral research associate. He is the director of the Center forManycore Programming and an associate professor in the School ofComputer Science and Engineering at Seoul National University(SNU). He was an assistant professor in the Department of ComputerScience and Engineering at Michigan State University from January2000 to August 2002 before joining SNU. His research interestsinclude compilers, architectures, parallel processing, and embeddedsystems. He is a member of the IEEE. More information can be foundat http://aces.snu.ac.kr.

Sang Lyul Min received the BS and MSdegrees in computer engineering from SeoulNational University, Seoul, in 1983 and 1985,respectively, and the PhD degree in computerscience from the University of Washington,Seattle, in 1989. He is currently a professor inthe School of Computer Science and Engineer-ing, Seoul National University, Seoul. He hasserved on a number of program committees oftechnical conferences and workshops, including

the International Conference on Embedded Software (EMSOFT), theReal-Time Systems Symposium (RTSS), and the Real-Time Technol-ogy and Applications Symposium (RTAS). He was also a member of theeditorial board of the IEEE Transactions on Computers. His researchinterests include embedded systems, computer architecture, real-timecomputing, and parallel processing. He is a member of the IEEE.

Heonshik Shin received the BS degree inapplied physics from Seoul National University,Korea, in 1973. Since he received the PhDdegree in computer engineering from the Uni-versity of Texas at Austin in 1985, he hasactively involved himself in researches of var-ious topics, ranging from real-time computingand distributed computing to mobile systemsand software. He is currently a professor of theSchool of Computer Science and Engineering at

Seoul National University. He is a member of the IEEE.

. For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.


ieee transactions on computers, vol. 59, no. 8, august ... · it classifies the code of the...

Documents