Re: Program Partitioning for embedded systems.

Hi,


I remember having read on these topics long back. I feel you might not
be able to get away with overlays completely, so you might fine tune
your application in such a way that main will always anyhow be in the
memory always, but other fns called by main are small enough to fit
into an overlay, you might need to check the m/c code to do this. But
yes this might be a tough job to do and further considering the fact
that if a fn in one overlay calls another fn in a different overlay
and if this happens most of the times then most of the time would be
spent in loading itself. so you need careful planning to do this.


          Second alternative might be to simulate paging in software. I
agree its not that cost effective as hardware support in
paging. anyhow as you asked for some links, here is a good link where
you can get lots of research articles on various comp sci related
topics. Just need to get a keyword and search.


http://citeseer.nj.nec.com/cs


Regs,
-madhusudan


Bageshri Sathe wrote:
> I am working on a problem of partitioning the executable code for a
> limited memory embedded system (non-parallel) which has neither an OS
> nor any paging hardware. There are separate memories for code and
> data. A large function may not fit in the code memory, so overlays
> cannot be used.
>
> We are trying to partition the executable code in order to achieve
> following:
>
> (1) Each partition should fit in the available memory.
>
> (2) Number of DMA calls (which are required to load new code in the
> memory) are minimized. (Eg. avoiding partition boundaries to fall
> within a loop if the loop entirely fits in the memory.)
>
> (3) Number of data loads (corresponding to code loads) are minimized.
>
> I would like to find out if any research has been done or is being
> done on this. If any one knows about work done in this direction,
> please give me some pointers.
>
> Regards,
> Bageshri.
> [I told him that the usual way to solve this problem is to rewrite the
> code into functions small enough to overlay, and then overlay them,
> but he'd like something more automated. Sounds like a difficult and
> interesting problem. -John]


--
-madhusudan


Ericsson Inc
work :- 805-562-6066

Return to the comp.compilers page.
Search the comp.compilers archives again.