Re: [avr-chat] Missed Optimisation ?

[Michael Hennebry]

On Thu, 3 Mar 2011, Alex Eremeenkov wrote:

> 03.03.2011 18:40, Michael Hennebry writes:
> > On Thu, 3 Mar 2011, Alex Eremeenkov wrote:

> > > If you disagree here again,
> > > explain me how instruction below will determine in what actual memory 
> > > segment address mapped during execution,
> > > if we have CPU with memory mapping configuration(any modern ARM CPU for 
> > > example):
> > >
> > > lds    r10, 0xFF00025A
> >
> > Unless it's for an xmega, that is not an AVR instruction.
> > The address is too big.
> > Do xmegas have three-word instructions?
> >
> > An AVR's LDS instruction refers to either IO space,
> > internal SRAM or external memory.
> > It does not refer to either flash or EEPROM.
> > If the corresponding C refers to a named variable,
> > it does not refer to IO space.
> > If the processor cannot use external memory,
> > that leaves internal SRAM.
> The size of the instruction it not a discussion theme.
> And not an a answer for a question.
> You said that LDS didn't reffed to flash, and it's correct by AVR 
> architecture, but isn't mutually according features of tool-chain.

avr-gcc isn't obligated to produce code for anything that is not an AVR.

> You can simple deceit compiler and CPU by link flash segments to SRAM map, 
> and SRAM segments to flash map, and application will didn't work too.
> It's a compiler faults like initial claims?

That won't work regardless of optimization.

> > What other possibilities did you have in mind?
> It is possible to think up and realize set of variants where current

But you cannot do it yourself?

> optimization of avr-gcc will be correct,
> and code that 'needed' for you will fault, corrupt or made some problems.

--
Michael   address@hidden
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."