2 ms·

Right. There might be an obvious mapping for any C construct, but there's absolutely no guarantee that a C compiler will do the obvious thing. The C standard le

by pdw 10y ago

Right. There might be an obvious mapping for any C construct, but there's absolutely no guarantee that a C compiler will do the obvious thing. The C standard leaves much behavior undefined (wolfgke listed some of the more notorious items), and modern compilers exploit that. People who view C as "portable assembler" end up being very disappointed.

wolfgke 10y ago
> There might be an obvious mapping for any C construct I don't know much about the PDP-11, the machine for which C was originally designed, but for modern processors this "obvious" mapping is typically not how things are done in assembly. To give an example: int x = 42; x = x+1; foo(&x); The way how it was originally conceived in C was that we reserve, say, 4 bytes on the stack and pass the adress of x on the stack to foo. On the other hand, any assembler programmer would try to store integer variables in a processor register (where we can't take an adress) and synchronize it with the x on the stack before we pass x's adress to foo. In other words: x now is now "two variables": 4 bytes on the stack and a register, which are synced if necessary. Summarizing: In assembly we have "two kinds of local variables": - Registers [one cannot take adress of it] - Adresses in stack frame [on RISC cores (load-store architecture) these can only be accesses by an explicit load/store and must be loaded into register before anything useful can be done with them; on x86-32/x86-64 the story is a little more complicated - I don't want to go into the details here] As I have shown these two completely different concepts are intertwined in C into the conept of local variables. I hope this convinces you how the concepts in C don't map directly to modern assembly code (i.e. a direct mapping yields bad assembly code). Ironically C has the concept of "register" variables, of which one cannot take the adress. This feature is hardly used in modern C, but maps IMHO much better to the "register" concept in assembly (but I'm not a C expert).

by pdw 10y ago

wolfgke 10y ago

> There might be an obvious mapping for any C construct I don't know much about the PDP-11, the machine for which C was originally designed, but for modern processors this "obvious" mapping is typically not how things are done in assembly. To give an example: int x = 42; x = x+1; foo(&x); The way how it was originally conceived in C was that we reserve, say, 4 bytes on the stack and pass the adress of x on the stack to foo. On the other hand, any assembler programmer would try to store integer variables in a processor register (where we can't take an adress) and synchronize it with the x on the stack before we pass x's adress to foo. In other words: x now is now "two variables": 4 bytes on the stack and a register, which are synced if necessary. Summarizing: In assembly we have "two kinds of local variables": - Registers [one cannot take adress of it] - Adresses in stack frame [on RISC cores (load-store architecture) these can only be accesses by an explicit load/store and must be loaded into register before anything useful can be done with them; on x86-32/x86-64 the story is a little more complicated - I don't want to go into the details here] As I have shown these two completely different concepts are intertwined in C into the conept of local variables. I hope this convinces you how the concepts in C don't map directly to modern assembly code (i.e. a direct mapping yields bad assembly code). Ironically C has the concept of "register" variables, of which one cannot take the adress. This feature is hardly used in modern C, but maps IMHO much better to the "register" concept in assembly (but I'm not a C expert).