Re: [ECOS] code optimizations

[Grant Edwards <grante at visi dot com>]

On Thu, Aug 23, 2001 at 11:34:48AM -0700, Dan Conti wrote:

> > It's mostly a philosphical thing I have stuck in my head about
> > at what stage in the build addresses get assigned.  I think
> > that should happen at the link stage. If you assign addresses
> > to peripherals in the linker file (where the reset of the
> > memory addresses are defined), then all of the memory layout is
> > defined in a single place.  I've always thought that a nice
> > thing.
> 
> That's an interesting thought. We actually have a lot of revs of similar
> hardware layouts here, and up wrestling with this problem. Putting
> memory locations in the linker file would simplify base address changes,
> but what about register offsets? We've had situations where on one
> board, the address leads are flat, and on another, A0 on the peripheral
> is tied to A5 on the processor, so now all the registers are at
> different offsets. It seems like this could snowball to the point of
> having huge amounts of information in your linker file.

That's a problem.  It only helps in situations where only the
base address changes.

> By the way, there's another slight benefit to your method in terms of
> performance. Chances are when you're talking to a peripheral it wont
> matter, but on some of the boards i've worked with (which have 0 wait
> state peripherals but 4 wait state ram), the extra load for the pointer
> in the case of:
> 
> #define foo 0x7ffe1110
> 
> *(volatile unsigned int*)foo = 0xabc;
> 
> can be painful. :)

It depends on the architecture.  For some, derefrencing the
pointer is more expensive, for others it isn't. ARM, for
example can't fit a complete direct address in an instruction,
so all external references end up being equivalent to
dereferencing a pointer that was statically initialized.

-- 
Grant Edwards
grante@visi.com