This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: code optimizations


> -----Original Message-----
> From: Grant Edwards [mailto:grante@visi.com]
> Subject: Re: [ECOS] code optimizations
> 
> 
> On Thu, Aug 23, 2001 at 10:08:03AM -0600, Gary Thomas wrote:
> 
> > Why?  I don't see any advantage - in fact there could be major
> > code generation/optimization disadvantages.  Having the actual
> > addresses in header files (the eCos custom) also provides an
> > additional level of documentation, however bleak.
> 
> I agree that it's easier for most people to find the addresses
> when they're in a header file.
> 
> 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.

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. :)

-Dan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]