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

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.

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