[dTal]

Maybe this was once true, but the hardware that C was designed for specifying the behavior of was a PDP-11. Nowadays you are programming an abstract C-ish virtual machine that provides certain semantic guarantees that don't necessarily map terribly well to the physical hardware. For example, if you write to a memory address, and then read from the memory address in the "next instruction", you expect the change to be immediate, even though the code is actually running on a pipeline that could be dozens of instructions deep, with several layers of cache between the core and system memory. So in a sense there's not really a qualitative difference between C and Fortran - they are both for specifying a sequence of operations on an abstract machine, relying on the compiler to implement that machine - and indeed modern optimizing C compilers actually provide very few guarantees about specific assembly instructions to be executed, happily rewriting or omitting code so long as it executes "as if" it ran on the C virtual machine.

See "C is not a low-level language" - https://queue.acm.org/detail.cfm?id=3212479

[theodorethomas]

I don't see how C can match Fortran's abstraction level and still reliably control hardware that uses memory-mapped I/O.

C, as an operating system implementation language, is trying to do something fundamentally different than Fortran.

You live by memory address, you die by memory address.

[PhilipRoman]

> For example, if you write to a memory address, and then read from the memory address in the "next instruction", you expect the change to be immediate

This would also be true for assembly, hardly a high level language

[lmm]

On modern CPUs assembly is a high level language (or rather, it's a language that doesn't have any of the advantages of traditional low-level languages, even if it also lacks the advantages of traditional high-level languages. Much like C)

[AnimalMuppet]

> you expect the change to be immediate, even though the code is actually running on a pipeline that could be dozens of instructions deep, with several layers of cache between the core and system memory.

I expect the hardware to handle cache coherency in that situation. What the compiler does should be irrelevant.

[dTal]

Right, but the point is that the hardware is still "meeting you halfway" to present the appearance of something which isn't actually happening. Those pointers in C aren't really "memory addresses" at all, they're keys in a key-value store managed by the hardware to preset the illusion of flat, contiguous memory, as mandated by the C programming model.

So maybe it's accurate to say that C is "more compatible" with real hardware, in the sense that its abstract machine is more isomorphic to what's really happening than Fortran's is. But it's not exactly "closer to hardware" in the way we might be tempted to think; it's more of a lingua franca that your processor happens to speak.

If you're still tempted to consider C "close to hardware", consider that you can compile the same code for a Z80 and a Threadripper. What hardware exactly are you controlling that's common to both?

[AnimalMuppet]

> as mandated by the C programming model.

As PhilipRoman said, this is also true of assembly (or any other programming language model[1]).

> If you're still tempted to consider C "close to hardware", consider that you can compile the same code for a Z80 and a Threadripper. What hardware exactly are you controlling that's common to both?

In both of them I can write to a memory-mapped I/O device, if it has one. I can write a custom memory allocator for a pool that I'm managing myself. I can't do either of those in Fortran or Javascript.

[1] Why does it have to be true of any other programming language model? Well, maybe I exaggerate slightly. But can you show me a (single threaded) programming language where "a = 1" does not mean that on the next line, a will be 1?

[kmstout]

> But can you show me a (single threaded) programming language where "a = 1" does not mean that on the next line, a will be 1?

MIPS I.

https://en.wikipedia.org/wiki/Delay_slot#Load_delay_slot

[gpderetta]

>But can you show me a (single threaded) programming language where "a = 1" does not mean that on the next line, a will be 1

Generally agree with your point, but just to play the devil's advocate, in a CPU with exposed pipeline and no interlocks, setting a register to a value doesn't guarantee that a following instruction reading from that register will see the last value written.