Hacker News Reader

Comment by titzer | Hacker News Reader

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.

View on HN

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...

Quote does not support the claim that the only reason C exists was that it more fun

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"

I never really thought much about this quote before now, although presumably I had read it…interesting how humble Dennis Richie was

That doesn't quite say what you claim. The choice was because the other languages were too large/complicated, not because of fun.

"...but it was more fun to do things on our own."

"..simpler and smaller.."

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

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

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?

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).

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.

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.

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.

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

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.

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.

Reply on news.ycombinator.com