Ah. Well, I'd call that a fairly sophisticated software concept, that I've never needed to use. In fact I wonder if it's ever relevant to "Embedded Systems and Microcontrollers". Seems more like big-computer stuff.

It's actually exactly the opposite as nsaspook correctly states.

And the example of where this will actually make a difference in a PIC?

Just one example

Now I couldn't get a project to compile away the loop as the wiki states, but then again, I did not pay for the compiler optimization package components that would do such.

You may not see such an optimization unless your compiler has settings or a tab such as this one:

 

And the example of where this will actually make a difference in a PIC?

As I said before the compiler just accesses the RAM location any time it reads or writes that variable. As someone who has used PIC assembler for over 10 years I always check the compilers ASM output and have a pretty good understanding of what it does.

In a Windows C situation where the compiler with use lots of temporary RAM and swap files etc then volatile can be very important, but the PIC does not have temporary RAM, it has very limited RAM where the one memory location is used for 1byte variable.

If anyone has a real example of a PIC volatile issue I would like to see it.

If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization.
-Gerald Weinberg, Weinberg’s Second Law.

Never depend on compiler quirks for proper code operation when proper software design will make it hardened. Code that seems to run correctly might only work with one version of a controller and totally crash with a development system upgrade. Not all pics have 1K of memory and you can bet that C18 when used on upper end chips with 64K+ memory or PIC32 using GCC will optimize out what it thinks is dead code and cache what it thinks are unmodified variables.

 

I did a little searching and managed to come up with a clear example of where the volatile keyword might be used. ...

 while((dvp->csr & (READY | ERROR)) == 0)
                ; /* NULL - wait till done */

...

Thanks John, that above problem won't occur because C compilers for PICs because they treat all SFR (special function registers) as volatile. It would be insane not to! The SFRs must be read and written constantly to check or set hardware flags and the entire purpose of the SFRs is to be constantly changing outside of software control.

If there is a volatile declaration issue it would be on a GPR (general purpose register or RAM variable).

The Wiki example of;

static int foo;
void bar(void) {
    foo = 0;
 
    while (foo != 255)
         ;
}

Is easy to understand but simply does not occur, at least on MikroC anyway. I have the paid version of the compiler with all 5 levels of selectable optimisation and the output result always looks like this;

;Led_Blinking.c,24 :: 		foo = 0;
$0004	$1303			BCF	STATUS, RP1
$0005	$1283			BCF	STATUS, RP0
$0006	$01A0			CLRF	main_foo_L0
$0007	$01A1			CLRF	main_foo_L0+1
;Led_Blinking.c,26 :: 		while (foo != 255);
$0008	$	L_main_0:
$0008	$3000			MOVLW	0
$0009	$0621			XORWF	main_foo_L0+1, 0
$000A	$1D03			BTFSS	STATUS, Z
$000B	$280E			GOTO	L_main_2
$000C	$30FF			MOVLW	255
$000D	$0620			XORWF	main_foo_L0, 0
$000E	$	L_main_2:
$000E	$1D03			BTFSS	STATUS, Z
$000F	$2808			GOTO	L_main_0

as you can see it clearly tests the RAM location of the 16bit var foo for ==0. This occurs on all 5 optimisation levels and also with char 8bit, int 16bit and long 32bit vars.

... Never depend on compiler quirks for proper code operation when proper software design will make it hardened. Code that seems to run correctly might only work with one version of a controller and totally crash with a development system upgrade. Not all pics have 1K of memory and you can bet that C18 when used on upper end chips with 64K+ memory or PIC32 using GCC will optimize out what it thinks is dead code and cache what it thinks are unmodified variables.

I REALLY agree! Which is why I check the compiler output. In my relationship the compiler is very much the servant not the master.

However I always use variables to pass info from interrupts back to main loops, and always check the compiler output, and the compiler always accesses the GPR ram locations in the main loops when it is told to check those variables.

I do use volatile in my windows programming, but nobody has yet posted any proof that it is needed in a PIC C compiler.

 

I just discovered I have MikroC installed on this machine. Hey!

So I boped open the compiler, opened up the Button example project, and it so nicely found the definition it is using for PORTC:

sfr unsigned short volatile PORTC            absolute 0x0007;

Looks like it is declared as volatile in the P16F887.c file, as it should be. Note it is not the compiler making that choice, it is the included file.

(A personal note I do not like how MikroC "sneaks in" the reference for this definition, at it does not appear in the main code. Perhaps the simplicity of that construct is what makes their business model work.)

... but simply does not occur, at least on MikroC anyway. I have the paid version of the compiler with all 5 levels of selectable optimisation and the output result always looks like this...
...as you can see it clearly tests the RAM location of the 16bit var foo for ==0. This occurs on all 5 optimisation levels and also with char 8bit, int 16bit and long 32bit vars.

Sorry to say but you got ripped off if your "optimizing" compiler emitter that code! It should be construed as dead code and removed.

 

...

sfr unsigned short volatile PORTC            absolute 0x0007;

Looks like it is declared as volatile in the P16F887.c file, as it should be. Note it is not the compiler making that choice, it is the included file.
...

Correct. PORTC (like all the hardware registers) is a SFR and is automatically volatile. As all the SFRs must be.

...
(A personal note I do not like how MikroC "sneaks in" the reference for this definition, at it does not appear in the main code. Perhaps the simplicity of that construct is what makes their business model work.)
...

As for "sneaking it in" what would you prefer? That every C program has a massive list of all the SFR registers defined in the top of the source code?

As for the "hidden file" "business model" i think you will find Microchip themselves have always had a separate defines file for all the PIC's SFRs, and other PIC C or basic compilers will all do the same?

...
Sorry to say but you got ripped off if your "optimizing" compiler emitter that code! It should be construed as dead code and removed.

Ha ha! Maybe the compiler was smart enough to know it was making code for a PIC and not for a PC...

Do you know another PIC C compiler that would compile that code as Wiki suggests? I would be very surprised if any of them do as it would be such a poor choice of code generation for a PIC.

It's a good example of why people that learn C in a classroom shoudn't think they will automatically be any good at writing C code for microcontrollers. Working with a Harvard architecture, SFR/GPR differences and no cache etc lean towards C optimisation that is going to use the GPR address for the variable on every occasion it can.

 

Correct. PORTC (like all the hardware registers) is a SFR and is automatically volatile. As all the SFRs must be.



As for "sneaking it in" what would you prefer? That every C program has a massive list of all the SFR registers defined in the top of the source code?

As for the "hidden file" "business model" i think you will find Microchip themselves have always had a separate defines file for all the PIC's SFRs, and other PIC C or basic compilers will all do the same?

Microchip in common with every other PIC C compiler (except MikroC) use header files for SFR definitions and the pragma directive or some other mechanism in the source file to set the chip configuration bits. MikroC uses a .c source file for these settings making porting of code somewhat difficult and giving no indication of how the config bits were set.

Ha ha! Maybe the compiler was smart enough to know it was making code for a PIC and not for a PC...

Do you know another PIC C compiler that would compile that code as Wiki suggests? I would be very surprised if any of them do as it would be such a poor choice of code generation for a PIC.

Or much more likely the compiler was too dumb to relies that it was dealing with a PIC!
Microcontrollers have very limited program memory and even more limited RAM so any compiler for microcontrollers should do more aggressive code optimisation than a compiler for PCs.
All good (and even most not so good) PIC compilers will remove dead (unused) code and convert any variables that don't change into constants that can be held in program memory rather than in RAM.
Optimisation should also simplify and streamline your code so that for example the statement

a &= ~(1 << 3);

will compile to

bcf a, 3

If your compiler doesn't do that then I would seriously consider changing compilers.

It's a good example of why people that learn C in a classroom shoudn't think they will automatically be any good at writing C code for microcontrollers. Working with a Harvard architecture, SFR/GPR differences and no cache etc lean towards C optimisation that is going to use the GPR address for the variable on every occasion it can.

If you are programming in C then you don't give a toss whether the device used Harvard or von Neumann architecture, how and where things are stored is controlled by the compiler not the programmer.
Providing the code is logically correct then the quality of the resultant machine code will dependant on how good the compiler is and how well it does code optimisation, not the skill or otherwise of the programmer.

 

Correct. PORTC (like all the hardware registers) is a SFR and is automatically volatile. As all the SFRs must be.
As for "sneaking it in" what would you prefer? That every C program has a massive list of all the SFR registers defined in the top of the source code?
As for the "hidden file" "business model" i think you will find Microchip themselves have always had a separate defines file for all the PIC's SFRs, and other PIC C or basic compilers will all do the same?

There is nothing automatic about the volatile declaration; it is defined in the code of the includes source file, not in the compiler. This is not an obtuse point, if it was truly inside the compiler then the compiler itself would need to be recompiled every time Microchip releases a new core.

Actually, there already IS a massive list of all the SFR registers and other things in the source, be it Microchip C or MicroC. It is defined in this source file. (Question: why does MikroC use a SOURCE .c file and not a header .h file? Probably easier to link in that way without a program reference!) For many reasons these are stuffed into an included file so as to not obscure other code, as is traditional and proper in C. The nuisance factor with MikroC is it gets included silently, without the programmer being aware of its existence.

And the business model I refer to is a question I have had for some time: "why market another C compiler for PICs when Microchip already gives them away?" Perhaps it is the hand holding it does by handling those nasty processor dependent include files and configuration bits that noobs always stumble over. If someone can get their first code up and running from the MicroC compiler after no success with Microchips then they are motivated to buy what works.

Ha ha! Maybe the compiler was smart enough to know it was making code for a PIC and not for a PC...

Huh? A PIC can support useless code bloat better then a PC? Really?

Do you know another PIC C compiler that would compile that code as Wiki suggests? I would be very surprised if any of them do as it would be such a poor choice of code generation for a PIC.

The Microchip PIC32 C compiler with optimization turned on. You know, the compiler from the people who designed the PIC itself?

It's a good example of why people that learn C in a classroom shoudn't think they will automatically be any good at writing C code for microcontrollers. Working with a Harvard architecture, SFR/GPR differences and no cache etc lean towards C optimisation that is going to use the GPR address for the variable on every occasion it can.

Besides the point of not all PICs using Harvard architecture (my current target PIC is MIPS based and has cache and memory segmentation and all sorts of goodies) the entire point of a high level compiler is to release the programmer from knowing or even caring what the base assembly code even looks like. While I would always agree that knowing the core at the assembly level is "useful" it is less useful as you go up in processors. I can code day and night in PIC16 and lower cores in assembly. My brain hurt too much to even finish reading the instruction set for the PIC18's. I never even looked at the assembly in PIC32's (I skipped over the 16 bit cores).

Oh, and back in school "C" wasn't even on the horizon. The formal courses I took were in now obsolete high level languages, or in assembly (for some IBM beast). On the side I had a few "microcomputers" such as the COSMAC Elf which ran my hand assembled code. "C" came later after figuring out assembly on a PC under windows. (Yes, I would take "Programming Windows" examples, read C and write assembly.

Not bad for someone who doesn't consider himself a "programmer."

Microchip in common with every other PIC C compiler (except MikroC) use header files for SFR definitions and the pragma directive or some other mechanism in the source file to set the chip configuration bits. MikroC uses a .c source file for these settings making porting of code somewhat difficult and giving no indication of how the config bits were set.

I should properly quote this entire post for truth but I am actually trying to be brief <grin>

An excellent point concerning the configuration bits. If you have spent any time at all inside the incredible excellent (and free!) Microchip Application Libraries (MAL) you would see example after example of application code that is configurable over many cores, even cores from different families. Configuration bits are set inside pragmatic #pragma statements turned on and off by #ifdef statements.

That facility is broken if these bits get set "in the project."

 

Microchip in common with every other PIC C compiler (except MikroC) use header files for SFR definitions and the pragma directive or some other mechanism in the source file to set the chip configuration bits. MikroC uses a .c source file for these settings making porting of code somewhat difficult and giving no indication of how the config bits were set.
...

Sure. But using a .c file to hold the data instead of a .h file does not make it "hidden" as ErnieM suggested. Which was my point. In all cases it is in a separate file, in another directory, one file for each PIC.

...If you are programming in C then you don't give a toss whether the device used Harvard or von Neumann architecture, how and where things are stored is controlled by the compiler not the programmer.
Providing the code is logically correct then the quality of the resultant machine code will dependant on how good the compiler is and how well it does code optimisation, not the skill or otherwise of the programmer.

You are proving my point, it is exactly that attitude that makes people write very poor C code for PICs that have very limited hardware. The old "I'll just write C and the compiler will give me the very best code" myth that I am surprised to hear from someone that is not an idiot.

...
The Microchip PIC32 C compiler with optimization turned on. You know, the compiler from the people who designed the PIC itself?

That's a laughable comparison as the PIC32 architecture is so very different to the lower level PICs and it's compiler is a totally different beast. You may as well compare a Windows x86 compiler to a PIC 12F compiler if you want to be ridiculous and sarcastic. Dalaran the OP asked re PIC 16/18 and MikroC which has been the basis of MY replies.

...
And the business model I refer to is a question I have had for some time: "why market another C compiler for PICs when Microchip already gives them away?" Perhaps it is the hand holding it does by handling those nasty processor dependent include files and configuration bits that noobs always stumble over. If someone can get their first code up and running from the MicroC compiler after no success with Microchips then they are motivated to buy what works.
...

You are right, MikroC provides a high level of ease of use for beginners, and like any compiler it is not perfect in every way. You obviously have your preferred compiler and I'm sure you like its benefits and are aware of its flaws too.

I share your (and Alexes) point on the config fuses, I would prefer them in the source code too rather than in a "Wizard" but that is unfortunately the modern way.

There's no point in some ******* contest of which compiler is best any more than which football team is best.

Getting back on topic this orignal intellectual debate (which I always enjoy with you ) was re your statement that the variable on Dalaran's PIC 16F or 18F would have to be declared as volatile and so far you have not been able to provide any proof that this is required, and I've posted some proof that it is not required by debunking the Wiki example and from years of my experience not using volatile on PIC 16F and 18F and my checking of the assembler output.

I'd actually be happy if you could prove a case where the issue exists as it would be good to know.

We all know what volatile is and why it can be useful sometimes. But what goes for large processors with large RAM and cache RAM etc does not automatically apply to tiny PICs with limited hardware. And good C decisions on large processors do not automatically translate to being good C decisions on small PICs!

 

Sure. But using a .c file to hold the data instead of a .h file does not make it "hidden" as ErnieM suggested. Which was my point. In all cases it is in a separate file, in another directory, one file for each PIC.

Another example of misquoting what I said, or did you misread it or just not understand it?

To restate my point leaving the file reference out of the project is what makes it hidden.

That's a laughable comparison as the PIC32 architecture is so very different to the lower level PICs and it's compiler is a totally different beast. You may as well compare a Windows x86 compiler to a PIC 12F compiler if you want to be ridiculous and sarcastic. Dalaran the OP asked re PIC 16/18 and MikroC which has been the basis of MY replies.

Once again you attempt to squiggle out of the ongoing discussion to make yourself seem correct. We are discussing Microchip PIC microcontrollers. It is up to Microchip to define what is and what is and is not a PIC.

Not you.

If you go back and READ Dalaran's post no where does he state MikcoC. That's something you said. You are the one saying "my compiler does not do X" to mean "no compiler will do X" is itself "ridiculous" and "laughable."

I share your (and Alexes) point on the config fuses, I would prefer them in the source code too rather than in a "Wizard" but that is unfortunately the modern way.

In no way shape or form is this the "modern" way. It is the way the specific compiler you use works. It is not how the Microchip C18 or C32 compilers work, nor the way of the SourceBoostC compiler, just to mention a few.

Getting back on topic this orignal intellectual debate (which I always enjoy with you ) was re your statement that the variable on Dalaran's PIC 16F or 18F would have to be declared as volatile and so far you have not been able to provide any proof that this is required, and I've posted some proof that it is not required by debunking the Wiki example and from years of my experience not using volatile on PIC 16F and 18F and my checking of the assembler output.

Nope, I do not have a sufficiently powerful optimizing compiler to dump code that exhibits this problem. That doesn't mean I'm going to start writing compiler dependent code. Neither is Mikroelectronica as they have very correctly defined the SFR's as volatile. Such a definition would not be used if this was not a significant point.

However, since you were looking for that one precious example of the required use of volatile in MikroC, I present you with such.

Oops, found another good example!

Should I go for three?

Finally, AlexR is spot on with his statements, as he gets the general case, but I will leave it to him to defend his post or not.

 

....................Finally, AlexR is spot on with his statements, as he gets the general case, but I will leave it to him to defend his post or not.

This thread is starting to get seriously off topic so I don't think I'll bother. In any case what's to defend?
Hopefully the OP will have gained something from this discussion and take our advise to declare ISR variables as "volatile", probably THE_RB won't, but that's his problem not mine.

 

...
To restate my point leaving the file reference out of the project is what makes it hidden.

No you said "does not appear in the main code", you mentioned nothing about the "project". You have changed your words.

...
(re PIC 32) Once again you attempt to squiggle out of the ongoing discussion to make yourself seem correct. We are discussing Microchip PIC microcontrollers.

The OP mentioned EasyPIC6 dev board which only works with PIC 16F and 18F. All my comments have been relevant to PIC 16F and 18F. For you to equate the OPs little PIC with the new big PIC32 is such an order of magnitude to be off topic, as though comparing a PIC 16F to a Pentium. I'm not trying to "squiggle out" just trying to get through to you the simple fact that you are wrong.

You advice was re passing a simple variable back from the interrupt on the OPs PIC. You have still failed to provide any proof that it is necessary.

...
If you go back and READ Dalaran's post no where does he state MikcoC. That's something you said.

He mentioned the MirkoE EasyPIC6 development board and I have helped him with other code matters in previous threads as he is using MikroC. You are apparently more ignorant of his setup and what he was asking than I am, which explains much of your error of logic. You were arguing with less information.

Part of my reason for participating in this thread is because I use the same dev board and compiler and thought I might have specific knowlege of the two to enable me to give him specific advice.

...
You are the one saying "my compiler does not do X" to mean "no compiler will do X" is itself "ridiculous" and "laughable."

No I placed the onus on you to prove your statement that the OP needed to use volatile so he could pass a variable from an interrupt on his PIC 16F back to the main code. You have still failed to provide any proof that it is necessary other than generalisations and referrals to very large PICs of a very different memory architecture using a much larger and more complex compiler.

...
However, since you were looking for that one precious example of the required use of volatile in MikroC, I present you with such.

That thread you linked has one post with no code to show in any way that the volatile was the issue. The users code could have had ANY fault.

Oops, found another good example!

Compeltely wrong again! You are making it a habit. In post #7 the OP says he then used "volatile" and it was still NOT fixed. In post #8 Mince says he tested WITHOUT "volatile" and it was STILL fixed even without volatile.

You can be as argumentative as you like, but you stated "volatile" was necessary for our OP to bring a variable back from the interrupt to the main code, and you still have not proved it. And if you can't prove it then the case rests, science and logic are based on proof, not on your "faith" Ernie.

 

To the community: I sincerely apologies for participating in the hijacking of this thread. In my defense, I was attempting to correct some incorrect or parochial comments by one individual.

However, I can see I have violated a fundamental tenant of internet forums: Don't feed the trolls.

Mea culpa.

 

You can be as argumentative as you like, but you stated "volatile" was necessary for our OP to bring a variable back from the interrupt to the main code, and you still have not proved it. And if you can't prove it then the case rests, science and logic are based on proof, not on your "faith" Ernie.

To be fair, C18 has been intentionally tweaked to make most accesses be already treated as volatile (reducing optimization) because of the programming styles and expectations of users, so it's fair to say for most programs it's non-use on a ISR variable will have no direct effect on function. Volatile does have an effect on optimizations and hardware interaction causing bug reports in previous versions.
http://www.microchip.com/forums/tm.aspx?m=118026&mpage=1&key=&#149034

Simple example of volatiles effect on code with full C18 optimizations.

http://www.flickr.com//photos/nsaspook/sets/72157627096455182/show/

The side effect is one x=y is eliminated as redundant until the variables are made volatile. I'm sure a carefully crafted example with ISR code could be written but I'd rather do something useful like drink a beer.

 

...To be fair, C18 has been intentionally tweaked to make most accesses be already treated as volatile (reducing optimization) because of the programming styles and expectations of users, so it's fair to say for most programs it's non-use on a ISR variable will have no direct effect on function. Volatile does have an effect on optimizations and hardware interaction causing bug reports in previous versions.
http://www.microchip.com/forums/tm.aspx?m=118026&mpage=1&key=&#149034

I agree, but would add that PIC C compilers for 16F and 18F are not just "tweaked to automatically treat variables as volatile because of user convention", but also because general optimisation requires the fastest/smallest code and on those PICs that results from directly addressing the GPR RAM location. It's faster and better for the compiler to do MOVF or MOVWF than any alternative using "cached variables" and it's simply good practice in the compilation.

It's interesting to note you said C18 has now moved toward a user convention of auto volatile, I too would have thought that was superior.

If a user codes; blah = meh; on a PIC16F or 18F then it would be logical that they want the contents of RAM meh moved into RAM blah regardless of optimisations. PICs, especially small ones, are very much about being in control of the very small hardware resources and advanced programming often involves use of gotos, global variables, inline assembler, positioning code and ram in particular locations etc etc, all things that are not "proper C" but do enable someone with an expert skill level on that limited hardware to accomplish what the compiler can never do.

.. However, I can see I have violated a fundamental tenant of internet forums: Don't feed the trolls.
...

ErnieM, that is uncalled for. A troll is a person who uses the forum for the primary reason of causing trouble. I have been here for years and the vast majority of my posts are philanthopic, helping others on technical matters, with some occasions of asking for help myself and maybe a little humour.

I was genuinely interested in the volatile issue you first mentioned and have been polite and mature in my posts. You are the one who introduced ridicule, sarcasm and now libel.

 

I was going to leave this thread alone but when I see blatant misinformation and ignorance peddled as fact then I'm afraid I must jump in.

FACTS YOU ARE IGNORANT OFF:
1. No ANSI/ISO compliant C compiler automatically treats all variables as volatile, only variables that have been tagged as volatile are treated as such.
2. Compilers for PICs (and other microcontrollers) including C18 treat SFRs as volatile(as they should since their content can change outside of the program control) but only because they have been tagged volatile in the header files. Any user defined variable that is not tagged volatile will be treated as an ordinary run of the mill variable and is subject to being optimised out if not used.
3. C18 has not nor is going to move to any convention to treat all variable as volatile. If you or nasspook had bothered to read the link provided by nsaspook you would see it refers a bug that occurred when someone at Microchip forgot to mark the SFR definitions in the header files as volatile.
4. Variables marked volatile cannot be optimised so marking every variable as volatile whether it needs it or not will lead to inefficient and blotted code.

 

It's interesting to note you said C18 has now moved toward a user convention of auto volatile, I too would have thought that was superior.

My little demo shows that volatile is not auto in C18. Most volatile/optimizer side-effects deal with code size reduction not directly with memory accesses. The main side effect of volatile is that it changes the optimization process from "as if" to a "as written" model as shown in my two line "redundant store removal" example.

"as if" model: I can modify the structure of the code flow in anyway as long as it has the same result.
"as written" model: Just do what I told ya, even if it seems stupid.

The bias with C18 is almost always "as written" with complex code sequences because of all the things that make it not optimize like hardware (defined volatile) operations, some pointer operations, inline asm code (ISR '_asm goto xx_isr_xxx' inline assembly block will stop optimization in the jumped to C ISR code), etc ...

Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
-- M.A. Jackson
"More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity."
-- W.A. Wulf

 

...
FACTS YOU ARE IGNORANT OFF:
1. No ANSI/ISO compliant C compiler automatically treats all variables as volatile, only variables that have been tagged as volatile are treated as such.
2. Compilers for PICs (and other microcontrollers) including C18 treat SFRs as volatile(as they should since their content can change outside of the program control) but only because they have been tagged volatile in the header files. ...

I'm not sure what your argument is or what I am "ignorant" of?

Regarding the SFR (hardware registers) they are handled automatically because of the include file for the specific PIC in use. ErnieM even had a criticism of MikroC as he thought it was handled "too automatically" (my words) to the point of being "hidden" (his words).

Maybe we have different definitions of "automatic" (which sounds like wasting time nitpicking to me) but I feel if it's done without being specifically commanded by the user it qualifies as "automatic". As for the SFRs, it is, so they are.

As for the GPRs, in the code I have compiled for years with my compiler the reading or writing GPRs have "automatically" resulted in asm that directly accesses the GPR RAM locations. I haven't said this is guaranteed "automatic" with GPRs in all cases, in fact we have all been discussing where and when this happens.

...
The bias with C18 is almost always "as written" with complex code sequences because of all the things that make it not optimize like hardware (defined volatile) operations, some pointer operations, inline asm code (ISR '_asm goto xx_isr_xxx' inline assembly block will stop optimization in the jumped to C ISR code), etc ...

Thanks for clarifying. I did say "moved toward a user convention of auto volatile" in reference toward the user expecting that if they read or write a register on a small PIC then their commands in code are carried out.

I agree with your "as written model" and I agree it is (or should be) the convention for compiling code on the small PICs. One of the reasons I check the assembler the compiler generates is to make sure it has performed my wishes "as written", and to be fair my programming style has changed over the years to the point when I write deliberately simplified, more vertical C code which more clearly specifies my wishes so the compiler WILL compile the code as it was written.

Someone who writes in a different style may get a lot more situations where the compiler does not compile their code as written, and experience problems especially if they are not in the habit of checking compiler output and "holding its hand" so to speak.

 

Nsaspook: I'm not sure "bias" is the term I'd use but I have no problem with it. I do like the "as if" / "as written" comparison.

I was going to leave this thread alone but when I see blatant misinformation and ignorance peddled as fact then I'm afraid I must jump in.

FACTS YOU ARE IGNORANT OF:
<snip>

Yep all that and more too. But when you are trying to instruct someone who cannot tell the difference between a C file and a C compiler do you really expect him to comprehend the meaning behind such simple declaratory statement as "FACTS YOU ARE IGNORANT OF" ?

Just let him have his last self exalting statement on this thread and let it die with him.

 

Nsaspook: I'm not sure "bias" is the term I'd use but I have no problem with it. I do like the "as if" / "as written" comparison.

I don't mean bias in a negative sense but the developers know that users from a machine code/asm background expect to see logical, human readable expressions in code results and it makes debug functions easier.

 

I don't mean bias in a negative sense but the developers know that users from a machine code/asm background expect to see logical, human readable expressions in code results and it makes debug functions easier.

Exactly my point. And users of the small PICs *should* be working closely with the hardware. Especially expert users. C18 and MikroC should be applauded for PIC compilers that follow a more hardware oriented convention rather than a C purist convention.

...Yep all that and more too. But when you are trying to instruct someone who cannot tell the difference between a C file and a C compiler do you really expect him to comprehend the meaning behind such simple declaratory statement as "FACTS YOU ARE IGNORANT OF" ?

Just let him have his last self exalting statement on this thread and let it die with him.

So now you have descended from sarcasm through libel to personal attacks? What's next are you going to start swearing? You don't look good here Ernie.