Keil C does not support this line:
typedef const UINT32 volatile xdata *PCVX32;
typedef const volatile UINT32 xdata *PCVX32;
just curious How can something that is constant be volatile Erik
"just curious How can something that is constant be volatile" We flogged this to death before. In the 'C' programming language const!=constant. Just accept it.
"How can something that is constant be volatile" Yes, it appears contradictory at first sight, but is actually perfectly reasonable: 'const' simply tells the compiler to give a warning on any attempt to write to the symbol; it means "read-only" - it does not mean "constant!" The obvious example would be a read-only memory-mapped register - you'd use 'const' to prohibit writes to it, and 'volatile' for the usual reasons.
Agree on upstairs. I just describe a read-only register outside the MCU. So, it must be const and volatile. See the code below:
#include "TYPEDEF.H" typedef volatile UINT32 xdata *PVX32; typedef const volatile UINT32 xdata *PCVX32; //register sets #define CONTRL_REG (*((PVX32) 0x0600))//Control Register #define INTRPT_REG (*((PVX32) 0x0604))//Interrupt bits
typedef const volatile *PVINT;
typedef const volatile long *PVLONG;
typedef const long volatile *PVLONG;
Just a guess VC sell millions of copies Keil sell thousands of copies just visualize the budgets So, if some insignificant thing arise and there is a simple way to handle ir shut up and let Keil with the limited budget concentrate on significant issues. Erik
"So, if some insignificant thing arise and there is a simple way to handle ir shut up and let Keil with the limited budget concentrate on significant issues." I see. So when you find bug in your software you think the best approach is to find a workaround and ignore it rather than investigating whether it has wider implications than those you have observed for a particular test case?
So when you find bug in your software you think the best approach is to find a workaround and ignore it rather than investigating whether it has wider implications than those you have observed for a particular test case? No, absolutely not, However dragging out "VC can this, why can Keil not" is ridiculous. I do not expect Keil to consider VC "the standard", C for the '51 is a quite different animal than C for the PC. Anyhow, this hardly qualify as a "bug", requiring parametres in a certain order could, at most, be labelled an inconvenience. If I found an error, not an inconvenience, I would definitely press the issue. However an inconvenience should, of course, be brought to the attention to Keil, but harping on it as a disaster is ridiculous. Again I did not post as to the issue being mentioned, which it should, but to it being dragged out. I woukd expect Keil to check if this existed in a wider context and either document "the sequence MUST be" or allow random sequencing of keywords. Erik
addendum: the statement is "Keil C does not support", had it been "Keil C produce erroneous code" I would, of course, not have been of my stated opinion. Erik
"I do not expect Keil to consider VC "the standard", C for the '51 is a quite different animal than C for the PC." Nobody expects Keil to consider VC the standard. We do expect them, however, to conform to the ANSI standard unless there is a good reason not to do so. "Anyhow, this hardly qualify as a "bug", requiring parametres in a certain order could, at most, be labelled an inconvenience. If I found an error, not an inconvenience, I would definitely press the issue." const int volatile abc; //Compiles const long volatile abc; //Doesn't compile You don't think that's a bug? Or an error? "Again I did not post as to the issue being mentioned, which it should, but to it being dragged out. I woukd expect Keil to check if this existed in a wider context and either document "the sequence MUST be" or allow random sequencing of keywords." The whole point of having an ANSI 'C' compiler is so that anyone who can write ANSI 'C' can use it. The whole thing becomes pointless if you allow compiler writers to deviate arbitrarily from that standard. Would you consider it acceptable to have this ordering provided it were documented? 42 int = volatile abc;
"For two qualified types to be compatible, both shall have the identically qualified version of a compatible type; the order of type qualifiers within a list of specifiers or qualifiers does not affect the specified type." from ISO/IEC 9899:1999 And I can not find more.
const int volatile abc; //Compiles const long volatile abc; //Doesn't compile You don't think that's a bug? Or an error? Neither. I consider it an insignificant inconvenience which, of course, should be fixed, but not necessarily "yesterday. The whole point of having an ANSI 'C' compiler is so that anyone who can write ANSI 'C' can use it. The whole thing becomes pointless if you allow compiler writers to deviate arbitrarily from that standard. well, if that is your opinion, let us remove DATA, XDATA etc. Would you consider it acceptable to have this ordering provided it were documented? 42 int = volatile abc; In a low volume product, absolutely. Keil is doing a great job of making the compiling bug free and reasonably efficient, if a glitch of a certain odd sequence of parametres produce "does not compile" is that significant compared to "xxx,xxx produce the wrong result" I never said "forget this", just don't get your knickers in a knot becuse you have to change the sequence of two words. Do I expect Keil to fix this eventually, sure, but once Keil knows about it stop whining Erik
TC 2.0 and HI-TECH C for 8051 are both support this:
typedef const volatile long *pLONG;
"You don't think that's a bug? Or an error? Neither. I consider it an insignificant inconvenience" Excellent! I shall stop calling bugs in my code 'features' and start calling them 'insignificant inconveniences' from now on. "The whole point of having an ANSI 'C' compiler is so that anyone who can write ANSI 'C' can use it. The whole thing becomes pointless if you allow compiler writers to deviate arbitrarily from that standard. well, if that is your opinion, let us remove DATA, XDATA etc." Don't be silly. The standard permits extensions provided they are documented. Are you unable to see the difference? "Would you consider it acceptable to have this ordering provided it were documented? 42 int = volatile abc; In a low volume product, absolutely." So, you would be quite happy if you bought a 'C' compiler then discovered it actually compiled a language that wasn't 'C'? "just don't get your knickers in a knot becuse you have to change the sequence of two words." I think you're the one with his knickers in a knot!
Staffan: let me repeat from a previous post "Again I did not post as to the issue being mentioned, which it should, but to it being dragged out. I woukd expect Keil to check if this existed in a wider context and either document "the sequence MUST be" or allow random sequencing of keywords.". thus, please stop dragging it out. Erik
"Staffan" Try again. "let me repeat from a previous post "Again I did not post as to the issue being mentioned, which it should, but to it being dragged out." Perhaps you should restrict your posts to technical contributions? "I woukd expect Keil to check if this existed in a wider context and either document "the sequence MUST be" or allow random sequencing of keywords."." And I have explained to you why they cannot, and would not want, to do that. "thus, please stop dragging it out" I have no desire to drag anything out. Your contribution to this thread contained errors, I corrected them. Deal with it.
Please state fully, you shouls post Your contribution to this thread in my ponion contained errors. That we do not agree does not make my opinion erroneous. Erik