Why does compiler produce different code for 46: Disp=DispData8; C:0x02DD 908082 MOV DPTR,#Disp(0x8082) C:0x02E0 7438 MOV A,#0x38 C:0x02E2 F0 MOVX @DPTR,A 47: wait(22); C:0x02E3 7F16

That is not an answer to the question, only a critique of the form of the question.

True.

But you are more likely to get good answers when you present the question in a good form.

Also, don't post code in the title!

Ok, but perhaps you could fix/address that?

Not clear what the question is, what is the demarcation for the different code?

Lacking significantly in contextual detail, going to be hard to determine what/why compiler made specific choices.

 3 consecutive lines of code

    Disp=DispData8;
    wait(22);       
    Disp=DispData8;

the compiler produces

    46:         Disp=DispData8;
C:0x02DD    908082   MOV      DPTR,#Disp(0x8082)
C:0x02E0    7438     MOV      A,#0x38
C:0x02E2    F0       MOVX     @DPTR,A
    47:         wait(22);        
C:0x02E3    7F16     MOV      R7,#0x16
C:0x02E5    7E00     MOV      R6,#0x00
C:0x02E7    120546   LCALL    wait(C:0546)
    48:         Disp=DispData8;
C:0x02EA    7438     MOV      A,#0x38

The second write to Disp should be the same as the first.

Disp is defined as

char xdata Disp       _at_ 0x8082;

Seems to me to be a bug.

Is there a store instruction beyond the last line you showed?

Optimizer looks to have decided it doesn't need to reload DPTR

So you decided to ignore the instructions for posting source code?

GEAG said:

The second write to Disp should be the same as the first

Not at all.

As Westonsupermare Pier said, the compiler is probably smart enough to realise that the DPTR is already correctly set.

In fact, the optimiser might well decide that the 2nd write is entirely pointless - DispData8 hasn't changed been changed - and emit emit no code at all for it.

I doubt that the compiler would do this to a write to IO in the system. This code was last compiled in 1996 by the Archimedes compiler and it has been running just fine in many sold products. Unfortunately I would need an XP machine to run the old compiler which I do not have. So I spent $3K+ for the Keil. I have used the Keil in the late 90's for other work with no problems.

I set the optimize to 0, problem went away. thanks all.

GEAG said:

I doubt that the compiler would do this to a write to IO in the system.

Why wouldn't it?   Did you tell the compiler that that's I/O, instead of plain memory?

GEAG said:

I set the optimize to 0, problem went away

So there wasn't any actual problem in the first place!

The compiler was just doing a perfectly valid optimisation - omitting an unnecessary re-load of the DPTR - exactly as any assembler programmer would have done if writing this manually!

Andy Neil said:

So there wasn't any actual problem in the first place!

There was: the source code was implicitly making an incorrect assumption, causing incorrect behaviour.   And that problem remains unsolved.

On top of that, there are probably quite a number of even worse problems of similar kinds lurking in that source base.

The morale: if you observe a problem goes away by changing optimization levels, the actual problem is pretty much guaranteed not to be with the compiler, but rather with your source code.

Broeker said:

if you observe a problem goes away by changing optimization levels, the actual problem is pretty much guaranteed not to be with the compiler, but rather with your source code

+1