When I compile Make a mistake Seek to answer THX!

Once you've fixed those 1st three errors (as Drew explained), all the rest will probably also disappear!
With todays compile speeds (anyone know of more than 5 seconds to compile and link) I would - for general purposes - go as far as "Once you've fixed the 1st error some, if not all, of the rest will probably also disappear"

If there is no clear picture of whether an error is/could be the result of a previous, do one at a time.

Of course, my timing estimate above does not include uVision overhead, it is based on commandline (.bat) operation.

Erik

anyone know of more than 5 seconds to compile and link

Not that it changes the point, but since you asked: one of my projects takes about 17 seconds to compile all files and about 60 seconds to link. (119 files, a bit under 70K lines of source, roughly 90K of image and 32K of data.)

The linker in particular seems noticeably non-linear in its run time with respect to project size. When the project was just a wee nubbin of its current self (say around 8-10 KLOC), compile and link was indeed very quick. And of course when it decides to do its global register re-optimization, it takes four passes and more than four times as long.

OK, I missed that one. Superoptimization may, indeed extend the processing time dramatically. Believing in the NASA philiosophy "we fly what we test" I do not optimize beyond two. You may ask "what does that have to do with testing?". Simply, if a bug is found at optimization 47 there is no way to debug it since the source and object will have very little resemblance and if I can not debug, what is the purpose of writing code. Also, so called "testing" is, in my opinion, worthless as to finding functional problems, it only serves as a means of finding clerical problems.
You may have a differnt opinion, I shall not argue beyond what I stated above.

Erik

"I would - for general purposes - go as far as 'Once you've fixed the 1st error some, if not all, of the rest will probably also disappear'"

Yes, that would be a very good generalisation.

"If there is no clear picture of whether an error is/could be the result of a previous, do one at a time."

Yes.

In this particular case, it is obvious to me that there are 3 distinct "root" errors - so I would fix the 3 and then rebuild.
As your method suggests, even with the above observation, I wouldn't bother trawling through all the other messages to try and spot any more unrelated ones - just fix the 3, then address any that are left.

But, in general, "fix the first one first" stands.

"Of course, my timing estimate above does not include uVision overhead"

FYI: Provided uVision is already open, it adds no more overhead to a build than starting a batch file.

"Superoptimization may, indeed extend the processing time dramatically."

It most certainly does - no question at all!
Particularly the "Linker Code Packing"

"Simply, if a bug is found at optimization 47 there is no way to debug it since the source and object will have very little resemblance"

It is possible - just very much more difficult.
The LX51 Linker produces a disassembly listing of what it's actually done to aid in debugging.

This is a very big issue that people should really think about very seriously before just jumping blindly into the higher optimisation levels...

It's the same old story: there's no such thing as a free lunch; you can't have your cake and eat it; the tools can't magically double the 8051's address space out of thin air - the price you pay is loss of debuggability!

Where Could you tell me how I should check the question?
Need to check whether the Address is covered again?
Need to reduce the use of the variables?
My variables is under the situation that can't be reduced .
I deserve and do?

"Where Could you tell me how I should check the question?
Need to check whether the Address is covered again?
Need to reduce the use of the variables?
My variables is under the situation that can't be reduced .
I deserve and do?"

Fix the errors and warnings one at a time starting from the first, as others have told you.

Jia,

Drew explained the cause of your problem:

"Something has been declared with an explicit memory type that doesn't match its real memory space. Given your description, this is probably one of the items you moved from data to xdata. Some other piece of code still refers to it in the data space."

So you need to ensure that all your uses of the memory-type specifiers (data, xdata, etc) are consistent.

Another possible cause could be that you didn't rebuild everything when you changed the memory model.
You need to rebuild everything!

*** WARNING L15: MULTIPLE CALL TO SEGMENT
SEGMENT: ?PR?_FLASH_BOOT_WRITE_WITH_POLL?FLASHCODE1
CALLER1: ?C_C51STARTUP
CALLER2: ?PR?USBISR?MAIN

Program Size: data=198.0 xdata=608 code=48535
LINK/LOCATE RUN COMPLETE. 1 WARNING(S), 0 ERROR(S)

I can not find the question!!!How should I do?