Warning 216

[russk2txb]

Ok, I got the v4.071 compiler and right away I ran into a problem. At the end of compilation there are a bunch of warning 216 messages about disabling interrupts during certain function calls. I do understand why these interrupts should be disabled when called from an interrupt, but I have some questions.

1. If the same function is called from an ISR and from main code, are the interrupts disabled in either case?
2. Is there any way to turn off this warning (pragma warning)?
3. Is there any way to turn off this behaviour?
4. Is this new behaviour for the new compiler, or just a new warning message?

Each warning message references the last line of code in my file, so it is impossible to determine what instance of the function call the warning is for - leading me to think maybe it is for all instances???

You may think it is bad programming practice to call the same function from an ISR and main code, but not really if the circumstances are right. For instance I have a Reboot function that the comiler warned about. It turns off some periphials and then resets the processor. Mostly it is called from main code, but in one place from the rda interrupt in response to a command from the controlling PC. In either case it is ok to disable the interrupts, and so I would like to not see the warning message.

Another case is a function that writes 4 bytes to the EEProm. This function is called from main code (in several places), and once from the power loss interrupt. When called from the ISR, it is may be reasonable to shut down the interrupts, but not when called from main code. So I hope this warning only applies to calls from ISR, but it's impossible to tell from the compiler message. (Actually extra instructions to shut off interrupts during power loss processing are not welcome either!)

I'd like to respectfully submit that the compiler warning message needs to be more explicit, and correctly show the line numbers for the calls where this is done.

Thanks in advance for any explanations.

Russ

[russk2txb]

In addition to my first questions, two more. First look at this code:

void AZ_stop ()
{
output_bit (PIN_A5, 0); // Stop drive CW
output_bit (PIN_A2, 0); // Stop drive CCW
output_bit (PIN_B3, 0); // Slow off
if (gbMovingCW | gbMovingCCW)
AzStopTimer = 0;
gbMoveCW = gbMoveCCW = false;
gbMovingCW = gbMovingCCW = false;
gbAzSlow = false;
if (bJogLed)
output_bit (PIN_E2, gbElSlow); // leave it on if el is slow
}

Why would the compiler turn off interrupts for this function?

Secondly, in my first message I mentioned a function that writes 4 bytes to EEProm. here it is:

void WriteEEpromDLong (int address, int32 value)
{
write_eeprom (address, value >> 24);
write_eeprom (address+1, value >> 16);
write_eeprom (address+2, value >> 8);
write_eeprom (address+3, value & 0xff);
}

However several functions call it, like this:

void SetCurrentEl (int32 el)
{
WriteEEpromDLong (EL_CURRENT, el);
OpData.ElPosition = el;
}

Why would the compiler generate a Warning 216 for this second function, since we already know that WriteEEpromLong turns off the interrupts? Or is it smart enough to turn off the ints at the call to SetCurrentEl, and then not turn them off again when WriteEEpromLong is called?

Thanks again,
Russ

[PCM programmer]

[russk2txb]

Ok, I see where I can turn off the warning, but it appears to be for all instances of that warning. I want to be able to turn it off only for specific instances where I know the warning is not needed (for instance during Reboot). Other places I want the warning so I can know to watch out for problems that turning off the ints might cause.


Also, I already figured out, partially, the answer to my second post, where I asked why the warning was generated for the function AZ_Stop:

void AZ_stop ()
{
output_bit (PIN_A5, 0); // Stop drive CW
output_bit (PIN_A2, 0); // Stop drive CCW
output_bit (PIN_B3, 0); // Slow off
if (gbMovingCW | gbMovingCCW)
AzStopTimer = 0;
gbMoveCW = gbMoveCCW = false;
gbMovingCW = gbMovingCCW = false;
gbAzSlow = false;
if (bJogLed)
output_bit (PIN_E2, gbElSlow); // leave it on if el is slow
}

The problem is with this line: if (gbMovingCW | gbMovingCCW)

Changing it to "if (gbMovingCW || gbMovingCCW)" resolves the issue. But why? This is a simple bitwise OR. gbMovingCW and gbMovingCCW are both bool (typedef short bool;). This should not invoke any non-reentrant code. I have always used the single | in cases like this because it creates fewer machine instructions than the || which would generate jump or branch instructions.

Thanks,
Russ

PS: Wonder why my posted code is not showing up in code blocks like before.

[PCM programmer]

[russk2txb]

Ok PCM, thanks for your help. Here is a test program:

[PCM programmer]

You can see it in the .LST file. The bitwise-OR operation uses a
temporary variable, while the logical OR does not.

Here's the bitwise OR. It uses temporary variable "@@1C":

[russk2txb]

PCM, yes I do see. And not only that but the bitwise OR uses a lot more instructions - completely opposite from any processor I have used before. It does not make sense to me... Even the lowly 8008 microprossor had a way to OR a register with the accumulator and leave the result plus flags in the accumulator - with a single instruction. However it is what it is and I will have to work with it.

Now if you can answer one more thing I think I will be done. If I have a routine like that AZ_stop, and I call it from another function, StopAll. Both AZ_stop and StopAll will be flagged with warning 216 (if I am calling both from main code as well as ISR). Why is that - if StopAll does not have any code that needs to be protected then I would think only AZ_stop would be flagged with the warning. And are interrupts really disabled when calling StopAll, or only when StopAll calls AZ_Stop? I will look at the .lst file to find that answer, but beyond the simple question of what does it do, I'd appreciate an answer to why.

Thanks,
Russ

[andrewg]

[russk2txb]

[PCM programmer]

In MPLAB, go to the Project menu, and then to Build Options.
In that window, select Symbolic format for the List file.
Then you will see this:

[russk2txb]

PCM, I have now studied the .lst files for several examples and I see what I think is incorrect application of this disabling of interrupts.

Suppose you have a program with functions f1, f2, main, and int_rda. Only f1 has code that must be protected from reentrance, but f1 is called from f2. Now if f1 and f2 are both called from main and from int_rda, the 216 warning will be shown for both f1 and f2. From the lst file the ints are disabled prior to the call to both f1 and f2 in main. But this means that all of the code in f2, both prior to and after the call to f1, are protected from interrupts, even though it is not necessary. Interrupts will remain disabled for a lot longer than necessary.

This could cause significant problems to programs that depend on fast interrupt handling. This is especially a problem since we don't have dependable ways of knowing when a routine will disable interrupts (except by compiling with the new compiler and seeing if it generates a warning 216). People with the version 3 compiler will never figure it out, and people with v4 compiler will perhaps write a lot of code, only to discover they have to restructure to prevent this problem.

If, in my example, the ints were disabled inside of f2, just before calling f1, then the problem would be significantly reduced and it would not be necessary to warn for or disable interrupts for each call to f2.

I also think a list of operators and functions that cause interrupt disabling, and perhaps some syntax coloring in the editor when one of these operators or instructions are used would be very helpful. Even better would be to have a compiler switch that could cause code generation that does not require reentrancy protection.

If my suggestions are valid, can you make sure they are forwarded to the proper peoople?

Thank you,
Russ