6 ms·

No but C is a better model of most processors assembly, than most other procedural languages.

masklinn 4y ago
Not sure how that is relevant. The GP asserts (and bemoans) the reverse cause-and-effect.
pjmlp 4y ago
Only when we are talking about PDP-11. Thankfully nowadays we have Compiler Explorer supporting almost every flavour of mainstream compiled languages to dispel myths.
- Nevermark 4y ago
  Unless you know a widely used high level language that is is a better model of newer assembly, then C would still remain “the best”, no? “Not as good lately”, doesn’t change that status without another language superseding it, right?
- flohofwoe 4y ago
  This PDP-11 vs C thing always seems to come down to the PDP-11's auto-increment addressing modes vs C's ++ and --. Are there are any other PDP-11 features baked into C? Because this increment/decrement thing is hardly unique (the 68k CPUs had that too, and every CPU with a stack pointer also does it, some CPUs just made that a general addressing mode accessible in the instruction set. While today's compiler do a lot more transformations which can result in surprising output, it's still fairly straightforward to map C statements to CPU instructions.
  - pjmlp 4y ago
    How do you map C statements to AVX512 instructions?
    - flohofwoe 4y ago
      ...by doing the only sensible thing and use intrinsics. Auto-vectorisation is exactly where compiler optimisations stop being useful.
      - pjmlp 4y ago
        On which page of ISO C can I find the intrinsics specification?
        junon 4y ago
        Not sure what your point is. There are no instruction-level parts to the standard. The C standard doesn't dictate how individual CPUs should operate.
        tsimionescu 4y ago
        The point is that C is very far away from being a "portable assembly" for any kind of modern processor. For the PDP-11 and other processors from that era, there was indeed some pretty simple 1:1 mapping between C instructions and their assembly. This has not been true for decades.
        MereInterest 4y ago
        The point is in reference to flohofwoe's earlier comment which stated "it's still fairly straightforward to map C statements to CPU instructions.". By pointing out the existence of vectorized instructions, which are entirely absent from the C standard, pjmlp was making an argument by counter-example. That while you can map C statements to CPU instructions, most compilers typically don't apply such a 1-1 mapping. The seeming non-sequitur referring to the ISO C standard was because flohofwoe responded to the rhetorical question as if it were a normal question, leading pjmlp to restate the rhetorical question in a stronger form.
        flohofwoe 4y ago
        The C standard only matters for compiler writers. What matters for compiler users is what specific compilers actually implement (and it's pretty much impossible to write a non-trivial C program which is 100% standard compliant, the Windows headers alone are full of MSVC idiosyncrasies).
  - msla 4y ago
    Autoincrement and autodecrement didn't come from the PDP-11 https://web.archive.org/web/19980220175804/http://cm.bell-labs.com/cm/cs/who/dmr/chist.html https://web.archive.org/web/19980220175804/http://cm.bell-la... > People often guess that they were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first became popular. This is historically impossible, since there was no PDP-11 when B was developed. The PDP-7, however, did have a few `auto-increment' memory cells, with the property that an indirect memory reference through them incremented the cell. This feature probably suggested such operators to Thompson; the generalization to make them both prefix and postfix was his own. Indeed, the auto-increment cells were not used directly in implementation of the operators, and a stronger motivation for the innovation was probably his observation that the translation of ++x was smaller than that of x=x+1. --- Dennis Ritchie
  - tsimionescu 4y ago
    The point is that C maps quite poorly onto the ISAs of most processors other than a PDP-11. There are various features of even 8086 that are not easily available in C (such as overflow detection) and huge numbers of instructions in newer ISAs that don't have any direct mapping to C code. Additionally, modern processors have execution models that are entirely different from the C machine model, but this is often hidden even from the ISA. For example, modern x86-64 cores execute code by splitting up instructions into micro-instructions, determining data dependencies between them, then queueing them up on any of the available execution units (of various kinds) in parallel - which is about as far from the C model of executing instructions 1 by 1 in a series as it is from Haskell.
    - flohofwoe 4y ago
      Well from the pov of machine or assembly code, C is without a doubt a high level language. But at the same time it's the lowest-level high-level language (that's popular at least). I'm also not aware of any high level programming languages that allow access to the CPUs status flags (for instance to check for overflow). (there are a couple of interesting 'mid-level' languages for 8-bit processors though, like Millfork: https://github.com/KarolS/millfork https://github.com/KarolS/millfork) I'd be all over a proper mid-level language that's closer to modern CPUs than C and has less 'optimization magic'. But this idea doesn't seem to be very popular amongst the compiler writer crowd.

Not sure how that is relevant. The GP asserts (and bemoans) the reverse cause-and-effect.

Only when we are talking about PDP-11. Thankfully nowadays we have Compiler Explorer supporting almost every flavour of mainstream compiled languages to dispel myths.

Nevermark 4y ago
Unless you know a widely used high level language that is is a better model of newer assembly, then C would still remain “the best”, no? “Not as good lately”, doesn’t change that status without another language superseding it, right?
flohofwoe 4y ago
This PDP-11 vs C thing always seems to come down to the PDP-11's auto-increment addressing modes vs C's ++ and --. Are there are any other PDP-11 features baked into C? Because this increment/decrement thing is hardly unique (the 68k CPUs had that too, and every CPU with a stack pointer also does it, some CPUs just made that a general addressing mode accessible in the instruction set. While today's compiler do a lot more transformations which can result in surprising output, it's still fairly straightforward to map C statements to CPU instructions.
- pjmlp 4y ago
  How do you map C statements to AVX512 instructions?
  - flohofwoe 4y ago
    ...by doing the only sensible thing and use intrinsics. Auto-vectorisation is exactly where compiler optimisations stop being useful.
    - pjmlp 4y ago
      On which page of ISO C can I find the intrinsics specification?
      - junon 4y ago
        Not sure what your point is. There are no instruction-level parts to the standard. The C standard doesn't dictate how individual CPUs should operate.
        tsimionescu 4y ago
        The point is that C is very far away from being a "portable assembly" for any kind of modern processor. For the PDP-11 and other processors from that era, there was indeed some pretty simple 1:1 mapping between C instructions and their assembly. This has not been true for decades.
        MereInterest 4y ago
        The point is in reference to flohofwoe's earlier comment which stated "it's still fairly straightforward to map C statements to CPU instructions.". By pointing out the existence of vectorized instructions, which are entirely absent from the C standard, pjmlp was making an argument by counter-example. That while you can map C statements to CPU instructions, most compilers typically don't apply such a 1-1 mapping. The seeming non-sequitur referring to the ISO C standard was because flohofwoe responded to the rhetorical question as if it were a normal question, leading pjmlp to restate the rhetorical question in a stronger form.
      - flohofwoe 4y ago
        The C standard only matters for compiler writers. What matters for compiler users is what specific compilers actually implement (and it's pretty much impossible to write a non-trivial C program which is 100% standard compliant, the Windows headers alone are full of MSVC idiosyncrasies).
- msla 4y ago
  Autoincrement and autodecrement didn't come from the PDP-11 https://web.archive.org/web/19980220175804/http://cm.bell-labs.com/cm/cs/who/dmr/chist.html https://web.archive.org/web/19980220175804/http://cm.bell-la... > People often guess that they were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first became popular. This is historically impossible, since there was no PDP-11 when B was developed. The PDP-7, however, did have a few `auto-increment' memory cells, with the property that an indirect memory reference through them incremented the cell. This feature probably suggested such operators to Thompson; the generalization to make them both prefix and postfix was his own. Indeed, the auto-increment cells were not used directly in implementation of the operators, and a stronger motivation for the innovation was probably his observation that the translation of ++x was smaller than that of x=x+1. --- Dennis Ritchie
- tsimionescu 4y ago
  The point is that C maps quite poorly onto the ISAs of most processors other than a PDP-11. There are various features of even 8086 that are not easily available in C (such as overflow detection) and huge numbers of instructions in newer ISAs that don't have any direct mapping to C code. Additionally, modern processors have execution models that are entirely different from the C machine model, but this is often hidden even from the ISA. For example, modern x86-64 cores execute code by splitting up instructions into micro-instructions, determining data dependencies between them, then queueing them up on any of the available execution units (of various kinds) in parallel - which is about as far from the C model of executing instructions 1 by 1 in a series as it is from Haskell.
  - flohofwoe 4y ago
    Well from the pov of machine or assembly code, C is without a doubt a high level language. But at the same time it's the lowest-level high-level language (that's popular at least). I'm also not aware of any high level programming languages that allow access to the CPUs status flags (for instance to check for overflow). (there are a couple of interesting 'mid-level' languages for 8-bit processors though, like Millfork: https://github.com/KarolS/millfork https://github.com/KarolS/millfork) I'd be all over a proper mid-level language that's closer to modern CPUs than C and has less 'optimization magic'. But this idea doesn't seem to be very popular amongst the compiler writer crowd.