3 ms·

It's not normal in any other language that constant-folding in the compiler has different behavior than running an expression on the machine. C exists in a net

by titzer 2mo ago

It's not normal in any other language that constant-folding in the compiler has different behavior than running an expression on the machine. C exists in a nether world of being neither assembly nor high-level language. People only call it high level because in the 1970s, having blocks, loops, and functions was high level, compared to the SoTa machines available in the day, which were either programmed with assembler or some bespoke thing the manufacturer came up with.

thin_carapace 2mo ago
may I ask specifically what aspects of C lead to examples of quasi low level status such as the one you gave? I'd hazard a guess the C abstract machine is defined in a particular manner differentiable from say the JVM?
- titzer 2mo ago
  It has pointers and pointer arithmetic. Pointing into the stack, allocating buffers on the stack (and the resulting decades of stack smashing attacks that came with it). Most languages don't have an underlying model of a flat memory that you can just randomly point at and write things; they have objects and data types and functions that aren't meant to be pointed at (and usually cannot).
  - thin_carapace 2mo ago
    ah so other languages emulate harvard to a degree. I wonder if performance could improve by reimplementing a C like language based on a von neumann abstract machine inspired by something other than a PDP. thanks for your response
    - Dylan16807 2mo ago
      It's a similar distinction, but not really? Harvard is about separating code and data and C still does that with high reliability. Pointers and the stack and the important return addresses on the stack are all data. Strong barriers between different pieces of data are a different concern.
  - jstimpfle 2mo ago
    It isn't actually that flat in the spec, though modern machines' address spaces are. So in a sense it is merely an accident of a specific implementation that you can smash stacks.
    - titzer 2mo ago
      Yes, you are right in that programs are not supposed to point outside of allocated blocks into other regions, that's UB. As in, pointer arithmetic that computes pointers outside of (but not even accessing!) an allocated block is UB. Annoying, pointers can legally be put into integers, looked at (e.g. printed out as a hex value), and then reinterpreted back into pointers, so it more-or-less dictates flat addressing. E.g. it's basically not possible to make an implementation that would run most programs where pointers are unforgeable, relocatable things, because of this. All of this spec is post-hoc, so it's a nasty retcon job that papers over the old folk understanding of one flat address space that's more or less still there in every implementation.
      - jstimpfle 2mo ago
        Casting integers to pointers is implementation-defined as far as I know. Even if weren't, I'm not convinced that you have to interpret C's address space as flat just because it is finite or because pointers are representable as integers. In any case, machine's address spaces are flat (the physical memory mapped into them not so much), and working with real machines is what I'm interested in.
- im3w1l 2mo ago
  Well the title of this very post is about the ABI. The ABI provides some guarantees on what the compiler output will be. It guarantees that parameters will be read from certain registers and results will be written to other registers. Most languages do not offer such guarantees.
pjmlp 2mo ago
There are high level systems languages starting with JOVIAL in 1958 for the SAGE radar system. C only exists instead of the alternatives, because according to Dennis Ritchie himself it was more fun to create C than using something else, and I quote: "Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own." From https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist...
- tikitorch200 2mo ago
  Quote does not support the claim that the only reason C exists was that it more fun
  - pjmlp 2mo ago
    You read it your way, I read it my way. "All these languages influenced our work, but it was more fun to do things on our own"
    - tikitorch200 2mo ago
      I never really thought much about this quote before now, although presumably I had read it…interesting how humble Dennis Richie was
- AnimalMuppet 2mo ago
  That doesn't quite say what you claim. The choice was because the other languages were too large/complicated, not because of fun.
  - pjmlp 2mo ago
    "...but it was more fun to do things on our own."
p_l 2mo ago
Unix team developed C partially to regain a bit of the state of the art that they were excluded to earlier, with added constraint of being very small machine so they couldn't just fit a state of the art language without making complex multi pass compiler - not in 32kB of RAM
jstimpfle 2mo ago
But I assume that both on compiler and on machine, the evaluation is still conforming to the semantics of the C abstract machine?

by titzer 2mo ago

thin_carapace 2mo ago

may I ask specifically what aspects of C lead to examples of quasi low level status such as the one you gave? I'd hazard a guess the C abstract machine is defined in a particular manner differentiable from say the JVM?

titzer 2mo ago
It has pointers and pointer arithmetic. Pointing into the stack, allocating buffers on the stack (and the resulting decades of stack smashing attacks that came with it). Most languages don't have an underlying model of a flat memory that you can just randomly point at and write things; they have objects and data types and functions that aren't meant to be pointed at (and usually cannot).
- thin_carapace 2mo ago
  ah so other languages emulate harvard to a degree. I wonder if performance could improve by reimplementing a C like language based on a von neumann abstract machine inspired by something other than a PDP. thanks for your response
  - Dylan16807 2mo ago
    It's a similar distinction, but not really? Harvard is about separating code and data and C still does that with high reliability. Pointers and the stack and the important return addresses on the stack are all data. Strong barriers between different pieces of data are a different concern.
- jstimpfle 2mo ago
  It isn't actually that flat in the spec, though modern machines' address spaces are. So in a sense it is merely an accident of a specific implementation that you can smash stacks.
  - titzer 2mo ago
    Yes, you are right in that programs are not supposed to point outside of allocated blocks into other regions, that's UB. As in, pointer arithmetic that computes pointers outside of (but not even accessing!) an allocated block is UB. Annoying, pointers can legally be put into integers, looked at (e.g. printed out as a hex value), and then reinterpreted back into pointers, so it more-or-less dictates flat addressing. E.g. it's basically not possible to make an implementation that would run most programs where pointers are unforgeable, relocatable things, because of this. All of this spec is post-hoc, so it's a nasty retcon job that papers over the old folk understanding of one flat address space that's more or less still there in every implementation.
    - jstimpfle 2mo ago
      Casting integers to pointers is implementation-defined as far as I know. Even if weren't, I'm not convinced that you have to interpret C's address space as flat just because it is finite or because pointers are representable as integers. In any case, machine's address spaces are flat (the physical memory mapped into them not so much), and working with real machines is what I'm interested in.
im3w1l 2mo ago
Well the title of this very post is about the ABI. The ABI provides some guarantees on what the compiler output will be. It guarantees that parameters will be read from certain registers and results will be written to other registers. Most languages do not offer such guarantees.

pjmlp 2mo ago

There are high level systems languages starting with JOVIAL in 1958 for the SAGE radar system. C only exists instead of the alternatives, because according to Dennis Ritchie himself it was more fun to create C than using something else, and I quote: "Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own." From https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist...

tikitorch200 2mo ago
Quote does not support the claim that the only reason C exists was that it more fun
- pjmlp 2mo ago
  You read it your way, I read it my way. "All these languages influenced our work, but it was more fun to do things on our own"
  - tikitorch200 2mo ago
    I never really thought much about this quote before now, although presumably I had read it…interesting how humble Dennis Richie was
AnimalMuppet 2mo ago
That doesn't quite say what you claim. The choice was because the other languages were too large/complicated, not because of fun.
- pjmlp 2mo ago
  "...but it was more fun to do things on our own."

p_l 2mo ago

Unix team developed C partially to regain a bit of the state of the art that they were excluded to earlier, with added constraint of being very small machine so they couldn't just fit a state of the art language without making complex multi pass compiler - not in 32kB of RAM

jstimpfle 2mo ago

But I assume that both on compiler and on machine, the evaluation is still conforming to the semantics of the C abstract machine?