3 ms·

Finally someone that understands.

by ydcvjk 11y ago

Gibbon1 11y ago
Not really because there are two kinds of c programer out there. 1. Those that communicate with the outside world exclusively via library calls to an operating system. 2. Those that do not. People that live in world #1, usually don't get people living in world #2. Example. // wait for write ready while((spi.S & SPI_S_SPTEF_MASK) == 0) ; spi.D; spi.D = data; Guess what, No spi.D; is actually important. No just because the program never writes to spi.S does not mean you can delete the while loop. No you cannot reorder any of this and have it work.
- spdionis 11y ago
  Why? That's the issue that people should solve. Disclaimer: I have no C experience.
- deleted 11y ago
  [deleted]
- deleted 11y ago
  [deleted]
- _dps 11y ago
  Are you saying something other than "you, the programmer, must declare spi to be volatile, or else the compiler might lay a bear trap for you?". Based on your comment it seems clear that you understand that... but given that you understand that I don't get the point you're trying to make (except perhaps that writing low-level hardware code in C often means actively stopping the compiler from screwing you over). (for non-C programmers: "volatile" can be approximated by "hey compiler, this variable can change unexpectedly even if you didn't do anything to change it, so don't use any optimizations that assume you're the only one changing it).
- ydcvjk 11y ago
  Sorry, I have no idea what you are trying to say. Maybe stick to the relevant issue and be less abstract?
  - icedchai 11y ago
    His example is anything but abstract. Embedded programming is a world unto itself. You sometimes need to read an address before you can write, etc.
    - dllthomas 11y ago
      I think the parent meant "implicit" rather than "abstract". The code is not abstract; but the pragmatic intent of the comment is not made very clear. I believe I follow but I'm not confident enough to risk confusing things by guessing. (I believe I follow the intended conversational import; I certainly follow the code.)
      - Gibbon1 11y ago
        Sort of the point is, in pure languages only the symbolic operations are important. And the side effects (memory operations) are unimportant and beyond the control of the programmer. So you can do all sorts of transformation on the code without effecting the end result. C is definitely impure. There is a large set usage cases where the memory layouts are important. Where the orders of operation and memory accesses are important. What I worry about is when the optimizer is allowed to make assumptions about undefined behavior, that may be actually important on certain targets. Consider referencing a null pointer. Winows7, Linux, in user land if you do that and you'll get a seg fault. And if the default handler runs your program dies. The ARM cortex processor I've been slopping code for, reading a null pointer returns the initial stack pointer. Writing generates a bus fault. Since I actually trap that, and error message gets written into non-initialize memory and then the processor gets forcibly reset. On an AVR reading a null pointer gives you the programs entry point. Writing to that location typically does nothing. Though you can write to it if running out of a special 'boot sector' and you've done some magic incantations. So that's the problem I have with the idea that 'undefined means the optimizer can make hash of your program' instead of trusting the back end of the compiler will do something target appropriate.
        AnimalMuppet 11y ago

Finally someone that understands.

by ydcvjk 11y ago

Finally someone that understands.

Not really because there are two kinds of c programer out there. 1. Those that communicate with the outside world exclusively via library calls to an operating system. 2. Those that do not. People that live in world #1, usually don't get people living in world #2. Example. // wait for write ready while((spi.S & SPI_S_SPTEF_MASK) == 0) ; spi.D; spi.D = data; Guess what, No spi.D; is actually important. No just because the program never writes to spi.S does not mean you can delete the while loop. No you cannot reorder any of this and have it work.

spdionis 11y ago
Why? That's the issue that people should solve. Disclaimer: I have no C experience.
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
_dps 11y ago
Are you saying something other than "you, the programmer, must declare spi to be volatile, or else the compiler might lay a bear trap for you?". Based on your comment it seems clear that you understand that... but given that you understand that I don't get the point you're trying to make (except perhaps that writing low-level hardware code in C often means actively stopping the compiler from screwing you over). (for non-C programmers: "volatile" can be approximated by "hey compiler, this variable can change unexpectedly even if you didn't do anything to change it, so don't use any optimizations that assume you're the only one changing it).
ydcvjk 11y ago
Sorry, I have no idea what you are trying to say. Maybe stick to the relevant issue and be less abstract?
- icedchai 11y ago
  His example is anything but abstract. Embedded programming is a world unto itself. You sometimes need to read an address before you can write, etc.
  - dllthomas 11y ago
    I think the parent meant "implicit" rather than "abstract". The code is not abstract; but the pragmatic intent of the comment is not made very clear. I believe I follow but I'm not confident enough to risk confusing things by guessing. (I believe I follow the intended conversational import; I certainly follow the code.)
    - Gibbon1 11y ago
      Sort of the point is, in pure languages only the symbolic operations are important. And the side effects (memory operations) are unimportant and beyond the control of the programmer. So you can do all sorts of transformation on the code without effecting the end result. C is definitely impure. There is a large set usage cases where the memory layouts are important. Where the orders of operation and memory accesses are important. What I worry about is when the optimizer is allowed to make assumptions about undefined behavior, that may be actually important on certain targets. Consider referencing a null pointer. Winows7, Linux, in user land if you do that and you'll get a seg fault. And if the default handler runs your program dies. The ARM cortex processor I've been slopping code for, reading a null pointer returns the initial stack pointer. Writing generates a bus fault. Since I actually trap that, and error message gets written into non-initialize memory and then the processor gets forcibly reset. On an AVR reading a null pointer gives you the programs entry point. Writing to that location typically does nothing. Though you can write to it if running out of a special 'boot sector' and you've done some magic incantations. So that's the problem I have with the idea that 'undefined means the optimizer can make hash of your program' instead of trusting the back end of the compiler will do something target appropriate.
      - AnimalMuppet 11y ago