In our previous episode, Jonas Maebe said: > The reason the need for volatile on embedded systems is far less in FPC, > is the existence of the "absolute" keyword. In C, you have to declare > all of those memory mapped registers as volatile pointers, because > otherwise things will get optimised wrongly. In FPC, you can declare > them as variables that are "absolute" at some address, and the compiler > will never optimise their accesses. Only if you would take the address > of one of these variables and store it in a pointer, you would need > "volatile" in this context.
(you also need it for variables you access from interrupt routines, as they might change while a procedure is running) > In FPC, every statement is basically considered to be a compiler-level > memory barrier for accesses to global variables. So within a single > statement multiple accesses can be optimised, but that cannot happen not > across statements. It's not perfect since it inhibits some optimisation, > but on the flip side it's very simple and easy to reason about. That's what I remember from earlier "volatile" discussions. But what about LLVM? If you want to squeeze performance out of it, won't that need volatile sooner or later? But I agree that this is the usual smart shopping mentality. When shopping for a compiler, people drone on the most detail optimization opportunities, but once in production they put it on the lowest common denomitor they developed/tested with, and call that "validated". _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
