4 ms·

What would you say C is beyond the high-level assembler ? genuinely curious (i kinda hold that belief personally but i'm not a c programmer by trade)

_kst_ 11mo ago
I see a huge semantic gap between assembly language and C. An assembly language program specifies a sequence of CPU instructions. The mapping between lines of code and generated instructions is one-to-one, or nearly so. A C program specifies run-time behavior, without regard to what CPU instructions might be used to achieve that. C is at a lower level than a lot of other languages, but it's not an assembly language.
- vnorilo 11mo ago
  And yet modern assembly does not correspond 1:1 to the micro-ops the CPU runs or even necessarily the order in which they run. Both ISA-level assembly and C are targeting an abstract machine model, even if the former is somewhat further removed from hardware reality.
  - IshKebab 11mo ago
    > And yet modern assembly does not correspond 1:1 to the micro-ops the CPU runs or even necessarily the order in which they run. Nobody claimed that. It corresponds to the instructions the CPU runs and their observable order. Also it's really only x86 that uses micro-ops (in the way that you mean), and there are still plenty of in-order CPUs.
    - vnorilo 11mo ago
      sure, I was thinking of large OO cores. "Correspondd to the instructions the cpu runs and their observable order" is how I'd characterize C as well, but to each their own.
  - arghwhat 11mo ago
    Java also targets an abstract machine model (JVM) - such statement really doesn't mean much. Assembly is not about corresponding to exactly which gates open when in the CPU. It's just the human writable form of whatever the CPU ingests, whereas C is an early take on a language reasonable capable of expressing higher level ideas with less low-level noise. I seriously doubt anyone who has written projects in assembly would make such comparisons...
    - vnorilo 11mo ago
      >I seriously doubt anyone who has written projects in assembly would make such comparisons... With genuine respect, I believe this type of insinuation is rarely productive. Someone might still have silly opinions, even if they have been paid to write assembly for 8-24-64 bit cisc, risc, ordered and out of order ISAs, and maybe compilers too. Peace :)
      - arghwhat 11mo ago
        Yes but someone might also have silly opinions from having no experience how production assembly actually looks, such as underestimating just how different working with that is to working in high-level languages like C and why such languages were quite revolutionary. :) This should not be mistaken as appeal to authority, it is merely reasonable discrimination between those speaking from experience, and those forming opinions without experience. If one believes those with experience has poorly informed opinions, they're always free to gain experience and associated perspective. They will then either have the fundamentals to properly push their viewpoint, or end up better understanding and aligning with the common viewpoint.
  - flohofwoe 11mo ago
    > And yet modern assembly does not correspond 1:1 to the micro-ops the CPU runs or even necessarily the order in which they run. It's still much closer to the input machine code compared to what compiler optimizer passes do to your input C code ;)
    - vnorilo 11mo ago
      I have empathy for this having written compiler passes for 10ish years of my career. But as I've studied register renaming, speculative branch prediction and trace caches I would no longer agree with your last sentence. It's fine though, totally just an opinion.
  - cylemons 11mo ago
    Sure but from software POV assembly is the lowest level you can target
    - jcelerier 11mo ago
      Yes and no, you can use c in situations where there's no "assembly", for instance when synthesizing FPGAs. You target flow graphs directly in that case IIRC.
    - torstenvl 11mo ago
      Which assembly? Assembly with macros? Assembly with synthetic instructions? If you use mov %i0, %l0 instead of or %g0, %i0, %l0 Then that isn't "the lowest level you can target."
      - cylemons 11mo ago
        I was thinking of x86 when I wrote that, also I am not sure macros count as an abstraction level since they are just preprocessors? What I meant to say is that since there is no way to directly write microcode, assembly is the lowest level software can target.
AlotOfReading 11mo ago
C is a programming language. It makes for a very shitty high level assembler. Here's a trivial example clang will often implement differently on different systems, producing two different results. Clang x64 will generally mul+add, while clang arm64 is aggressive about fma. x = 3.0f*x+1.0f; But that's just the broad strategy. Depending on the actual compiler flags, the assembly generated might include anything up to multiple function calls under the hood (sanitizers, soft floats, function profiling, etc).
- torstenvl 11mo ago
  I don't think clang is being "aggressive" on ARM, it's just that all aarch64 targets support fma. You'll get similar results with vfmadd213ss on x86-64 with -march=haswell (13 years old at this point, probably a safe bet). float fma(float x) { return 3.0f * x + 1.0f; } Clang armv8 21.1.0: fma(float): sub sp, sp, #16 str s0, [sp, #12] ldr s1, [sp, #12] fmov s2, #1.00000000 fmov s0, #3.00000000 fmadd s0, s0, s1, s2 add sp, sp, #16 ret Clang x86-64 21.1.0: .LCPI0_0: .long 0x3f800000 .LCPI0_1: .long 0x40400000 fma(float): push rbp mov rbp, rsp vmovss dword ptr [rbp - 4], xmm0 vmovss xmm1, dword ptr [rbp - 4] vmovss xmm2, dword ptr [rip + .LCPI0_0] vmovss xmm0, dword ptr [rip + .LCPI0_1] vfmadd213ss xmm0, xmm1, xmm2 pop rbp ret
  - AlotOfReading 11mo ago
    The point is that there are multiple, meaningfully different implementations for the same line, not that either is wrong. Sometimes compilers will even produce both implementations and call one or the other based on runtime checks, as this ICC example does: https://godbolt.org/z/KnErdebM5 https://godbolt.org/z/KnErdebM5
    - torstenvl 11mo ago
      I don't understand the argument you're trying to make. You seem to be arguing that C isn't a high-level assembler because some compilers generate different machine code for the same source code. But (a) that doesn't contradict the claim in any way; and (b) this happens in assembly all the time too—some synthetic instructions generate different machine code depending on circumstances.
flohofwoe 11mo ago
Look at the compiler assembly output after optimization kicks in. The resulting assembly code is usually significantly different from the input source code. With modern optimizer passes, C is much closer to any other high level programming language than to handwritten assembly code.
pjmlp 11mo ago
This was only the case when the machine code generated from C compilers was almost 1:1 to PDP-11, or similar 16 bit home computers. Since optmizing compilers became a thing in the C world, and the WG14 never considered modern CPU architectures on what hardware features C should expose, this idea lost meaning. However many people hold on to old beliefs that C is still the same kind of C that they learnt with the first edition of K&R C book. This ACM article might be interesting to you, https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479 Before dismissing it as the author having no idea what he is talking about, David Chisnall used to be a GCC contributor, one of the main GNUStep contributors back in the original days, and one of the key researchers behind the CHERI project.
- mpweiher 11mo ago
  David is quite accomplished, but in this instance he is simply wrong. For two reasons: 1. All the reasons he cites that depend on "what the metal does" being different and quite a bit more complex than what is surfaced in C apply equally to machine/assembly language. So the CPU's instruction set is not a low-level language? Interesting take, but I don't think so: it is the lowest level language that is exposed by the CPU. 2. The other reasons boil down to "I would like to do this optimization", and that is simply inapplicable.

_kst_ 11mo ago

I see a huge semantic gap between assembly language and C. An assembly language program specifies a sequence of CPU instructions. The mapping between lines of code and generated instructions is one-to-one, or nearly so. A C program specifies run-time behavior, without regard to what CPU instructions might be used to achieve that. C is at a lower level than a lot of other languages, but it's not an assembly language.

vnorilo 11mo ago
And yet modern assembly does not correspond 1:1 to the micro-ops the CPU runs or even necessarily the order in which they run. Both ISA-level assembly and C are targeting an abstract machine model, even if the former is somewhat further removed from hardware reality.
- IshKebab 11mo ago
  > And yet modern assembly does not correspond 1:1 to the micro-ops the CPU runs or even necessarily the order in which they run. Nobody claimed that. It corresponds to the instructions the CPU runs and their observable order. Also it's really only x86 that uses micro-ops (in the way that you mean), and there are still plenty of in-order CPUs.
  - vnorilo 11mo ago
    sure, I was thinking of large OO cores. "Correspondd to the instructions the cpu runs and their observable order" is how I'd characterize C as well, but to each their own.
- arghwhat 11mo ago
  Java also targets an abstract machine model (JVM) - such statement really doesn't mean much. Assembly is not about corresponding to exactly which gates open when in the CPU. It's just the human writable form of whatever the CPU ingests, whereas C is an early take on a language reasonable capable of expressing higher level ideas with less low-level noise. I seriously doubt anyone who has written projects in assembly would make such comparisons...
  - vnorilo 11mo ago
    >I seriously doubt anyone who has written projects in assembly would make such comparisons... With genuine respect, I believe this type of insinuation is rarely productive. Someone might still have silly opinions, even if they have been paid to write assembly for 8-24-64 bit cisc, risc, ordered and out of order ISAs, and maybe compilers too. Peace :)
    - arghwhat 11mo ago
      Yes but someone might also have silly opinions from having no experience how production assembly actually looks, such as underestimating just how different working with that is to working in high-level languages like C and why such languages were quite revolutionary. :) This should not be mistaken as appeal to authority, it is merely reasonable discrimination between those speaking from experience, and those forming opinions without experience. If one believes those with experience has poorly informed opinions, they're always free to gain experience and associated perspective. They will then either have the fundamentals to properly push their viewpoint, or end up better understanding and aligning with the common viewpoint.
- flohofwoe 11mo ago
  > And yet modern assembly does not correspond 1:1 to the micro-ops the CPU runs or even necessarily the order in which they run. It's still much closer to the input machine code compared to what compiler optimizer passes do to your input C code ;)
  - vnorilo 11mo ago
    I have empathy for this having written compiler passes for 10ish years of my career. But as I've studied register renaming, speculative branch prediction and trace caches I would no longer agree with your last sentence. It's fine though, totally just an opinion.
- cylemons 11mo ago
  Sure but from software POV assembly is the lowest level you can target
  - jcelerier 11mo ago
    Yes and no, you can use c in situations where there's no "assembly", for instance when synthesizing FPGAs. You target flow graphs directly in that case IIRC.
  - torstenvl 11mo ago
    Which assembly? Assembly with macros? Assembly with synthetic instructions? If you use mov %i0, %l0 instead of or %g0, %i0, %l0 Then that isn't "the lowest level you can target."
    - cylemons 11mo ago
      I was thinking of x86 when I wrote that, also I am not sure macros count as an abstraction level since they are just preprocessors? What I meant to say is that since there is no way to directly write microcode, assembly is the lowest level software can target.

AlotOfReading 11mo ago

C is a programming language. It makes for a very shitty high level assembler. Here's a trivial example clang will often implement differently on different systems, producing two different results. Clang x64 will generally mul+add, while clang arm64 is aggressive about fma. x = 3.0f*x+1.0f; But that's just the broad strategy. Depending on the actual compiler flags, the assembly generated might include anything up to multiple function calls under the hood (sanitizers, soft floats, function profiling, etc).

torstenvl 11mo ago
I don't think clang is being "aggressive" on ARM, it's just that all aarch64 targets support fma. You'll get similar results with vfmadd213ss on x86-64 with -march=haswell (13 years old at this point, probably a safe bet). float fma(float x) { return 3.0f * x + 1.0f; } Clang armv8 21.1.0: fma(float): sub sp, sp, #16 str s0, [sp, #12] ldr s1, [sp, #12] fmov s2, #1.00000000 fmov s0, #3.00000000 fmadd s0, s0, s1, s2 add sp, sp, #16 ret Clang x86-64 21.1.0: .LCPI0_0: .long 0x3f800000 .LCPI0_1: .long 0x40400000 fma(float): push rbp mov rbp, rsp vmovss dword ptr [rbp - 4], xmm0 vmovss xmm1, dword ptr [rbp - 4] vmovss xmm2, dword ptr [rip + .LCPI0_0] vmovss xmm0, dword ptr [rip + .LCPI0_1] vfmadd213ss xmm0, xmm1, xmm2 pop rbp ret
- AlotOfReading 11mo ago
  The point is that there are multiple, meaningfully different implementations for the same line, not that either is wrong. Sometimes compilers will even produce both implementations and call one or the other based on runtime checks, as this ICC example does: https://godbolt.org/z/KnErdebM5 https://godbolt.org/z/KnErdebM5
  - torstenvl 11mo ago
    I don't understand the argument you're trying to make. You seem to be arguing that C isn't a high-level assembler because some compilers generate different machine code for the same source code. But (a) that doesn't contradict the claim in any way; and (b) this happens in assembly all the time too—some synthetic instructions generate different machine code depending on circumstances.

flohofwoe 11mo ago

Look at the compiler assembly output after optimization kicks in. The resulting assembly code is usually significantly different from the input source code. With modern optimizer passes, C is much closer to any other high level programming language than to handwritten assembly code.

pjmlp 11mo ago

This was only the case when the machine code generated from C compilers was almost 1:1 to PDP-11, or similar 16 bit home computers. Since optmizing compilers became a thing in the C world, and the WG14 never considered modern CPU architectures on what hardware features C should expose, this idea lost meaning. However many people hold on to old beliefs that C is still the same kind of C that they learnt with the first edition of K&R C book. This ACM article might be interesting to you, https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479 Before dismissing it as the author having no idea what he is talking about, David Chisnall used to be a GCC contributor, one of the main GNUStep contributors back in the original days, and one of the key researchers behind the CHERI project.

mpweiher 11mo ago
David is quite accomplished, but in this instance he is simply wrong. For two reasons: 1. All the reasons he cites that depend on "what the metal does" being different and quite a bit more complex than what is surfaced in C apply equally to machine/assembly language. So the CPU's instruction set is not a low-level language? Interesting take, but I don't think so: it is the lowest level language that is exposed by the CPU. 2. The other reasons boil down to "I would like to do this optimization", and that is simply inapplicable.