Will the IAR ICC430 compiler/linker etc overlay variables?

I have some significant RAM buffers that are not used simulataneously 
and their contents do not need to be preserved across function calls.

Some decent compilers I have used would overlay such variables 
(unless I told it otherwise).  I can't seem to get the IAR system to 
does such a thing.  Is it just me or is this toolset pretty limited?

Thanks,
Ian

> Some decent compilers I have used would overlay such variables 
> (unless I told it otherwise).  I can't seem
to get the IAR system 
to 
> does such a thing.  Is it just me or is this
toolset pretty limited?

Yes, IAR is limited in this and other respects.  But may I suggest 
use of a C "union" might to accomplish this?

JJS

Hi Ian!

> Will the IAR ICC430 compiler/linker etc overlay
variables?
>
> I have some significant RAM buffers that are not used simulataneously
> and their contents do not need to be preserved across function calls.
>
> Some decent compilers I have used would overlay such variables
> (unless I told it otherwise).  I can't seem to get the IAR system to
> does such a thing.

I haven't heard of any compiler that does such analysis with global
variables.  Some compilers (including some of ours) do perform a so
called static overlay analysis on local variables and places them on
absolute locations.  This is useful for architectures that have no or
very limited stack capabilities.


Oh well, over to the problem at hand.

The way I see it you can approach this problem i two different ways.
The first is to declare your variables inside a union.  The second is
to perform some linker tricks.


* The union way.

In C (as you probably are aware of) elements inside a union share the
same storeage.  So if you have two buffers you could define them as
follows:

  union
  {
    char buf1[100];
    int  buf2[50];
  } bufs;

Then in your code you could access them by using "bufs.buf1[...]".

Some compilers on the market (ours, for example, as of V2) also
support someting called "anonymous unions".  This is a union without a
name -- the advantage is that you can refer to the members without the
"bufs."  part.  You will gain no code advantages, but it is more
convenient if your program already contains references to "buf1" etc.

For example:

  union
  {
    char buf1[100];
    int  buf2[50];
  };

  int test()
  {
     return buf1[20];
  }


* The linker way

Our linker, XLink, can -- with come mild violence -- place segments
(but not individual variables) on the same location.

I will use an example to exmplain this; assume that you have declared
your buffers like:

__no_init char buf1[100] @ "BUF1";
__no_init int  buf2[50]  @ "BUF2";

Then you can force place then at a location using the "-Z@" option:

-Z@(DATA)BUF1p00
-Z@(DATA)BUF2p00

This, unfortunately, raises error "e24" since the two blocks were
placed at the same location.  This is a soft error, so all we need to
to do is to drop this to a warning:

-we24=w

or disable it:

-we24


> Is it just me or is this toolset pretty limited?

No comment ;-)


> Thanks,
> Ian

You're welcome,
    Anders Lindgren, IAR Systems

-- 
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

I can think of a third way, that I have used on occasion (for global 
variables).

Let's say you have a working area, like an array of structures.  
Then, you need to do something like build a big message stream or 
buffer and send it off, and you know the array-of-structures-area is 
not in use at that particular time.

Take a pointer and cast it to the start of the work area, or pass the 
casted address to the function that needs to do the job.  Any code 
that uses the pointer doesn't know (or care) that it is really the 
array of structures.

It implicitly does the same as the union, but all the down-stream 
code doesn't need to "know" it is a union and use the union
syntax.  
I guess it boils down to the "anonymous union" that Anders described.

Lee

--- In msp430@msp4..., Anders Lindgren <andersl@i...> wrote:
> 
> Hi Ian!
> 
> > Will the IAR ICC430 compiler/linker etc overlay variables?
> >
> > I have some significant RAM buffers that are not used 
simulataneously
> > and their contents do not need to be
preserved across function 
calls.
> >
> > Some decent compilers I have used would overlay such variables
> > (unless I told it otherwise).  I can't seem to get the IAR system

to
> > does such a thing.
> 
> I haven't heard of any compiler that does such analysis with global
> variables.  Some compilers (including some of ours) do perform a so
> called static overlay analysis on local variables and places them on
> absolute locations.  This is useful for architectures that have no 
or
> very limited stack capabilities.
> 
> 
> Oh well, over to the problem at hand.
> 
> The way I see it you can approach this problem i two different ways.
> The first is to declare your variables inside a union.  The second 
is
> to perform some linker tricks.
> 
> 
> * The union way.
> 
> In C (as you probably are aware of) elements inside a union share 
the
> same storeage.  So if you have two buffers you
could define them as
> follows:
> 
>   union
>   {
>     char buf1[100];
>     int  buf2[50];
>   } bufs;
> 
> Then in your code you could access them by using
"bufs.buf1[...]".
> 
> Some compilers on the market (ours, for example, as of V2) also
> support someting called "anonymous unions".  This is a union 
without a
> name -- the advantage is that you can refer to the
members without 
the
> "bufs."  part.  You will gain no code
advantages, but it is more
> convenient if your program already contains references to "buf1" 
etc.
> 
> For example:
> 
>   union
>   {
>     char buf1[100];
>     int  buf2[50];
>   };
> 
>   int test()
>   {
>      return buf1[20];
>   }
> 
> 
> * The linker way
> 
> Our linker, XLink, can -- with come mild violence -- place segments
> (but not individual variables) on the same location.
> 
> I will use an example to exmplain this; assume that you have 
declared
> your buffers like:
> 
> __no_init char buf1[100] @ "BUF1";
> __no_init int  buf2[50]  @ "BUF2";
> 
> Then you can force place then at a location using the "-Z@"
option:
> 
> -Z@(DATA)BUF1p00
> -Z@(DATA)BUF2p00
> 
> This, unfortunately, raises error "e24" since the two blocks were
> placed at the same location.  This is a soft error, so all we need 
to
> to do is to drop this to a warning:
> 
> -we24=w
> 
> or disable it:
> 
> -we24
> 
> 
> > Is it just me or is this toolset pretty limited?
> 
> No comment ;-)
> 
> 
> > Thanks,
> > Ian
> 
> You're welcome,
>     Anders Lindgren, IAR Systems
> 
> -- 
> Disclaimer: Opinions expressed in this posting are strictly my own 
and
> not necessarily those of my employer.