Source Code (C) Phantom Support Sytem Generic Front-End Compiler BB CFG Code Generation ANSI C Single-threaded Application Phantom Call Identifier AEB

Transcription

1 Code Partitioning for Synthei of Embedded Application with Phantom André C. Nácul, Tony Givargi Department of Computer Science Univerity of California, Irvine {nacul, ABSTRACT In a large cla of embedded ytem, dynamic multitaking uing traditional OS technique i infeaible becaue of memory and proceing overhead or lack of operating ytem availability for the target embedded proceor. Serializing compiler have been propoed a an alternative olution, enabling a deigner to develop multitaking application without the need of OS upport. A erializing compiler i a ource-to-ource tranlator that take a POSIX compliant multitaking C program a input and generate an equivalent, embedded proceor independent, inglethreaded ANSI C program, to be compiled uing the embedded proceor-pecific tool chain. Such erializing compiler work by partitioning each tak into block of code and yntheizing a cheduler that dynamically witche among thee block. The quality of the compiled code in term of multitaking overhead and tak latency i highly dependent on the partitioning algorithm. In thi work, we give our olution to the partitioning problem in the context of erializing compiler. We how that it i poible to provide the deigner with a et of Pareto-Optimal olution that trade off multitaking overhead for tak latency. Keyword Dynamic Multitaking, Code Generation, Scheduling, Serializing Compiler, Software Synthei. INTRODUCTION Embedded oftware continue to play an ever increaing role in the deign of complex embedded application. In part, the elevated level of abtraction provided by a highlevel programming paradigm immenely facilitate a hort deign cycle, fewer deign error, deign portability, and Intellectual Property (IP) reue. In particular, the concurrent programming paradigm i an ideal model of computation for deign of embedded ytem, which often encompa inherent concurrency. On the other hand, embedded ytem often have tringent performance requirement (e.g., timing, energy, etc.) and, conequently, require a carefully elected and performance tuned embedded proceor to meet pecified deign contraint. In recent year, a plethora of highly cutomized embedded proceor have become available. A an example, Tenilica [] provide a large family of highly cutomized application-pecific embedded proceor, the Xtena. Likewie, ARM [] and MIPS [] provide everal derivative of their repective core proceor, in an effort to provide to ---//$. IEEE. their cutomer an application-pecific olution. Such embedded proceor hip with cro-compiler and the aociated tool chain for application development. However, to upport a multitaking application development environment, there i a need for an operating ytem (OS) layer that can upport tak creation, tak ynchronization, and tak communication. Such OS upport i eldom available for each and every variant of the bae embedded proceor. In part, thi i due to the lack of ytem memory and/or ufficient proceor performance (e.g., in the cae of micro-controller uch a the Microchip PIC [] and the Phillip []) coupled with the high performance penalty of having a full-fledged OS. Additionally, manually porting and verifying an OS to every embedded proceor available i a high-cot job, in term of time and money, and yet doe not guarantee correctne. To fill the gap in realizing a multitaking application targeted at a particular embedded proceor, we have propoed Phantom. Phantom provide a fully automated ource-toource tranlator, taking a multitaking C program a input and generating an equivalent, embedded proceor independent, ingle-threaded ANSI C program, to be compiled uing the embedded proceor-pecific tool chain. The output of Phantom i a highly tuned, correct (i.e., by contruction) ANSI C program that embodie the application-pecific embedded cheduler and dynamic multitaking infratructure along with the uer code. One important iue in code generation with Phantom i that of code partitioning. In order to implement multitaking with a ingle-threaded ANSI C code, Phantom make ue of compile time information, and partition the code into non-preemptive unit of execution, which are call atomic execution block (AEB). Some of thee partition are mandatory to maintain the correct execution of the application, uch a thoe implied by ynchronization point. Other are not mandatory, but directly affect repone time, latency, and the multitaking overhead. In thi paper, we pecifically addre the partitioning iue in Phantom, dicuing the impact of partitioning on the final generated code, metric to meaure the quality of different partition, and algorithm to explore the different poible partition. A for related work, we can identify three different approache that addre ome of the iue olved with Phantom, namely a Virtual Machine (VM) baed technique, template-baed OS generation technique, and tatic cheduling technique. In the VM approach, portability i achieved, but with the overhead impoed by the VM layer. Moreover, the VM ha to be ported to each new platform.

2 Source Code (C) Phantom Support Sytem Generic Front-End Compiler BB CFG Code Generation ANSI C Single-threaded Application Phantom Call Identifier AEB Graph Partitioning Module Live Variable Analyi Figure : Phantom Compiler Architecture typedef truct { int id; pthread_mutex_t *lock; pthread_mutex_t *unlock; game_t; int winner; void *game(void *arg) { /* THREAD */ game_t g = (game_t *)arg; int num; while() { pthread_mutex_lock(g->lock); if(winner) { return NULL; ele { num = rand(); if(num == g->id) winner = g->id; int main(int argc, char **argv) { pthread_t t, t; int r; truct game_t g, g; pthread_mutex_t m, m; pthread_mutex_init(&m, NULL); pthread_mutex_lock(&m); pthread_mutex_init(&m, NULL); pthread_mutex_lock(&m); g.id = ; g.id = ; g.lock = g.unlock = &m; g.lock = g.unlock = &m; winner = ; pthread_create(&t, NULL, game, &g); pthread_create(&t, NULL, game, &g); pthread_mutex_unlock(&m); pthread_join(t, NULL); pthread_join(t, NULL); printf("winner i %d\n", winner); To improve on thee, olution like JIT[] and cutomized VM for embedded platform[] have been propoed. In the template baed OS generation, a cutom OS i generated from a generic library of template [][][]. However, no ingle generic OS template can be ued in the variety of embedded proceor available. Finally, the tatic cheduling technique [][][] olve the tatic, a priori known, tak cla of problem, without addreing the dynamic multitaking iue. Phantom i a new approach in addreing the challenge of multitaking upport for embedded application. We are unaware of any work that addree the partitioning problem a tated in thi work. The remainder of thi work i organized a follow. In Section, we briefly decribe Phantom, the ource to ource tranlator. In ection, we dicu the partitioning iue related to code generation with Phantom. In Section, we how experimental reult. Finally, in Section, we tate our concluion.. THE PHANTOM APPROACH Figure : Code Example partitioning module to refine the partition until acceptable preemption, timing, and latency are achieved. The reulting AEB graph are then paed to the code generator to output the correponding ANSI C code for each AEB node. In addition, the embedded cheduler, along with other C data tructure and ynchronization API are included from the Phantom ytem upport library, reulting in the final ANSI C ingle-threaded code. In the current verion, Phantom i able to handle oft, firm, and event-driven real-time application. All the module pictured in Figure are implemented and can be ued in the automatic code generation proce. Next, we briefly preent the major component of Phantom. Throughout the next ection, we will be referring to our running example hown in Figure. Our running example implement a imple game between two tak that are picking up random number until one of them pick it own id, making it the winner of the game.. Introduction Input to Phantom i a multitaking program P input, written in C. The multitaking i upported through the native Phantom API, which complie with the tandard POSIX interface[]. Thee primitive provide function for tak creation and management (e.g., tak create, tak join, etc.) a well a a et of ynchronization variable (e.g., mutex t, ema t, etc.). Output of Phantom i a ingle-threaded trict ANSI C program P output that i equivalent in function to P input. More pecifically, P output doe not require any OS upport and can be compiled by any ANSI C compiler into a elf ufficient binary for a target embedded proceor. Figure i the block diagram of Phantom. The multitaking C application i compiled with a generic front-end compiler to obtain the baic block (BB) control flow graph (CFG) repreentation. Thi intermediate BB repreentation i annotated, identifying Phantom primitive. The reulting tructure i ued by a partitioning module to generate nonpreemptive block of code, which are called atomic execution block AEB, to be executed by the cheduler. Every tak in the original code i partitioned into many AEB, generating an AEB Graph. Then, a live variable analyi i performed on the AEB graph and the reult i fed back to the. Preemption and Scheduling Since the output of Phantom i a ingle-threaded program, there i a need for a context witching mechanim and a baic unit of execution in order to achieve multitaking. A mentioned earlier, we define the baic unit of execution, cheduled by the cheduler, an atomic execution block (AEB). An AEB i a block of code that i executed in it entirety prior to cheduling the next AEB. A tak T i i partitioned into an AEB graph whoe node are AEB and edge repreent control flow. For example, Figure picture the CFG tranformation for the function game of our running example. Figure (a) how the output of the compiler front-end that i fed to the partitioning module. The partitioner add two control baic block, etup and cleanup, a hown in Figure (b), and ubequently divide the code into a number of AEB, a hown in Figure (c). Figure (c) how the AEB graph of function game a being compoed of AEB aeb, aeb, aeb, aeb, aeb and aeb. Within an AEB graph, each node i implemented a an ANSI C function with no return value. For intance, aeb implementation i hown in Figure (function game aeb). The termination of an AEB function tranfer the control back to the cheduler (Figure, function

3 (a) Partitioner Step I (b) Partitioner Step II aeb_ aeb_ aeb_ aeb_ (c) aeb_ aeb_ void game(void *arg, void **ret_val) { // allocate and etup frame frame = malloc(...); frame->arg = arg; // ave the ret_val in the frame frame->ret = ret_val; // etup next aeb curr_thr->next_aeb = game_aeb; puh(curr_thr->frame, frame); void game_aeb(void) { int num; // retore local from frame frame = top(current->frame); game_t g = frame->g; if(!winner) goto bb_; curr_thr->next_aeb = game_aeb; goto exit; bb_: num = rand(); if(num!= g->id) goto bb_; winner = g->id; bb_: curr_thr->next_aeb = game_aeb; exit: void game_aeb(void) { // clean up frame tructure frame = pop(current->frame); free(frame); typedef truct { int id; tatu_t tatu; tak_info_t info; tack_t heap; join_info_t join_info; aeb_t next_aeb; void *ret; tak_t; tak_t *curr_thr; tatic queue_t tak; tatic void phantom_cheduler() { while(queue_ize(&tak) > ) { curr_thr = queue_pop(&tak); if(curr_thr->next_aeb!= ) { curr_thr->next_aeb(); if(curr_thr->tatu == RUNNABLE) queue_puh(&tak, curr_thr); ele terminate_tak(curr_thr->ret); void game_aeb(void) { // retore local from frame frame = top(current->frame); game_t g = frame->g; if(){ curr_thr->next_aeb = game_aeb; pthread_mutex_lock(g->lock); Figure : CFG Tranformation for Function game Figure : Excerpt of the Generated Code phantom cheduler). The cheduler, then, ha a chance to activate the next AEB, from either the ame tak or from another tak that i ready to run. It may happen that a function in the original input code i partitioned into more than one AEB, each one of them being implemented a a eparate ANSI C function. In that cae, there i a need for a mechanim to ave the variable that are live on tranition from one AEB to the other, o that the tranfer of one AEB to another i tranparent to the tak code. Phantom olve thi iue by toring the value of local variable of the original C function in a tructure inide the tak context, emulating the concept of a function frame. The frame i initialized in the firt AEB of a given function (i.e., etup), and cleaned up in the lat AEB of the ame function (i.e., cleanup). Thee operation are included by the partitioner for every function that need to be phantomized, i.e., divided into AEB. They are repreented by the dark node in Figure (b). For an example of the generated ANSI C code, refer to Figure, function game, for etup, and game aeb, for cleanup. During runtime, there i a need to maintain, among other, a pointer to the next AEB node that i to be executed in the future, called next aeb, in the context information for each tak that ha been created (Figure, tructure tak t). When a tak i created, the context i allocated, the next aeb field i initialized to the entry AEB of the tak, and the tak context i puhed onto a queue of exiting tak, called tak, to be proceed by the embedded cheduler. The embedded cheduler i reponible for electing and executing the next tak, by calling the correponding AEB function of the tak to be executed. The next aeb pointer of a tak T i i ued to reume the execution of T i by making a function call to the function correponding to the next AEB of T i. At termination, every AEB update the next aeb of the currently running tak to point to the ucceor AEB according to the tak AEB Graph. A zeroed next aeb indicate that T i ha reached it termination point, and thu i removed from the queue of exiting tak. The cheduling algorithm in Phantom i a priority baed cheme, a defined by POSIX. The way prioritie are aigned to tak, a they are created, can enforce alternate cheduling cheme, uch a round-robin, in the cae of all tak having equal priority, or earliet deadline firt (EDF), in the cae of tak having priority equal to the invere of their deadline, priority inverion, and o on. Additionally, prioritie can alo be changed at run-time, o that cheduling algorithm baed on dynamic prioritie can be implemented.. Synchronization Phantom implement the baic emaphore (ema t in POSIX) ynchronization primitive, upon which any other ynchronization contruct can be built. A emaphore i an integer variable with two operation, wait and ignal (ema wait and ema pot in POSIX). A tak T i calling wait on a emaphore S will be blocked if the S integer value i zero. Otherwie, S integer value i decremented and T i i allowed to continue. T i calling ignal on S will increment S integer value and unblock one tak that i currently blocked waiting on S. To implement emaphore, there i a need to add to a tak T i context an additional field called tatu. Statu i one of blocked or runnable and i et appropriately when a tak i blocked waiting on a emaphore. A emaphore operation, a well a a tak creation and joining, i what i called a ynchronization point. Synchronization point are identified by a gray node in Figure. At every ynchronization point a modification in the tate of at leat one tak in the ytem might happen. Either the current tak i blocked, if a emaphore i not available, or a higher priority tak i releaed on a emaphore ignal, for example. Therefore, a function i alway partitioned into AEB when ynchronization point are encountered, and a call to a ynchronization function i alway the lat tatement in it AEB. The cheduler mut regain control and remove the current tak from execution in cae it became

4 blocked or i preempted by a higher priority tak. Right before any ynchronization, an AEB will et the tak next aeb to the ucceor AEB according to the AEB Graph. If the tak i not blocked at the ynchronization, it will continue and the next aeb will be executed next. Otherwie, the next aeb will be potponed, and it will be executed a oon a the tak i releaed on the ynchronization point.. Interrupt Preempting an AEB when an interrupt occur would break the principle that every AEB execute until completion without preemption. Intead, in Phantom, the code for an interrupt ervice routine I i treated a a tak, with it aociated AEB. On an interrupt detined for I, a correponding tak i created, having a priority higher than all exiting tak. Note that if multiple interrupt detined for I occur, multiple tak will be created and cheduled for execution. Thi i a uniform and powerful mechanim for handling interrupt in a multitaking environment. However, the latency for handling the interrupt will depend on the average execution time of the AEB, which in turn depend on the partitioning cheme ued.. Experiment with Phantom The Phantom approach ha been uccefully applied to a number of application developed for teting the tranlation flow. In ummary, Phantom outperform tandard POSIX implementation, being to time fater in execution time. On the average, multitaking with Phantom achieve a peed-up of., with a maximum of.. In general, multitaking application yntheized with Phantom how a much improved performance (i.e., low operating overhead). The reaon i two fold. Firt, the generated application encompa a highly tuned multitaking framework that meet the application-pecific need. Second, the multitaking infratructure itelf i very compact and efficient, reulting in a much lighter overhead for context witching, tak creation, and ynchronization.. PARTITIONING A decribed earlier, the partitioning of the code into AEB graph i the key to implementing multitaking at a highlevel of abtraction. Recall that boundarie of AEB repreent the point where tak might be preempted or reumed for execution. Some partition are unavoidable and mut be performed for correctne, pecifically, when a tak invoke a ynchronization operation, or when a tak create another tak. In the cae when a tak invoke a ynchronization operation and thu i blocked, the embedded cheduler mut regain and tranfer control to one of the runnable tak. Likewie, when a tak create another, poibly higher priority tak, the embedded cheduler mut regain and poibly tranfer control to the new tak in accordance with the priority baed cheduling cheme. Additionally, the programmer can pecify point in the code where a context witch hould happen by calling the yield function of the Phantom API. Any original multitaking C program i compoed of a et of function (or routine). In Phantom, and for correctne, all function that are the entry point of a tak need to be partittioned. In addition, and for correctne, any function that invoke a ynchronization primitive alo need to be partitioned. We call the proce of partitioning function into AEB phantomization. Finally, and for correctne, a function that call a phantomized function alo need to be phantomized. However, partitioning beyond what i needed for correctne impact timing iue a decribed next. In general, partitioning will determine the granularity level of the cheduling (i.e., the time quantum), a well a the tak latency. A good partitioning of the tak into AEB would be one where all AEB have approximately the ame average cae execution time µ and a relatively low deviation δ from the average, which can be computed if the average cae execution time of each AEB i known. In thi cae, the application would have a very predictable and table behavior in term of timing. The range of partitioning granularitie i marked by two cenario. On one end of the pectrum, partitioning i performed only for correctne, and yield cooperative multitaking. On the other end of the pectrum, every baic block i placed in it own partition, reulting in a preemptive multitaking with extremely low latency, but high overhead. Specifically, to evaluate a partition we can apply the following metric, average, minimum, and maximum latency; tandard deviation of latency; and context witch overhead. Clearly, to horten latency, there i need to context witch more often, and thu pay a penalty in term of overhead. In thi work, we explore the range of partitioning poibilitie. In the next ection, we define a trategy for clutering and an exploration framework for obtaining a et of Pareto- Optimal partition.. Strategy for Clutering The generic clutering algorithm ued to group baic block into partition that correpond to AEB i baed on two algorithm traditionally ued for data flow analyi by compiler, namely interval partitioning and interval graph []. The generic clutering algorithm take a input a CFG, and return a et of dijoint cluter, each cluter grouping one or more of the baic block of the original CFG. The generic clutering algorithm enure that a cluter of baic block ha a ingle entry point (i.e., the head of the cluter), but poibly multiple exit point. Thi requirement i neceary ince every cluter i implemented a an ANSI C function in Phantom. Our generic clutering technique i hown in Algorithm. Initially, for a given CFG and it entry baic block n, a et of cluter i computed, each containing one (reachable from n ) baic block of the CFG (line ). Subequently, pair of cluter c i, c j are merged if all of c j predeceor are in cluter c i. The predeceor of c j are all cluter containing one or more baic block() that are predeceor() of at leat one baic block in c j. The algorithm iterate until no more cluter can be merged. Note that if Algorithm were to run on a CFG it would cluter all the baic block into a ingle partition, a expected. Therefore, we introduce a mechanim to modify the input CFG uch that, uing Algorithm, we obtain a deired partitioning for correctne and timing. The mechanim i to modify the original CFG with two pecial empty baic block, ynch-mark and time-mark. Neither of thee marker baic block are reachable from the entry baic block n, and are, for that reaon, not a member of a cluter (line ). All point of partitioning that are required for correctne or timing will be pointed to by one of the marker prior to Cooperative multitaking i when tak explicitly yield to each other or are preempted by a ynchronization primitive.

5 Algorithm The Generic Clutering Algorithm : Input: cfg, n cfg the entry point of the CFG : Output: cluter c, c,..., c n : clut {c i b i b i cfg and reachable from n : changed : while changed = do : changed : for each c i, c j clut do : if every pred. of c j i in c i then : c new c i c j : clut (clut c i c j) {c new : changed : end if : end for : end while Source Code (C) Pareto- Optimal Partition Uer Intervention Contrain Cot Function Phantom Compiler Partitioning Explorer Partition Selection Generated Single-Threaded Code (C) Intrumented Single-Threaded Code Profiling Data Phantom Compiler Execute running Algorithm. Figure how, tep-by-tep, the working of the clutering algorithm. Figure (a) i the CFG for the function game, augmented with the etup and cleanup baic block, where gray node repreent thoe baic block with a ynchronization point. Figure (b) how the addition of the ynchmark baic block. Next, every reachable baic block b i of the CFG i aigned to cluter c i a hown in Figure (c). Then, by ucceive iteration, cluter are merged until the final partitioning i reached, a hown in Figure (c)-(f). The introduction of the ynch-mark block i taken care of by the Phantom compiler. The introduction of the timemark i performed by the exploration framework, to be decribed later. In other word, the exploration of the different partition and the earch for the Pareto-Optimal et of tradeoff i a matter of determining the et of baic block that the time-mark point to.. Exploration Framework Our overall exploration framework i pictured in Figure and work a follow. Initially, the multitaking application i proceed by the Phantom compiler, a hown in Figure, uing the cooperative partitioning cheme. Then, the generated code i intrumented with profiling intruction (i.e., baic block execution counter). Next, the intrumented code i executed and a trace containing profiling information i retrieved. Moreover, trace obtained from multiple run of the ame intrumented code but different input are merged to obtain a ingle repreentative trace (i.e., by averaging the baic block count). The trace i then proceed to extract performance number for each poible partition. A partition i defined in term of a et of edge from the time-mark baic block to the baic block of the original CFG. Thu, given a CFG with N baic block, there are an exponential number of way to introduce uch edge, hence there are an exponential number of poible partition. For each partition, and uing the profiling data, we can quickly compute all the evaluation metric. Our earch goal i to obtain a et of Pareto-Optimal partition that tradeoff latency, context witch overhead, and other metric. Our exploration technique employ a imple heuritic to obtain different cluter and i hown in Algorithm. For a CFG with N baic block, Algorithm attempt K random In a multi-objective optimization problem, a Pareto-Optimal et contain deign intance where each deign intance i guaranteed to be optimal with repect to at leat one objective. Figure : Clutering Exploration Methodology placement of,,... N edge from the time-mark to baic block of the CFG. The parameter K i an arbitrary number and depend on the amount of compute time available for exploration. Clearly, larger value for K are expected to yield a better approximation of the Pareto-Optimal et. Although imple, thi heuritic allow u to quickly reach a reaonably good number of partition and obtain a fairly good approximation of the Pareto-Optimal et. Algorithm The Search Heuritic : Input: cfg : Input: K {number of trie : Output: cfg, cfg,..., cfg n where n = cfg : N cfg {number of baic block in cfg : for i = to N do : for j = to K do : pick i random baic block in cfg : place an edge from time mark to baic block i : execute Algorithm and evaluate metric : end for : end for Once the Pareto-Optimal et i computed, there i the final proce of electing the bet cluter to meet the application contraint. To do thi, there are three different poibilitie. The firt i to have the deigner elect the deired partition by examining the Pareto-Optimal et. Another alternative i to apply a ingle contraint (e.g., pecifying either a minimum latency, or maximum overhead) and let the tool elect the partition that meet the contraint while optimizing the other metric. Finally, it i poible to define a cot function (e.g., a weighted um of the variou metric) to compute a unique goodne meaure for each point in the Pareto-Optimal et, allowing the tool to elect the partition with the minimum cot.. EXPERIMENTAL RESULTS Eight different application were implemented uing the Phantom POSIX interface, in order to tet the Phantom compiler and partitioner. The application benchmark ued in our experiment are decribed in Table. Our exploration methodology wa applied to all the application benchmark. Figure,,, and how the reulting Pareto-Optimal partition for the mot interet-

6 (a) (b) (c) (d) (e) (f) Figure : Execution of Clutering Algorithm Table : Application Benchmark Name Decription client erver Client-Server implementation of a calculator. Communication through hared memory. erver and client. conumer producer Claical conumer producer problem, conumer and producer. Buffer with entrie. dct Multitak implementation of x dct. One tak for each point in the reult matrix. deep tack Multiple recurive tak. Tet the cot of recurive function call in the Phantom ytem. matrix mul Multitak implementation of matrix multiplication. Reulting matrix i x element. One tak per element in the reult. quick ort Multitak implementation of the traditional orting algorithm. vm Multitak imulator for a imple proceor. watch Time-keeper application, ued to tet timing behavior of the generated code. ing cae. In thee figure, each point repreent a different partition, howing the latency and context-witch overhead of an epecific partitioning olution.the rightmot point in each graph i the cooperative chedule, while the leftmot point i the mot reponive cenario, where each AEB ha only one baic block. Overall, we oberve the trend of increaed overhead a latency i reduced (i.e., more partition are created). Furthermore, by uing different partitioning cheme, it i poible to modify latency by a much a two order of magnitude at the expene of an overhead increae by a factor of. Figure how the Pareto-Optimal partition for the function erver in the client erver benchmark. In thi example, there i a fairly regular behavior. The maximum and Table : Partitioning quick ort part min max avg td ctx w number latency latency latency deviation overhead the minimum partition differ by a factor of in latency, and by a factor of. in performance. The range of latencie i covered reaonably well by our partitioning methodology. A completely different picture i hown in Figure, the Pareto-Optimal partition for function fpixel in DCT. Here, latency range from a large intruction delay to a tiny intruction delay on the other extreme. The overhead alo change ignificantly, from a minimal number of context witche in one cae to a large overhead in the other. Moreover, it i poible to detect iland of partition a we break the code in different part. Figure and how yet different cenario a a reult of partitioning. Clearly, the trade off between latency and context witch overhead i variable with different application. Table detail the minimum, maximum, and average latency; tandard deviation; and context witching overhead for ome of the partition explored in the quick ort function. The table how that, for the larger partition, the average latency i high, but tandard deviation i alo high, due to the highly irregular ize of each cluter, while the overhead due to context witching i minimal. Then, a the clutering methodology explore different partition, one can ee that the latency and the tandard deviation are reduced ignificantly, reulting in a more uniform clutering.. CONCLUSIONS In thi work, we have preented our olution to the partitioning problem in the context of erializing compiler. A erializing compiler i a ource-to-ource tranlator that take

7 ClientServer-erver Exploration ConumerProducer-main Exploration Overhead (ctx witche) Overhead (ctx witche) Latency (intruction) Latency (intruction) Figure : Client Server - erver Figure : Conumer Producer - main dct-fpixel Exploration quick-ort Exploration Overhead (ctx witche) Overhead (ctx witche) Latency (intruction) Latency (intruction) Figure : DCT - fpixel Figure : Quick Sort - quick ort a POSIX compliant multitaking C program a input and generate an equivalent, embedded proceor independent, ingle-threaded ANSI C program, to be compiled uing the embedded proceor-pecific tool chain. Serializing compiler have been propoed a an alternative olution, enabling a deigner to develop multitaking application without the need of OS upport. We have hown that it i poible to provide the deigner with a et of Pareto-Optimal olution that tradeoff multitaking overhead, tak latency, and other metric when erializing compiler are ued. Our reult how that it i poible to reduce latency (from the cooperative multitaking cheme) by a much a two order of magnitude at the expene of an increae in the overhead by a factor of up to. Our future direction of reearch i to invetigate approache where the tak latency and multitaking overhead are balanced during execution time. In other word, we are intereted in introducing mechanim for context witching between multiple tak at arbitrary point (i.e., determined dynamically) during execution.. ACKNOWLEDGEMENTS Thi work wa upported by the National Science Foundation award number CCR- and by CAPES Foundation, Brazil, award number BEX/-.. REFERENCES [] A. Aho, R. Sethi, and J. Ullman. Compiler Principle, Technique and Tool. Addion-Weley, Reading, Maachuett,. [] ARM Inc. [] J. Aycock. A Brief Hitory of Jut-In-Time. ACM Computing Survey, ():, Jun.. [] J. Cortadella et. al. Tak Generation and Compile-Time Scheduling for Mixed Data-Control Embedded Software. In Proc. of DAC, Jun.. [] S. Edward. Tutorial: Compiling Concurrent Language for Sequential Proceor. ACM TODAES, ():, Apr.. [] L. Gauthier, S. Yoo, and A. Jerraya. Automatic Generation and Targeting of Application-Specific Operating Sytem and Embedded Sytem Software. IEEE TCAD, ():, Nov.. [] A. Gertlauer, H. Yu, and D. Gajki. RTOS Modeling for Sytem Level Deign. In Proc. of DATE, Mar.. [] B. Lin. Efficient Compilation of Proce-Baed Concurrent Program without Run-Time Scheduling. In Proc. of DATE, Feb.. [] Microchip Inc. [] MIPS Inc. [] Phillip Inc. [] POSIX Open Group. [] Tenilica Inc. [] S. Vercauteren, B. Lin, and H. D. Man. A Strategy for Real-Time Kernel Support in Application-Specific HW/SW Embedded Architecture. In Proc. of DAC, Jun.. [] V. Verdiere, S. Cro, C. Fabre, R. Guider, and S. Yovine. Speedup Prediction for Selective Compilation of Embedded Java Program. In Proc. of EMSOFT, Oct..