[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-chat] Missed Optimisation ?

From: Michael Hennebry
Subject: Re: [avr-chat] Missed Optimisation ?
Date: Thu, 3 Mar 2011 16:05:10 -0600 (CST)
User-agent: Alpine 1.00 (DEB 882 2007-12-20)

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."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]