4 ms·

Someone told me back in high school that "C is just shorthand for assembly", which I think about a lot. Does anyone else feel that way?

Ididntdothis 7y ago
I think that goes way too far. Assembly is a completely different beast from C and way more complex. There is a lot stuff you can do with assembly that C can’t.
- CalChris 7y ago
  I agree that they are different beasts, but is there anything that assembly can do with data which C can't do? Or are there only control efficiencies which assembly can provide which C can't?
  - Ididntdothis 7y ago
    X86 has a lot of instructions that aren’t directly available to C and provide huge speed up. Often the optimizer will use them anyway but there plenty of cases where handcrafted assembly is much faster than anything C can achieve.
tenebrisalietum 7y ago
C lets you manipulate memory close to the level assembly allows, and C function pointers, unions, and strings are a very assembly-like thing. But assembly doesn't have the following concepts built into it, you have to manage those yourself if you want them: - The notion of functions and return values. CALL/RET implements subroutines, not functions. - Linkage that is more complex than jumps or call/returns. The ABI between units of code is something you have to define and do youself. - The notion of associating types with variables. Variables in assembly are simply labels for memory locations, but don't really constrict action or tell you how many memory locations are in the variable. Types, including valid actions, data widths, etc. are completely up to you and must be done manually in assembly.
steveklabnik 7y ago
Yes, folks do. I personally do not. I like this article on this topic: https://raphlinus.github.io/programming/rust/2018/08/17/undefined-behavior.html https://raphlinus.github.io/programming/rust/2018/08/17/unde...
ThrowawayR2 7y ago
> "Someone told me back in high school that 'C is just shorthand for assembly'" That was true for the PDP-11 that the article series mentions and it was true for the early home computers of the '70s and '80s but it became increasingly less true as processors became more and more complicated under the hood. That's kind of the point of the article series but it's not as big a deal as the author makes it out to be because it was already people writing in C were aware of.
- CalChris 7y ago
  I really like your first point, paraphrasing, that 'C is how the PDP-11 worked, then'. But as for now, I don't agree that most people writing C are in any way really aware of this shift. Instead, I think C is how the computer works is their abstraction level. Unless your homepage is Godbolt's Compiler Explorer [1], you see C, you think C, moreso if it's C++. [1] https://godbolt.org/ https://godbolt.org/
- 6keZbCECT2uB 7y ago
  As other people have pointed out, rather than C being more unlike assembly, processors are more unlike assembly. As such, the abstractions of C map pretty well to a theoretical assembly, even if optimization changes that precise mapping. A possible exception to this is the multicore semantics that are apart of each architecture aren't particularly well represented.
jeltz 7y ago
Yes, quite many do but I personally do not think that is a useful way to think about C. C is both much more than just a shorthand for assembly while at the same time it is a missing a lot of features from assembly.
deleted 7y ago
[deleted]
brlewis 7y ago
C is not shorthand for assembly, but there are two reasons why it feels like it. 1. You do lots of pointer arithmetic. But I don't think being practiced at pointer arithmetic is important for developing as a programmer. Just learn what it is. 2. Local variables in C exist on the stack, not the heap. But I don't think programming in C is a great way to learn about stacks. Except when you try to return a reference to a local variable from a function, everything feels the same as in other languages. If you're making a list of languages you want to try out, I wouldn't put C above 5th place. I say this as someone who spent 12 years primarily coding in C.

Ididntdothis 7y ago

I think that goes way too far. Assembly is a completely different beast from C and way more complex. There is a lot stuff you can do with assembly that C can’t.

CalChris 7y ago
I agree that they are different beasts, but is there anything that assembly can do with data which C can't do? Or are there only control efficiencies which assembly can provide which C can't?
- Ididntdothis 7y ago
  X86 has a lot of instructions that aren’t directly available to C and provide huge speed up. Often the optimizer will use them anyway but there plenty of cases where handcrafted assembly is much faster than anything C can achieve.

tenebrisalietum 7y ago

C lets you manipulate memory close to the level assembly allows, and C function pointers, unions, and strings are a very assembly-like thing. But assembly doesn't have the following concepts built into it, you have to manage those yourself if you want them: - The notion of functions and return values. CALL/RET implements subroutines, not functions. - Linkage that is more complex than jumps or call/returns. The ABI between units of code is something you have to define and do youself. - The notion of associating types with variables. Variables in assembly are simply labels for memory locations, but don't really constrict action or tell you how many memory locations are in the variable. Types, including valid actions, data widths, etc. are completely up to you and must be done manually in assembly.

steveklabnik 7y ago

Yes, folks do. I personally do not. I like this article on this topic: https://raphlinus.github.io/programming/rust/2018/08/17/undefined-behavior.html https://raphlinus.github.io/programming/rust/2018/08/17/unde...

ThrowawayR2 7y ago

> "Someone told me back in high school that 'C is just shorthand for assembly'" That was true for the PDP-11 that the article series mentions and it was true for the early home computers of the '70s and '80s but it became increasingly less true as processors became more and more complicated under the hood. That's kind of the point of the article series but it's not as big a deal as the author makes it out to be because it was already people writing in C were aware of.

CalChris 7y ago
I really like your first point, paraphrasing, that 'C is how the PDP-11 worked, then'. But as for now, I don't agree that most people writing C are in any way really aware of this shift. Instead, I think C is how the computer works is their abstraction level. Unless your homepage is Godbolt's Compiler Explorer [1], you see C, you think C, moreso if it's C++. [1] https://godbolt.org/ https://godbolt.org/
6keZbCECT2uB 7y ago
As other people have pointed out, rather than C being more unlike assembly, processors are more unlike assembly. As such, the abstractions of C map pretty well to a theoretical assembly, even if optimization changes that precise mapping. A possible exception to this is the multicore semantics that are apart of each architecture aren't particularly well represented.

jeltz 7y ago

Yes, quite many do but I personally do not think that is a useful way to think about C. C is both much more than just a shorthand for assembly while at the same time it is a missing a lot of features from assembly.

deleted 7y ago

[deleted]

brlewis 7y ago

C is not shorthand for assembly, but there are two reasons why it feels like it. 1. You do lots of pointer arithmetic. But I don't think being practiced at pointer arithmetic is important for developing as a programmer. Just learn what it is. 2. Local variables in C exist on the stack, not the heap. But I don't think programming in C is a great way to learn about stacks. Except when you try to return a reference to a local variable from a function, everything feels the same as in other languages. If you're making a list of languages you want to try out, I wouldn't put C above 5th place. I say this as someone who spent 12 years primarily coding in C.