5 ms·

> the concepts of pointers, variable sizes and memory layout of structs all represent the machine at some level. Exactly. Everything in assembly is still one-

> the concepts of pointers, variable sizes and memory layout of structs all represent the machine at some level. Exactly. Everything in assembly is still one-to-one in terms of functional/stateful behavior to actual execution. Runtime hardware optimization (pinhole instruction decomposition and reordering, speculative branching, automated caching, etc.) give a performance boost but do not change the model. Doing so would mean it didn't work! And C is still very close to the assembly, in terms of basic operations. Even if a compiler is able to map the same C operations to different instructions (i.e. regular, SIMD, etc.)

pjmlp 9mo ago
Lets play a game of what ISO C can do, and no other systems programming language has similar feature available? If language extensions to ISO C are allowed, then same goes for my selection on competing systems languages.
- Nevermark 9mo ago
  Yes, most languages allow C type code, if that’s what you are trying to do. Java with only primitive values, arrays, and classes only with fields and static methods. But that wouldn’t be idiomatic Java, so typically non-explicit abstractions such as polymorphism have code generated for them that you don’t have explicit control over. C is consistently low level because that’s all you get. Down to direct access to addressing and RAM, the stack frame, etc. as with assembly.
  - pjmlp 9mo ago
    How do you do direct accessing to CPU registers in C as with Assembly? Being idiomatic or not doesn't matter, what counts are what language features are available.
    - Nevermark 9mo ago
      I am puzzled by the claim that C and assembly are not relatively close. Note here “close” being used in the injective, not bijective, sense. (Scratch out “one-to-one” in my earlier comment.) And “closer” lowers the bar here too. C isn’t simply decorated assembly. But closer to it. And “close” being used informally. Arguments for closeness are several and strong (I think), but a bit of a hodgepodge. In terms of non-bijectivity, for systems programming and performance choices C makes it easy to drop into assembly. But the former are uniquely application specific. And the latter doesn’t make the C version less like the assembly it maps onto - whether the compiler uses the more performant instructions for the context or not. C’s convenient assembly inlining, and the handoff in both directions being smoothed by an assembly friendly model of the C code around it, are both a part of the “closeness” But C is generally “close” to assembly, because its data types emphasize types handled natively, compound types reflect RAM layout, and pointers are explicit addresses to data and code. And those address values can be constructed and operated on just like any other data. C is objectively closer to assembly than languages with strongly required abstractions. (E.g., Java classes, Lisp S-exp's/cons cells, etc.) C is more “strictly closer” to assembly than languages with more optional abstractions, even if they also allow for relatively low level coding. Functions could be viewed as a preferred abstraction, but they have a clear assembly level model accessible directly with pointer arithmetic. And they don’t get in the way of directly encoding custom argument passing schemes, and using goto’s and zero argument functions and tail calls as atomic assembly calls for function and jumps for continuations. Types are a significant non-assembly abstraction, but are zero-cost in that they don't separate C from assembly, but C from C, as a code safety mechanism that is easily escaped. It is often easy to add abstractions, via regular C, or macros, but you have to provide an explicit implementation for them in the source or complied library. (However, if macros, with their mixed logical, symbol, text and file “data” model, are viewed as C source instead of as a C source construction language, then C becomes a very wacky abstraction language with behavior and rules that look nothing like simple assembly.)
      - jenadine 8mo ago
        > I am puzzled by the claim that C and assembly are not relatively close. Did anyone say that? I think the point is not that it is not "close", but that C is not equivalent to ASM: C has its own abstractions, and there are things you can do on assembly that you can't express in C. The other low level languages such as C++, Rust, Zig, ... are equally close since you can express the same things. In some respect they are even closer since they got more features builtins that modern assembly can now do that was not part of the design in C. (SIMD, threading, ...) Modern languages also have extra abstractions that makes programming easier without compromising on the cost. There are more abstractions than in C, but they also are optional. (Just like you could use goto instead of while or for loop, but you're happy this abstractions exist. We could also use functions pointer in C++ instead of virtual functions, but why would we if the language provide tools that make programming easier, for the same result)
- rramadass 8mo ago
  You keep making these sorts of comments on various threads which tells me that perhaps you are not clear on the idea of an "Abstract machine" which underpins all high-level languages. See my comment here for some references - https://news.ycombinator.com/item?id=46930253 https://news.ycombinator.com/item?id=46930253 The gap between the "C Abstract Machine" and the actual Hardware underneath is smaller than most other high-level languages. This comment by user haberman puts it very nicely - https://news.ycombinator.com/item?id=46910015 https://news.ycombinator.com/item?id=46910015

pjmlp 9mo ago

Lets play a game of what ISO C can do, and no other systems programming language has similar feature available? If language extensions to ISO C are allowed, then same goes for my selection on competing systems languages.

Nevermark 9mo ago
Yes, most languages allow C type code, if that’s what you are trying to do. Java with only primitive values, arrays, and classes only with fields and static methods. But that wouldn’t be idiomatic Java, so typically non-explicit abstractions such as polymorphism have code generated for them that you don’t have explicit control over. C is consistently low level because that’s all you get. Down to direct access to addressing and RAM, the stack frame, etc. as with assembly.
- pjmlp 9mo ago
  How do you do direct accessing to CPU registers in C as with Assembly? Being idiomatic or not doesn't matter, what counts are what language features are available.
  - Nevermark 9mo ago
    I am puzzled by the claim that C and assembly are not relatively close. Note here “close” being used in the injective, not bijective, sense. (Scratch out “one-to-one” in my earlier comment.) And “closer” lowers the bar here too. C isn’t simply decorated assembly. But closer to it. And “close” being used informally. Arguments for closeness are several and strong (I think), but a bit of a hodgepodge. In terms of non-bijectivity, for systems programming and performance choices C makes it easy to drop into assembly. But the former are uniquely application specific. And the latter doesn’t make the C version less like the assembly it maps onto - whether the compiler uses the more performant instructions for the context or not. C’s convenient assembly inlining, and the handoff in both directions being smoothed by an assembly friendly model of the C code around it, are both a part of the “closeness” But C is generally “close” to assembly, because its data types emphasize types handled natively, compound types reflect RAM layout, and pointers are explicit addresses to data and code. And those address values can be constructed and operated on just like any other data. C is objectively closer to assembly than languages with strongly required abstractions. (E.g., Java classes, Lisp S-exp's/cons cells, etc.) C is more “strictly closer” to assembly than languages with more optional abstractions, even if they also allow for relatively low level coding. Functions could be viewed as a preferred abstraction, but they have a clear assembly level model accessible directly with pointer arithmetic. And they don’t get in the way of directly encoding custom argument passing schemes, and using goto’s and zero argument functions and tail calls as atomic assembly calls for function and jumps for continuations. Types are a significant non-assembly abstraction, but are zero-cost in that they don't separate C from assembly, but C from C, as a code safety mechanism that is easily escaped. It is often easy to add abstractions, via regular C, or macros, but you have to provide an explicit implementation for them in the source or complied library. (However, if macros, with their mixed logical, symbol, text and file “data” model, are viewed as C source instead of as a C source construction language, then C becomes a very wacky abstraction language with behavior and rules that look nothing like simple assembly.)
    - jenadine 8mo ago
      > I am puzzled by the claim that C and assembly are not relatively close. Did anyone say that? I think the point is not that it is not "close", but that C is not equivalent to ASM: C has its own abstractions, and there are things you can do on assembly that you can't express in C. The other low level languages such as C++, Rust, Zig, ... are equally close since you can express the same things. In some respect they are even closer since they got more features builtins that modern assembly can now do that was not part of the design in C. (SIMD, threading, ...) Modern languages also have extra abstractions that makes programming easier without compromising on the cost. There are more abstractions than in C, but they also are optional. (Just like you could use goto instead of while or for loop, but you're happy this abstractions exist. We could also use functions pointer in C++ instead of virtual functions, but why would we if the language provide tools that make programming easier, for the same result)
rramadass 8mo ago
You keep making these sorts of comments on various threads which tells me that perhaps you are not clear on the idea of an "Abstract machine" which underpins all high-level languages. See my comment here for some references - https://news.ycombinator.com/item?id=46930253 https://news.ycombinator.com/item?id=46930253 The gap between the "C Abstract Machine" and the actual Hardware underneath is smaller than most other high-level languages. This comment by user haberman puts it very nicely - https://news.ycombinator.com/item?id=46910015 https://news.ycombinator.com/item?id=46910015