Compiler optimisation

"The ^ may _only_ be used when declaring bit variables"

Here is where i got confused.

Because i had used something like P0^1 so i thought that is the only way to reference a bit.
i do not know why keil chose to use P0^1 to declare bits instead of P0.1
I just used keil only after about 5 years.in fact i do not use MCS51.

Thanks

Sheik mohamed

"The ^ may _only_ be used when declaring bit variables"

Here is where i got confused.

Because i had used something like P0^1 so i thought that is the only way to reference a bit.
i do not know why keil chose to use P0^1 to declare bits instead of P0.1
I just used keil only after about 5 years.in fact i do not use MCS51.

Thanks

Sheik mohamed

Yes, it is a very common source of confusion - it caught me out when I first started with C51!

It does seem to be a rather poor choice on Keil's part, and it is certainly not well explained in the manual.

:-(

"I must have used (P0 & 1) instead of (P0 ^ 1)"

No - that is still a whole byte operation!

if you want to use the 8051's single-bit features, then you have to define a single-bit variable:

sbit P0_1 = P0 ^ 1; // Define a single-bit variable

:

if( P0_1 )          // Test the single-bit variable

:

P0_1 = 1;           // Set the single-bit variable

:

P0_1 = 0;           // Clear the single-bit variable

http://www.keil.com/support/man/docs/c51/c51_le_sbit.htm

Yes, I got your point.

But when i use (P0 & 1) the compiler knew that i was testing for bit and it has assembled the right bit instruction for testing bit and not "AND" instruction for testing the whole byte.That is very nice & wise of the compiler.But the compiler did not check if the address is bit-addressable or not.If it had found the address is bit-addressable then it could have assembled more specific "jb" instruction.

Sheik mohamed

No, you clearly didn't!

"when i use (P0 & 1) the compiler knew that i was testing for bit"

No, it does not!!

P0 is an 8-bit value;

1 is an integral constant.

In strict ANSI 'C', the integral constant is considered an int, and the 8-bit value would be promoted to an int before doing a bitwise 'AND' of all bits and giving an int result.
Effectively, the expression is:

( P0 & 0x0001 )

Keil C51 gives you the option to disable this promotion, so that the expression becomes just an 8-bit operation.

But the only way to get Keil C51 to operate on a single bit is to use the specific bit operations.

Again, ANSI 'C' bitwise operators have noting to do with the 8051's single-bit operations!

In strict ANSI 'C', the integral constant is considered an int, and the 8-bit value would be promoted to an int before doing a bitwise 'AND' of all bits and giving an int result.

With the integer promotion, the semantics of the operation do not change: the code is still testing for a bit. In this particular case, if the compiler knew that the register is bit-addressable and chose not to ignore this information it could test for this bit directly.

But the only way to get Keil C51 to operate on a single bit is to use the specific bit operations.

Well, that's the point. A smarter compiler will use faster and more compact code constructs where appropriate. This is clearly one of those cases.

Again, ANSI 'C' bitwise operators have noting to do with the 8051's single-bit operations!

I'm not sure what you mean by that. I've seen the Green Hills compiler for Coldfire generate BSET and BCLR instructions when I was using bitwise OR and bitwise AND operators to set or clear bits. Why wouldn't C51 do the same? Especially since the 8051 core does a read-modify-write internally to set or clear bits, so semantics are the same.

Note that the compiler can be smart enough to notice that x & 1 can be seen as a bit operation. It would be a lousy compiler if it couldn't.

But P0 is a volatile 8-bit variable. And the language standard requiers that the compiler does perform the volatile access. So the compiler can't do a single-bit access to a bit variable that just _happens_ to be aliased to one bit of the 8-bit P0 special function register. The compiler _must_ do the full 8-bit read of P0. Then it can use its optimization abilities to convert (x & 1) into a bit operation instead of a full byte-wise and followed by a check of the zero flag.

When you do declare a bit variable P0_0, then the compiler isn't bound by the language standard into having to read the full P0. You have explicitly then told the compiler that you want an access to a single-bit variable, and the compiler may perform such a single-bit access without involving the accumulator.

Remember that it isn't obvious what special actions that may be trigged by accesses to an SFR. In some situations, the byte read may acknowledge an interrupt mechanism. In some situations, the access may control the latching of a 16-bit timer value into two 8-bit SFR.

Keil do not want to add a lot of special code intentionally violating the language standard just because they have considered it "safe" (an assumption since the world is full of 8051 variants with varying "special" features added) to violate the language standard in special situations. And there is no need to add such special code since they have explicitly given you the means to declare bit variables to explicitly tell the compiler to perform just a bit access.

"I've seen the Green Hills compiler for Coldfire generate BSET and BCLR instructions when I was using bitwise OR and bitwise AND operators to set or clear bits. Why wouldn't C51 do the same?"

Was that with SFR or volatile variables? Or was it with normal variables?

It really is important to separate SFR and volatile variables from standard char/int/... variables when discussing single-bit accesses.

But P0 is a volatile 8-bit variable. And the language standard requiers that the compiler does perform the volatile access.

For what it's worth:

On a '51, a bitwise operation internally requires a read of the complete byte. For example a CLRB is actually documented as a read-modify-write of the byte. So the JB, JNB, CLR and SETB would actually satisfy the volatile requirement.

But P0 is a volatile 8-bit variable. And the language standard requiers that the compiler does perform the volatile access. So the compiler can't do a single-bit access to a bit variable that just _happens_ to be aliased to one bit of the 8-bit P0 special function register. The compiler _must_ do the full 8-bit read of P0. Then it can use its optimization abilities to convert (x & 1) into a bit operation instead of a full byte-wise and followed by a check of the zero flag.

I'd say that the volatile argument is a poor excuse for avoiding optimization here. One could argue that an SFR is not covered by the language standard: even the declaration of an SFR has a special non-standard syntax. Besides, it is known that the CPU will perform a byte read when you read a single bit.

In that case it must have converted the P0 into an integer & do an 'AND' operation on that integer with an integer constant 0x0001

That is in strict ANSI-C,

       mov a,p0            <--- LOW(P0) <-port value
       andi a,#LOW(0x0001) <-integer const 1
       mov r0,a            //Save the result of low byte
       mov a,#0            <--- HIGH(P0)  <-port value promoted to integer as per ANSI C
       andi a,#HIGH(x0001) <-integer const 1
       orl a,r0            <--- is integer result 1
       jz  xxx

The above code is not needed we all know and the compiler too knew it.If it was to follw the ANSI-C then it would not have choosen the jnb instruction but the above big code.
But the compiler actually found the smart way to do the same thing with a bit test instruction.
But it missed the checking of whether the port byte is bit-addressable or not.

The "volatile" does not come here as the port bit is being accessed directly every time.

The compiler should produce small,smart & fast code that gives the same output when executed.

Sheik mohamed

I have seen compiler demote an integer to char

ex:

void delay(void)
{
int delay_val;
   for(delay_val = 0;delay_val < 250;delay_val++)
   {
     do_nothing();
   }
}

In the above code one of a compiler used a single 8 bit register for 'delay_val' that is
it demoted the int into char.Which may not be supported by your ANSI-C.But we all know when the code executes it will produce the same result.In fact a better result.Lower code & data memory usage and faster code execution.

It was nice & wise.Since the delay_val is never assigned a value above 255 so the compiler chose
to demote the integer to a char.

There is no ANSI-C comming here.It is just an optimization by the compiler

Sheik mohamed

It is irrelevant what a classic 8051 does. The classic 8051 implements the instructions based on a requirement to minimize the number of transistors. But a modern one-clocker or a soft core may introduce a lot of changes since they have a completely different transistor budget available. I'm not convinced that the read-modify-write argument is true for every 8051 implementation in existence now or next year.

There shouldn't be anything stopping a manfacturer from introducing pin-change interrupts, where a read of a single port bit acknowledges interrupts for that pin while a read of the port acknowledges/clears potential interrupts for all eight pins.

I'm not convinced that ...

You dare to doubt the so-called "bible"? shame on you.

I don't doubt the bible, where it is applicable.

But I doubt that 25 year old documentation of the original 8051 is true for all 8051 variants in existence or in planning. It is enough that a single 8051 manufacturer (or programmer, if we think about soft cores) decides that bit operations can be done without a read/modify/write.

We are not debating any natural laws here. And even many of our natural laws are only applicable in their "normal" form for non-relativistic speeds.

But I doubt that 25 year old documentation of the original 8051 is true for all 8051 variants in existence or in planning.

But that shouldn't prevent the compiler writers from implementing optimizations for cases where they are applicable. That would be most if not all existing 8051 cores. A simple command line switch will take care of new/non-compliant cores.
My understanding is that the OP is expressing frustration by the lack of progress on the optimization front. And I agree with that. It appears that C51 has been in bug-fix-only mode for many years.

Not if you were relying upon the loop execution time based on int arithmetic...!