>You may have heard another slogan when talking about C: “C is portable assembler.” If you think about this slogan for a minute, you’ll also find that if it’s true, C cannot be how the computer works: there are many kinds of different computers, with different architectures

As with many things, this phrase is an approximation. C is a portable implementation of many useful behaviors which map reasonably closely to tasks commonly done on most instruction sets. C programmers rarely write assembly to optimize (usually to capture those arch-specific features which are unrepresentable in C), but programmers in other languages often reach for C to write the high-performance parts of their code. The same reason C programmers in the early days would reach for assembly is now the reason higher-level programmers reach for C.

This I agree with and also I'd call the most important reason for Rust programmers to learn C. The C ABI is a lingua franca, not because it's good or pure but (as with spoken linguas franca) happened to be in the right place at the right time. It defines certain conventions and assumptions that didn't have to be assumed (implicit stack growth without declared bounds, single return value, NUL-terminated strings, etc.) and a lot of software is written to it, to the point that if you want your (e.g.) Python code and Rust code to interoperate, the easiest way is to get them to both speak C-compatible interfaces, even though you're not writing any actual C code.

ABI = Application Binary Interface

https://en.wikipedia.org/wiki/Application_binary_interface

https://upload.wikimedia.org/wikipedia/commons/b/bb/Linux_AP...

C and libc have been ABI-stable on most platforms for decades. C++ on some platforms (e.g., GNU) is stable with occasional ABI breakages in the standard library; on others (e.g., MS Visual C++) it breaks with new compiler versions. Rust isn't ABI-stable at all and has no clear plans for it, despite a strong commitment to API stability (i.e., old code will compile on new compiler versions). Swift 5 is targeting ABI stability.

For convenience, many architectures have a single assembly instruction for taking one register (called the "stack pointer"), adjusting it by a word, and moving a register to the address at that word, and a corresponding instruction to move data back to a register and adjust it in the other direction. That's the extent of the abstraction. You can implement it with two instructions instead of one, and then you get as many stack pointers as you want. Zero, if you want.

There is no "heap" on modern OSes. There used to be a thing called the program break, beyond which was the heap. It's almost meaningless now. You ask for an area of virtual memory via mmap or equivalent; it is now one of several heaps you have.

And you can pass around pointers from all your stacks and all your heaps in the same ways, as long as they remain valid.

You need to understand this in order to understand how thread stacks work (you typically allocate them via mmap or from "the heap"); how sigaltstack works and why you need it to catch SIGSEGV from stack oveflows; how segmented stacks (as previously used in Go and Rust) work; how Stackless Python works; how to share data structures between processes; etc.

Since this is a distinction that is very important both for performance in high-level languages and for correctness in C, and one C forces you to think about and makes plain without having to reason through escape analysis and closures, I think the previous comment's point is well taken.

Consider, say, shadow stacks- local variables might end up living on a totally separate "stack" from the one "call" pushes onto and "ret" pops from, and one which the ISA has no idea about.

PUSH/POP are more obviously "hey store your locals on the stack, kids", but on, say, x64, how often do you actually see a push instead of bp/sp-relative addressing? Most compilers seem to be much happier representing each stack frame as "a bunch of slots, some for things where the address is taken so it needs to be in memory, and others where I spill things into as needed".

On ARMv7 (i don't know enough about v8 / AARCH64), "push"/"pop" are just stores/loads with postdecrement / postincrement.

Is this lawyer-y? Sure. But I think it's still correct, and this being HN...

It's much more optimal to use a series of push/pops for smaller operations like saving registers before a call than to manually adjust and store onto the stack.

While technically this is still incrementing/decrementing a register and storing, the amount of isa/hardware support for such things clearly demonstrates that the x86 isa and modern x86 hardware gives special treatment to the stack.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

There are no occurrences of the words "stack" or "heap" in this document.

What the spec actually discusses is "storage durations". Now, in many cases you can say, well, "automatic storage duration" means it's on the stack, but that's not something C has any opinions about.

If you want to know about the stack and the heap, saying "learn C, and then learn how these abstract C concepts map onto the stack and the heap" might not actually be the best way to figure this stuff out.

What actually ends up happening, in my experience, is that to figure C out you have to get a decent mental model of how the stack and heap work, and then, from that, say "automatic storage duration and malloc/free are basically just the stack and the heap".

I learned calculus as a kid because I needed it for an online electronics class I was taking. But I'm not going to recommend that folks take electronics classes so they learn calculus! (that said- having a motivation to learn something, having an application in mind, a problem you want to solve... certainly seems to make learning easier.)

The semantics of automatic storage necessarily imply #1, but they do not require #2. Indeed, there are widely used implementations which implement #1 using linked lists (e.g. IBM mainframes, and GCC's split stacks or clang's segmented stacks).

Similarly, function recursion semantics necessarily imply #1 for restoring execution flow, but not #2. In addition to the examples above, so-called shadow stacks are on the horizon which maintain two separate stacks, one for function return addresses and another for data.[1] In the near future a single contiguous stack may be atypical.

[1] Some variations might mix data and return addresses if the compiler can prove safe object access. Or the shadow stack may simply contain checksums or other auxiliary information that can be optionally used, preserving ABI compatibility.

[1] https://arcanesentiment.blogspot.com/2014/12/customary-seman...

Oddly you seem to recognize this, so I’m not sure what your point is.

's funny, I am certainly aware of having, at some point, at least skimmed over the C99 standard encountered the concept of a storage duration. But, aside from that brief few hours, virtually the entirety of my C-knowing career has been spent thinking and talking in terms of stacks and heaps.

Meanwhile, in my .NET career, I really did (and, I guess, still do) feel like it was important to keep track of how .NET's distinction is between reference types and value types, and whether or not they were stack or heap allocated was an implementation detail.

I'm not even sure the C memory model depends on the code/stack/heap separation.

Modern languages solve problems created developing in legacy languages (primarily C). The issue is that knowing a solution without knowing the prior problem which the solution addresses, doesn't really lend itself to clarity.

Point is that out of context, a lot of the things modern languages provide seem superfluous. Why have objects? Why have templates, closures, or lambdas? For a novice programmer, these are many answers for questions yet to be asked.

When you come from a heavy C background and you encounter something like templates, you know EXACTLY what this is for and wish you had it years ago.

I'm as hardcore as they get C programmer and I'm having a ball with C# for this very reason.

Yet we often see passionate arguments in its favor, as for instance from Sústrik (http://250bpm.com/blog:56) and Tatham (https://www.chiark.greenend.org.uk/~sgtatham/mp/) and a person on the internet who recommends replacing LAPACK with preprocessor macros (http://wordsandbuttons.online/outperforming_lapack_with_c_me...). Would you care to comment on its enduring popularity?

C does have a lot of it, and it can be anywhere. In many languages, you can cause undefined behavior through its FFI. Some languages, like Rust, have UB, but only in well-defined places (a module containing unsafe code, in its case).

I do take your point about Rust, but I'd see that as deriving from LLVM's undefined behaviour which in turn descends from C; I'm not aware of any pre-C languages having C-style exploding undefined behaviour or of any subsequent languages inventing it independently.

That is fair, however, I don't think it's inherently due to C. Yes, most languages use the C ABI for FFI, but that doesn't mean they have to; it's a more general problem when combining two systems, they cannot track statically the guarantees of the other system.

With Rust, it has nothing to do with LLVM; it has to do with the fact that we cannot track things, that's why it's unsafe! Even if an implementation of the language does not use LLVM, we will still have UB.

I can see that any implementation of unsafe Rust would always have assembly-like unsafeness (e.g. reading an arbitrary memory address might result in an arbitrary value, or segfault). But I don't see why you would need C-style "arbitrary lines before and after the line that will not execute, reads from unrelated memory addresses will return arbitrary values" UB?

> I don't see why you would need C-style "arbitrary lines before and after the line that will not execute, reads from unrelated memory addresses will return arbitrary values" UB

This reason this happens is because we don't compile things down to obvious assembly, they get optimized. Each of those optimizations requires assumptions to be made about the the code. If you break those assumptions, then the optimizations can result in arbitrary results happening. Those assumptions determine what is and isn't UB.

Most languages just don't give the programmer any way to break those assumptions, but languages like C and Rust do. Thus, Rust will always have this 'problem' because it can/will make even more aggressive optimizations then C will, meaning badly written `unsafe` code will have arbitrary behavior and results from the optimizer if the compiler doesn't understand what you're doing.

The reason to have it is the exact same reason that the distinction between "implementation defined" and "undefined" exists in the first place: UB allows compilers to assume that it will never happen, and optimized based on it. That is a useful property, but it's a tradeoff, of course.

FFI isn't into "C", it's into your operating system's binary format. And since no two systems behave the same, it's UB however you look at it.

Most people call that format "the C ABI," and "FFI into C" is short for "FFI via the C ABI."

> And since no two systems behave the same, it's UB however you look at it.

That's not what UB means. It would be implementation defined, not undefined.

The reason that a spec is taking so long is that we're interested in making an ironclad, really good spec. Formal methods take time. C and C++ did not have specs for much, much longer than the three years that Rust has existed. We'll get there.

You are right that we are far, but that’s because it’s a monumental task, and it’s fundamentally unfair to expect equivalence from a young language. It is fair to say that it is a drawback.

It doesn't have to be a monumental task. Rust is simply too big, and getting bigger.

Specs are always a monumental task. The first C spec took six years to make in the first place!

If 99% of what that person does is gluing together APIs and software modules, and they can see their memory usages are well within range, why does it matter?

Without being able to refer to fundamental structures and concepts, I usually just exclusively teach students non-mutable patterns (e.g. list.sorted vs list.sort), while pushing them to become much proactive at inspecting and debugging.

if you're just going to move couches around and put down throw pillows, who cares about a solid foundation of design fundamentals and architectural psychology.

(I kept this post vague but can offer concrete examples of you'd like)

Go does that too. C teaches manual memory allocation, de-allocation and pointer arithmetic as well.

There are significant performance and strategy differences between the stack and the heap. On the stack, allocation is cheap, deallocation is free and automatic, fragmentation is impossible, the resource is limited, and the lifetime is lexically scoped.

On the heap, allocation might be cheap or it might be expensive, deallocation might be cheap or it might be expensive, fragmentation is a risk, the resource is 'unlimited', and the lifetime is unscoped.

Your statement is equivalent to saying "there's no difference between pointers and integers" - technically, they are both just numbers that live in registers or somewhere in memory. In reality, that approach will not get you far in computer science.

By all means it's certainly a valuable abstraction, one that most high-level languages support. But that's like how functions are a valuable abstraction, or objects, or key-value stores, or Berkeley sockets. Learning those abstractions is absolutely important and also completely irrelevant to understanding "the computer".

(As Dijkstra once said, computer science is no more about computers than astronomy is about telescopes. Learning C is valuable for computer science, but that doesn't mean it gives you a deep understanding of the computer itself.)

No, because in reality those are handled by different computational units. Integers are handled by the ALU, and pointers are handled by the loader. They are distinct things to the CPU.

Stack & heap have no such distinction. There isn't even a heap in the first place. There's as many heaps of as many sizes as you want, as the "heap" concept is an abstraction over memory (strictly speaking over virtual address space - another concept C won't teach you, yet is very important for things like mmap). It's not a tangible thing to the computer.

Same with the stack. It's why green-threads work, because the stack is simply an abstraction over memory.

I strongly disagree. Yes some execution units are more let's say "dedicated" to pointers than other, and obviously ultimately you will dereference your pointers, so you will load/store, but compilers happily emit lea to do e.g. Ax9+B and in the other direction, add or sub on pointers. Some ISA even have almost no pointer "oriented" register (and even x64 has very few)

Although, it sounds like you're agreeing with me that there is in fact a difference between the stack and the heap because to your point one exists supported at the hardware level with instructions and registers, and one doesn't exist or can exist many times over. Hence, different.

[1] https://c9x.me/articles/gthreads/code0.html

In other words it might behave just like "the stack"; the differences between different kinds of "heaps" are as large or larger than the difference between "the stack" and "the heap".

> fragmentation is a risk, the resource is 'unlimited', and the lifetime is unscoped.

None of these is true in all implementations and circumstances.

Understanding the details of memory management performance is important for particular kinds of programming. But learning C's version of "the stack" and "the heap" will not help you with that.

True enough; however sometimes access to "the heap" (in C terms) will use those instructions, and sometimes access to "the stack" will not. Learning one or two assembly languages is well worth doing, since they offer a coherent abstraction that is genuinely relevant to the implementation of higher-level languages. Not so C.

In fact C teaches a model of a semi-standard virtual architecture - loosely based on the DEC PDP7 and/or PDP11 - which is long gone from real hardware.

Real hardware today has multiple abstraction layers under the assembly code, and all but the top layer is inaccessible.

So there's no single definitive model of "How computers work."

They work at whatever level of abstraction you need them to work. You should definitely be familiar with a good selection of levels - and unless you're doing chip design, they're all equally real.

    char *dupstr(const char *src) {
       char new[1024];
       strlcpy(new, src, 1024);
       return new;
    }

Also, C is learn once, write anywhere. If there is some kind of computer, then there is probably a C compiler for it. That's not true of any other language to the same extent. Know C and you can program anything.

C is fundamentally a scalar language. In 2018, the only code for which "classic" C is the fastest is code that exhibits a low level of data parallelism and depends on dynamic superscalar scheduling. Fundamentally sequential algorithms like LZ data compression, or very branchy code like HTTP servers, are examples. This kind of code is becoming increasingly less prevalent as hardware fills in the gaps. Whereas we used to have C matrix multiplies, now we have TPUs and Neural Engines. We used to have H.264 video codecs, but now we have huge video decoding blocks on every x86 CPU Intel ships. Software implementations of AES used to be the go-to solution, but now we have AES-NI. Etc.

As an example, I'm playing around with high-performance fluid dynamics simulations in my spare time. Twenty years ago, C++ would have been the only game in town. But I went with TypeScript. Why? Because the performance-sensitive parts are GLSL anyway--if you're writing scalar code in any language, you've lost--and the edit/run/debug cycle of the browser is hard to beat.

I'd argue that GPUs and SIMD instructions have so many restrictions that they're useless for general purpose computing. Yeah, they have niche spaces, but in terms of all the different kinds of programs we write, I think those spaces are going to remain niche.

Doing fused SIMD-vectorised operations will likely bring the advantages of both, with relatively small downsides. This is a relatively common technique for libraries like Eigen (in C++), that batch a series of operations via "Expression Templates" and then execute them all in as a single sequence, using SIMD when appropriate. (Other examples are C++ ranges and Rust iterators, although these are focused on ensuring loop fusion and any vectorisation is compiler autovectorisation... but they are written with that in mind: effort is put into helping the building blocks vectorise.)

GPUs and other specialized hardware aren't good at everything, and I acknowledged as much upthread, but the set of problems they're good at is large and growing.

In my domain, we reach for the CUDA libraries to write the high-performance parts of our code. ;)

(and worth noting: if I pull out the special hardware you're thinking of from that box, my particular thousand-dollar-box is no longer able to run software I need because the GUI requires a graphics accelerator card. The OS authors have already reached for a subset of CUDA to optimize the parts of the GUI that needed optimization).

are there ? how many laptops, desktops, smartphones, tablets, use anything else than the von neumann architecture ?

The C model is relatively close, I’ve heard, to the hardware of a PDP-11. But there have been tons of abstractions and adaptations on both sides of that coin ever since; not only can a C program provide a language runtime that behaves quite differently from a PDP-11, but the C program itself is compiled to machine code that is sometimes quite different than the code for a PDP-11, and even the low level behavior of the CPU often differs from what’s implied by the ISA. And while all of these models of computation are Turing equivalent, the transformations to and from C are very well known.

* As a continuum from "low level" to "high level".

* As a giant bag of topics: strings, heap, hash tables, machine learning, garbage collection, function, instruction set, etc.

If your goal is to have a broad understanding of CS, you want to explore the whole continuum and many topics. C is great for that because it exists at a sweet spot that's lower-level than most languages but not so low level that you have to jump into the deep end of modern CPU architectures which are fantastically complex.

Because C has been so successful, there are few other successful languages that sit near it on that line. Those that are (C++, Rust) are much more complex. So if your goal is just to get familiar with that region of the continuum and not become an expert in a new language, C has a good price/performance ratio.

Also, it's a good language for getting exposure to many topics other languages hide. If all you know is JS or Ruby, C will teach manual memory management, static types, heap versus stack allocation, pointers versus values, primitive fixed-sized arrays, structs, and bit manipulation. Its sparse standard library means you'll end up implementing many common data structures yourself from scratch, so you'll get a better understanding of growable arrays, linked lists, trees, strings, hash tables, etc.

"Portable assembly" is a nice slogan for C. But it's worth remembering that back when it was coined, the emphasis was on "portable", not "assembly". At the time, C was an alternative to assembly languages, not higher-level languages.

It's never been very close to an assembly language. C has types while assembly is untyped. C has function calls that abstract the calling convention while assembly languages make that explicit. C implicitly converts between types, assembly doesn't.

To all the people who are going to reply "But machine language is not how the CPU works!!1!!111": Yes, I know that real modern CPUs translate the machine code to something else internally and that they do things like register renaming and microinstruction reordering and they have ports and TLBs and instruction caches and data caches etc. But CPUs still have registers and an instruction pointer and most of them have a stack pointer and interrupts and exceptions. C will definitely NOT help you to understand those things.

This depends on what the person is really trying to learn. If they are just interested in learning how a simple CPU does what it does, then, yes, going straight to an assembly language for some old chip from the 80s is a good idea. Writing an emulator is a fun and instructive exercise.

But my impression is that most programmers who want to learn how the computer works want to because they want to be able to write more efficient software. They want to understand how computer performance works. Learning a simple CPU is anti-helpful for that. It leads you to believe wrong things like "all memory access is equally fast".

If you want to learn how to write faster code, C is pretty good because it strips away the constant factor overhead of higher level languages where things like GC, dynamic dispatch, and "everything is a reference" mask hardware-level performance effects.

It lets you control layout in memory, so you can control data cache effects. Without a VM or interpreter overhead, most of the branches the CPU takes will be branches you explicitly write in your code, so you can control things like the branch predictor.

> if your goal is just to get familiar with that region of the continuum and not become an expert in a new language, C has a good price/performance ratio.

I think this is a particularly great point in your post. I wonder what AndyKelley thinks of this, as in my understanding, that's sort of what Zig is trying to do as well. That is, Zig is attempting to be a language on a specific spot on the price/performance ratio, as it were.

So if Zig is successful, in 4 years the title of this post would have been "Should you learn C/Zig to 'learn how the computer works'?" and in 8 years the title would have been "Should you learn Zig to 'learn how the computer works'?". :-)

The problem is most of the pain of learning C comes from undefined behaviour, which isn't how "computers work". The fact that depending on optimisation level writing past the end of an array might write to memory, or might not, is (mostly) a unique feature of C. Similarly sometimes a signed integer will overflow "cleanly", but then sometimes undefined behaviour will kick in and you'll get weird results. This (ironically) makes checking for overflow when adding integers in C annoyingly complicated.

With assembler if you write through a pointer, you write to that memory location, regardless of if you "should" be right now. You do multiplication or addition and you get well-defined 2s-complement wrap-around.

You get that, if that's what your CPU implements. Of course that's what all commonly used processors nowadays like x86 do. But C was meant to run on weirder ISAs as well. The specs of C allow so much undefined behavior in order to let C just emit the instructions for the multiply or memory access, and C deliberately says "not my problem" for whatever this architecture happens to do with edge-cases like overflow.

Using assembly instead of C cuts past the abstraction of the architecture, for both good and bad. You get defined behavior but lose portability. Practically speaking, yes, x86 assembly probably is a better way to learn without getting distracted by forty-year-old hardware oddities.

For me, working thru the resources on the OSDev wiki by taking jonesforth and linking it with the bootstrap from the "Writing an OS in Rust" tutorial (https://os.phil-opp.com/) really showed me how far C is from the hardware, and how much closer Forth connects to the idiosyncrasies of a computer system. Further, the immediacy of the Forth REPL can help with little experiments and building up the understanding of how much a machine's architecture influences code/data structures, opcode choice, privilege management, etc.

Plus, understanding Forth will bend your brain in a very strange but positive way :)

Can you elaborate on how you feel Forth better matches how a computer actually works? I’m not yet convinced on that point, but I have no Forth experience.

That experience made me regret that Forth wasn't part of my formal education experience: it is a wonderful slightly above assembly language.

Forth is what should be included in a BIOS as the absolute lowest level interpreted language. A basic machine abstraction could be made by using only interpreted functions/procedures and that could be used to bootstrap add-in routines for attached hardware. It would be very possible to write low level bootstrap drivers that could be used on any architecture providing the specification (including some interface hooks for defining how to register and use an IO interface).

https://en.wikipedia.org/wiki/Open_Firmware

I've had the pleasure to interact with it while trying to get a SPARC Ultra 60 workstation to work. The driver hooks missing from most modern hardware meant that not all graphics cards could be used with full support - currently BIOS drivers provided on some PCI hardware (RAID, network adapters) are only for the x86 architecture. I forgot what they are called though...

I'll refer to jonesforth [1], but I think the lessons apply to the other Forth's I've seen.

The main core of a Forth is generally written in assembly to bridge the specifics of a processing unit and the canonical Forth words. For instance, most control flow words are defined in Forth, but a couple critical ones are implemented in assembly and "exported" up to the higher level words. [2]

The main task of the core is to bootstrap to a sufficiently powerful yet abstract dictionary of words that will allow a full Forth to flourish. But to get there, you'll have to make a lot of choices that will be constrained by your chip (Intel x86, x86_64, ARM, Z80, etc). The big one is type of interpreter (direct threaded, indirect threaded, etc).

In jonesforth, check out the docs and implementation of NEXT [3]. The choice was guided by a quirk of the Intel instruction set that allowed loading the memory pointed by esi into eax and incrementing esi all in one step; further, Intel x86 allows an indirect jump to the address stored in a register (eax). Not all instruction sets support this pattern, you'll have to experiment and investigate for various chips.

That choice is a critical one, but it's one of many. Where do you store the dictionary of words? How do you implement DOCOL? What registers will you preserve? Why? What instructions will you expose? Which ones will you hide? Will you allow new words to be created with machine code?

In C, much of this has been decided by others decades ago (existing operating system ABI choices, mainly). In Forth, you can try things out and only be restricted by the chips, which is what all of us are ultimately constrained by, even fancy-pants languages like Rust and Go :)

Once you get past the core into Forth, some of the computer details recede, but you usually have to be somewhat aware of how you are using the system, far more than modern programming languages. Forth is the ultimate deep-dive "language" [4], but that is as much a curse as a blessing.

Basically, use Forth for the understanding it provides, then go back to making good software in typical languages aided by the enlightenment you've attained :)

[1] https://github.com/nornagon/jonesforth/blob/master/jonesfort...

[2] https://github.com/nornagon/jonesforth/blob/master/jonesfort...

[3] https://github.com/nornagon/jonesforth/blob/master/jonesfort...

[4] I've actually stopped calling Forth a programming language; programming system captures the idea a little better, I find.

I learned the HP programmable calculator version of Forth as one of my first languages, and I loved programming in that model. I think one's brain loses some flexibility if it hasn't programmed in a nonstandard model from an early time.

In my case, the destination was a very simple Forth interpreter that read input from the serial port and sent a single packet over the virtual NIC interface. There are so many ways to go, that just happened to be my choice.

Another revelation much later on, was, as discussed here, the realisation that C is indeed defined over an abstract machine. I think much of those realisations were because of reading about how crazy compiler optimizations can be and how UB can _actually_ do anything.

[1] https://savannah.nongnu.org/projects/pgubook/

[1] http://www.wrox.com/WileyCDA/WroxTitle/Professional-Assembly...

>When GCC identified “bad” C++ code, it tried to start NetHack, Rogue, or Towers of Hanoi. Failing all three, it would just print out a nice, cryptic error message.

https://feross.org/gcc-ownage/

I will say, waiting until he was capable and willing to read the subbed version was probably the right choice. Dubbed shows of any genre drive me nuts, and I'm not sure he would have the patience for the series if he was younger (the Alabasta arc was still taxing...). I do take a perverse pleasure in hinting about how crazy stuff becomes later, while also convincing him to not ruin it for himself by looking it up. ;)

This is at a really good level for driving intuitions about what the computer is actually doing. Your concern 99% of the time when you are trying to think at this level is performance, and thinking in C will give you the right intuition about how many instructions your code is generating, what and when memory is being allocated, and which exact bytes are being pulled off the disk for certain function calls.

Modern swift/java/javascript compilers are so good that they will often generate better code than you write. This often makes knowing C a less useful skill. But, even so, when trying to understand what a compiler optimization is doing, you are probably thinking in terms of the C code it is generating. It's at exactly the right level to be clear about what is actually happening without drowning yourself in JUMP statements.

I really don't think that's true given modern optimizing compilers. I remember back when C "best practices" were:

* Avoid moving code out into separate functions since calls are expensive.

* Hoist subexpressions out of loops to avoid recomputing them.

* Cache things in memory to avoid recomputing them.

But inlining means now we refactor things into small functions and usually expect that to be free. Optimizers automatically hoist common subexpressions out of loops.

And caching is useful, but making your data structures larger can cause more data cache misses, which can be more expensive that just recomputing things. I've seen good CPU cache usage make a 50x difference in performance.

Even in C, optimizing is now an empirical art and not something you can reason about from first principles and running the compiler in your head.

https://queue.acm.org/detail.cfm?id=3212479

I've seen this many times, I'll be honest: I can write C, but for the life of me I don't have the slightest clue how the assembly code will look like.

At one point, I probably could've looked at C and had a pretty clear idea of what the 68HC12 assembly would look like... but I've never bothered to learn x86/x64 assembly, or ARM assembly, and I've written way more C code for those architectures than I ever did for microcontrollers back in undergrad.

Compiler Explorer can help a ton. https://gcc.godbolt.org/

I recommend liberal use of Compiler Explorer to verify claims during code review.

  ; c = a + b

  load  reg1, a
  load  reg2, b
  add   reg1, reg2
  store reg1, c

On x86, that could be: mov [ebx], eax add [ecx], eax

Which is an entirely separate set of operands, instructions, and addressing modes. It's still the same steps, but it's not really telling you anything.

Not anymore, with modern optimizing compilers it's hard to reason about -O3 assembly output.

https://godbolt.org is amazing to play with that

It doesn't really matter if the assembly they play with comes from C or Rust or C++ or any other language that outputs assembly.

In short, learning C doesn't teach you assembly. Learning assembly teaches you assembly.

You are correct though that it is a close as you are going to get compared to many other languages, mostly because they all will make use of GC, vtables and dynamics on almost every line of code which adds noise in generated output or they run behind an interpretter or JIT.

You can get to them from C, but via extensions. They're often very thin and will let you learn a lot about how the computer works, but it's reasonable to say that it's not really "C" at that point.

C also has more runtime that most people realize since it often functions as a de facto runtime for the whole system. It has particular concepts about how the stack works, how the heap works, how function calls work, and so on. It's thicker than you realize because you swim through it's abstractions like a fish through water, but, technically, they are not fundamental to how a computer works. A computer does not need to implement a stack and a heap and have copy-based functions and so on. There's a lot more accidental history in C than a casual programmer may realize. If nothing else compare CPU programming to GPU programming. Even when the latter uses "something rather C-ish", the resemblance to C only goes so deep.

There's also some self-fulfilling prophecy in the "C is how the computer works", too. Why do none of our languages have first-class understanding of the cache hierarchy? Well, we have a flat memory model in C, and that's how we all think about it. We spend a lot of silicon forcing our computers to "work like C does" (the specification for how registers work may as well read "we need to run C code very quickly no matter how much register renaming costs us in silicon"), and every year, that is becoming a slightly worse idea than last year as the divergence continues.

As you point out, modern architectures are actually designed to run C efficiently, so I'd say that's a good argument in favor of learning C to learn how (modern) computers work. Pascal is at the same level as C, but no one says "learn Pascal to learn how computers work" because architectures weren't adapted according to that language.

They used to say it though, before UNIX derived OSes took over the computing world.

What general purpose computer exists that doesn't have a stack? Push/pop have been fundamental to all the architectures I've used.

On many systems, if you wanted a stack, you had to implement it in software. For instance, on the Xerox Alto (1973), when you called a subroutine, the subroutine would then call a library routine that would save the return address and set up a stack frame. You'd call another library routine to return from the subroutine and it would pop stuff from the stack.

The 8008, Intel's first 8-bit microprocessor, had an 8-level subroutine stack inside the chip. There were no push or pop instructions.

https://people.cs.clemson.edu/~mark/subroutines/s360.html

XPLINK, a different linkage convention, also for MVS, does have use a stack-based convention:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/...

ARM's pop is really a generic ldmia with update. You can use the same instruction in a memcpy.

MIPS, PowerPC, and Alpha don't have anything like push and pop, splitting load/stores and SP increment/decrement into separate instructions.

AArch64 has a dedicated stack pointer, but no explicit push pop.

In general the RISC style is to allocate a stack frame and use regular loads and stores off of SP rather than push and pop.

If a time traveler from a century in the future came back and told me that their programming languages aren't anywhere as fundamentally based on stacks as ours are, I wouldn't be that surprised. I'm not sure any current AI technology (deep learning, etc.) is stack-based.

From the perspective of "stack" as in "stack vs. heap", there's a lot of existing languages where at the language level, there is no such distinction. The dynamic scripting language interpreters put everything in the heap. The underlying C-based VM may be stack based, but the language itself is not. The specification of Go actually never mentions stack vs. heap; all the values just exist. There is a stack and a heap like C, but what goes where is an implementation detail handled by the compiler, not like in C where it is explicit.

To some extent, I think the replies to my post actually demonstrate my point to a great degree. People's conceptions of "how a computer works" are really bent around the C model... but that is not "how a computer works". Computers do not care if you allocate all variables globally and use "goto" to jump between various bits of code. Thousands if not millions of programs have been written that way, and continue to be written in the embedded arena. In fact, at the very bottom-most level (machines with single-digit kilobytes), this is not just an option, but best practice. Computers do not care if you hop around like crazy as you unwind a lazy evaluation. Computers do not care if all the CPU does is ship a program to the GPU and its radically different paradigm. Computers do not care if they are evaluating a neural net or some other AI paradigm that has no recognizable equivalent to any human programming language. If you put an opcode or specialized hardware into something that really does directly evaluate a neural net without any C code in sight, the electronics do not explode. FPGAs do not explode if you do not implement a stack.

C is not how computers work.

It is a particular useful local optimum, but nowadays a lot of that use isn't because "it's how everything works" but because it's a highly supported and polished paradigm used for decades that has a lot of tooling and utility behind it. But understanding C won't give you much insight into a modern processor, a GPU, modern AI, FPGAs, Haskell, Rust, and numerous other things. Because learning languages is generally good regardless, yes, learning C and then Rust will mean you learn Rust faster than just starting from Rust. Learn lots of languages. But there's a lot of ways in which you could equally start from Javascript and learn Rust; many of the concepts may shock the JS developer, but many of the concepts in Rust that the JS programmer just goes "Oh, good, that feature is different but still there" will shock the C developer.

C doesnt "have", or require, a stack, either. It has automatic variables, and I think I looked once and it doesn't even explitly require support for recursive functions.

That means static allocation is insufficient for an implementation of automatic variables in a conformant C compiler. Nevertheless I still like to think of it as a valid implementation sometimes. In contemporary practice many stack variables are basically global variables, in the sense that they are valid during most of the program. And they are degraded to stack variables only as a by-product of a (technically, unnessary) splitting of the program into very fine-grained function calls.

Can you elaborate? I thought I knew what register renaming was supposed to do, but I don't see the tight connection between register renaming and C.

The UltraSPARC processor is a stereotypical example, a RISC processor designed to cater to a C compiler as much as possible: with register renaming, it has 256 virtual registers!

Another related issue is dealing with user/kernel mode transitions and context switches. User/kernel transitions can be made cheaper by compiling the kernel to target a small subset of the architectural registers, but a user mode to user mode context switch would generally require a full save and restore of the massive register file.

And there's also an issue with instruction encoding efficiency. For example, in a typical three-operand RISC instruction format with 32-bit instructions, with 8-bit register operand fields you only have 8 bits remaining for the opcode in an RRR instruction (versus 17 bits for 5-bit operand fields), and 16 bits remaining for both the immediate and opcode in an RRI instruction (versus 22 bits for 5-bit operand fields). You can reduce the average-case instruction size with various encoding tricks, cf. RVC and Thumb, but you cannot make full use of the architectural registers without incurring significant instruction size bloat.

To make the comparison fair, it should be noted that register renaming cannot resolve all dependency hazards that would be possible to resolve with explicit registers. You can still only have as many live values as there are architectural registers. (That's a partial truth because of memory.)

There are of course alternatives to register renaming that can address some of these issues (but as you say register renaming isn't just about this). Register windows (which come in many flavors), valid/dirty bit tracking per register, segregated register types (like data vs address registers in MC68000), swappable register banks, etc.

I think a major reason register renaming is usually married to superscalar and/or deeply pipelined execution is that when you have a lot of physical registers you run into a von Neumann bottleneck unless you have a commensurate amount of execution parallellism. As an extreme case, imagine a 3-stage in-order RISC pipeline with 256 registers. All of the data except for at most 2 registers is sitting at rest at any given time. You'd be better served with a smaller register file and a fast local memory (1-cycle latency, pipelined loads/stores) that can exploit more powerful addressing modes.

On MOS 6502 we used self-modifying code rather than the stack because it was more efficient and that CPU has no instruction and data caches, so they couldn't be corrupted or invalidated.

AFAIK intel cpus have a hardware stack pointer

He addresses all of that in the subsequent bullet points of his summary, and elaborates on it in the body of the article (your criticism stops at his first sentence of the summary). It goes into a nuanced discussion; it doesn't just make a blanket statement. I don't find it disingenuous at all.

What's really needed are languages that make it easier to express what you want to accomplish - this is still a huge problem, as evidenced by the fact that even a simple data munging task can be easily explained to people in a few dozen words, but may require hundreds of LOC to convey to the machine...

(BTW, it's time for us to be able to assume that the computer and/or language can do base-10 arithmetic either directly or via emulation. The reasons for exposing binary in our programming languages became irrelevant decades ago - ordinary programmers should never have to care about how FP operations screw up their math, it should just work.)

I'd argue you should know how that works.

Cache-misses, pipelining and all these subtle performance intricacies that seem to have no rhyme or reason just fall out out understanding exactly how you get shorter clock cycles, different types of memory and the tradeoffs that they present.

One of the best things I ever did was go build a couple projects on an FPGA, when you get down to that level all of these leaky (performance) abstractions are clear as day.

The primary reason for dropping down to native is to get better performance. If you're going to do that you'll leave 10x-50x performance on the table if you don't understand cache misses, prefetching and the other things that manual memory placement open up.

I'm not saying that you can't do performance work without having done that. Just that you'll be at a disadvantage since you're at the mercy of whatever your HW vendor decides to disclose to you.

If you know this stuff you can work back from from first principals. With a high level memory architecture of a system(say tiled vs direct rendering GPU) you can reason about how certain operations will be fast and will be slow.

And your response was absurd. You don't rebuild a transmission in order to run a shop. You don't even rebuild a transmission as an engineer creating cars, you shop that out to an organization specializing in the extremely difficult task of designing and building transmissions. I wanted to avoid this waste of time, but here we are.

As for the rest of your comment about reasoning about performance, none of that requires the work you did. Again, neat project (for you), but completely unnecessary in general.

EDIT: I was going to update my comment a bit now that I thought more about it and that I'm on a computer rather than a mobile phone, but in the meantime jerf posted a very good reply to the parent comment so just read that ^^.

Even just the distinction between the stack & heap is wrong. They aren't different things, just different functions called on the otherwise identical memory. It's why things like Go work fine, because the stack isn't special. It's just memory.

malloc & free are also totally divorced from how your program interacts with the OS memory allocator, even. GC'd languages don't necessarily sit on malloc/free, so it's not like that's an underlying building block. It's simply a different building block.

So what are you trying to teach people, and is C really the way to get that concept across? Is the concept even _useful_ to know?

If you want to write fast code, which is what you'll commonly drop to C/C++ to do, then just learning C won't get you any closer to doing that. It won't teach you branch predictors, cache locality, cache lines, prefetching, etc... that are all super critical to going fast. It won't teach you data-oriented design, which is a hugely major thing for things like game engines. It won't teach you anything that matters about modern CPUs. You can _learn_ all that stuff in C, but simply learning C won't get you that knowledge at all. It'll just teach you about pointers and about malloc & free. And about heap corruption. And stack corruption.

To add to this: I have seen people who learned C and thought it to be "close to the metal" genuinely believe that stack memory was faster than heap memory. Not just allocation: they thought that stack and heap memory were somehow different kinds of memory with different performances characteristics.

And the C abstract machine maps just fine to computers where the heap and stack are separate, unrelated address spaces, so this isn't even necessarily mistaken reasoning for someone who just knows C.

The realization that malloc is really just kind of a crappier heavy-manual-hinting-mandatory garbage collector was a real eye-opener in my college's "implement malloc" project unit.

(To clarify: the malloc lib is doing a ton of housekeeping behind the scenes to act as a glue layer between the paging architecture the OS provides and high-resolution, fine-grained byte-range alloction within a program. There's a lot of meat on the bones of questions like sorting memory allocations to make free block reunification possible, when to try reunification vs. keeping a lot of small blocks handy for fast handout on tight loops that have a malloc() call inside of them, how much of the OS-requested memory you reserve for the library itself as memory-bookkeeping overhead [the pointer you get back is probably to the middle of a data structure malloc itself maintains!], minimization of cache misses, etc. That can all be thought of as "garbage collection," in the sense that it prepares used memory for repurposing; Java et. al. just add an additional feature that they keep track of used memory for you without heavy hinting via explicit calls to malloc() and free() about when you're done with a given region and it can be garbage-collected).

It occupies the same L1/L2 cache as any other memory. There's no decreased access times or fetches other than the fact that it just happens to be more consistently in L1 due to access patterns. And this is a very critical aspect of the system, as it also means it page faults like regular memory, allowing the OS to do all sorts of things (grow on demand, various stack protections, etc...)

There's a reason why SP was promoted to a first class citizen in AArch64 when they were otherwise removing features like conditional execution.

That's also the reason why using RSP as a GPR on x86 gives you terrible perf compared to the other registers, it flips back and forth between the stack engine and the rest of the core and has to manually synchronize in ucode.

EDIT: Also, the stack is different to the OS generally too. On Linux you throw in the flags MAP_GROWSDOWN | MAP_STACK when building a new stack.

Care to elaborate?

C doesn't let you write something like:

    string x = y;

C doesn't let you write "string x = y" because it doesn't have string as a primitive variable type; that's the whole and only reason. It's not quite correct to say that "the computer must allocate memory, copy memory, and eventually free memory" to do string assignment---it depends heavily on context and how a given language defines 'string' (are strings mutable in this language? If not, that statement may just be setting pointers to two immutable memory locations the same, and that immutability may be maintaned by type constructs in the language or by logical constraints in the underlying architecture like read-only TEXT memory pages---or both!---and so on).

The old Apple Foundation NSString is an interesting example of how the question of string manipulation is a complicated one that doesn't even lend itself well to the "allocate, copy, free" abstraction you've described. Pop that thing open, and you discover there's a ton of weird and grungy work going on inside of it to make string comparison, merging and splitting of strings, copying strings, and mutating strings cheap. There are multiple representations of the string attached to the wrapper structure, and a host of logic that keeps them copy-on-X synchronized on an as-needed basis and selects the cheapest representation for a given operation.

But why does C not have string as a primitive variable type? It's for exactly the reason you state: there are very different approaches a high-level language can take wrt. string ownership/mutability. These approaches might require GC, refcounting, allocation, O(n) copies, etc -- operations that do not trivially map to assembly language.

C is close to the machine precisely because it declines to implement any high-level semantics like these.

Perhaps it is more correct to say not that C is "closer to the machine," but that C "tries to position itself as somewhat equidistant from many machines and therefore has design quirks that are dictated by the hardware quirks of several dozen PDP-esque assembly architectures it's trying to span." Quite a few of C's quirks could go away entirely if someone came along, waved a magic wand, and re-wrote history to make K&R C a language targeted exclusively at compiling Intel-based x86 assembly computer achitectures, or even one specific CPU.

Also, the set of things you can do in standard C is a subset of the things you can do in assembler.

Procrastination ensues

   > *operations that must be manually performed in assembly language must also be manually performed in C.*

To give one obvious example, in C i can just call a function, no thinking required. Calling a function in assembly requires manually pushing stuff to the stack and then restoring it again.

I don't think people need to be able to code in C at the drop of a hat. But it should not be a scary thing for good engineers.

C really will test you and make you a better programmer than any high level language ever could. Someone who is a good C programmer will right better code in any language than someone who is just focused on high level languages. The same could not be said for python, java, or js.

1. https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...

How so? It's not like you can't write operating systems in other, more readable and understandable, languages.

My university introductory classes were Pascal and C++.

One of the consequences of C is the extinguishing of machine architectures where the underlying memory model is not a flat, uniform, byte-addressed address space. Such as Symbolics or Burroughs architectures, or word-addressed machines.

The “byte addressable” thing is exactly why C was created over B, even, right? That was one of the crucial features not supported.

The C abstract machine presents a flat, uniform, byte-addressed address space.[1] The reason that it does not define what a pointer's representation is is because it needs to map that to what the hardware actually does, which is your point.

1: Actually, my impression is that it does, but this is actually an area of the spec in which I'm less sure. I'm going to do some digging. Regardless, the point is that the memory model != the machine model, which is your point.

EDIT: For example, https://en.cppreference.com/w/c/language/memory_model

> The data storage (memory) available to a C program is one or more contiguous sequences of bytes. Each byte in memory has a unique address.

Though cppreference is not the spec itself, of course. It is the conceptual model that's often presented.

LAST EDIT: I happened to run into someone who seemed knowledgeable on this topic on Reddit: https://www.reddit.com/r/programming/comments/9kruju/should_...

TL;DR no! This is another misconception. Tricky!

I taught myself C when I was a teenager (on an Amiga, back in the 80's.) It is amazing that almost 30 years later, I'm still learning new things about it.

https://en.wikipedia.org/wiki/B_(programming_language)

From the above article:

>B is typeless, or more precisely has one data type: the computer word.

I had read the Martin Richards (inventor of the language) book about BCPL (predecessor of B) early in my career, although I could not work on it, since there was no machine available to me that could run it. (It was already outdated then.) Interesting language though, and even the systems software examples shown in the book (written using BCPL) were cool.

You're right about why C was created, byte addressability.

From the article about C:

https://en.wikipedia.org/wiki/C_(programming_language)

>The original PDP-11 version of Unix was developed in assembly language. The developers were considering rewriting the system using the B language, Thompson's simplified version of BCPL.[11] However B's inability to take advantage of some of the PDP-11's features, notably byte addressability, led to C.

C abstracts control flow, but not memory access. C data access is pretty much what the hardware gives you. Memory is bytes addressed by integers. There's even pointer arithmetic. C puts a layer of data structures on top of that, but the underlying memory model is one "(char *)" cast away. Every call to "write" implies that cast.

By the time you get to, say, Python or Javascript, that flat memory model is completely hidden. There could be a compacting garbage collector underneath, changing the addresses of everything while the program is running, and you'd never know.

Example: conversions between function pointers and regular pointers... https://stackoverflow.com/questions/32437069/c-void-function...

It's abstractions all the way down.

I think that these terms are some of the most confusing our discipline has.

In typical use of a C compiler, you get code for the target processor, i.e. x86. In theory, you don't have to worry about the underlying hardware, so you could say you are programming for some abstract machine that runs C code, but it is much less meaningful than saying java has a virtual machine.

Witness any discussion of a pointer bug at any level of the stack. No matter what the piece, someone will jump in and say, "that should have been bounds checked!" A lot of times it's true. But what they miss is that the bounds check needs to come from somewhere, which means there is a layer of the system where it doesn't apply. Somewhere you have a larger piece of memory, and it gets divided into smaller chunks, and the boundaries are fiction, meaningful only to a higher level abstraction. This is the way it needs to work.

Reducing the code in which that's a concern is likely legitimate. But then you enter into "that's not really how it works".

Do you need to bake bread to eat it? No. Should you learn to bake it? Yes.

There are lots of things you should learn to do because they're useful and teach you about how the world works. The miracle of society is that you don't have to learn most of them to enjoy using them.

>A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyse a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -- Robert Heinlein

For one, it misses the fact that learning how to bake it doesn't benefit the eating process. Whereas, learning how to code in C benefits (but is not required) in general programming.

I understand that analogies are always compromises because there is always going to be something that differs from the original motif. Also, analogies should be used when the motif is complicated with many layers of abstraction and using one adds something - whether it is clarity, succicicty or reduction of abstraction. In the case of parent comment, it is not too difficult to understand the original motif. So, the bread analogy adds virtually nothing to it.

Maybe it works differently for bread, but with whisky, learning how it has made has certainly enhanced my consumption, if only to give me the language needed to describe flavors and compare and contrast.

When you ask what portable assembler is, there's actually three different things you could mean:

1. C is portable assembler because every statement maps pretty directly to assembly. Obviously, compiler optimizations tend to make this completely not true (and most of the rants directed towards compiler developers are precisely because they're eschewing naive mappings).

2. You can represent every (reasonable) assembly listing using C code. Well, except that C has no notion of SIMD value (yes, there's extensions to add vector support). Until C11, it couldn't describe memory ordering. Even with compiler extensions, C still doesn't describe traps very well--any trap, in fact, is undefined behavior.

3. Every assembly instruction can have its semantics described using C code more or less natively. Again, here C has an abstract machine that doesn't correspond very well to hardware. There's no notion of things such as flag registers, and control registers are minimal (largely limited to floating-point control state). Vectors and traps are completely ignored in the model. Even more noticeably, C assigns types to values, whereas processor definitions assigns types to operations instead of values.

Note here that I didn't need to invoke undefined behavior to show how C fares poorly as portable assembler. The problem isn't that C has undefined behavior; it's that a lot of machine semantics just don't correspond well to the abstract semantics of C (or indeed most languages).

That simplicity and the smallness of the C language makes it truer to the hardware underneath and as you don't need to descend through layers of frameworks, like a high level language such as python, to understand what the heck is going on.

This is very much not true in my experience. Optimization (even just -O1, which is required to make C be more worth writing than Python for large-scale apps) will do things like reorder statements, inline functions, elide local variables, set up tail calls, etc. It is a specific skill requiring experience to be able to understand what's happening when stepping through a C function in a debugger, even with source at hand and debugging information included. If you haven't been frustrated at "Value has been optimized out" or breakpoints being mystically skipped, you haven't done enough debugging work to really acquire this skill, and saying that C maps to the machine is just theory.

There is value in a highly unoptimized language toolchain for debugging, sure. But honestly CPython is closer to that than any production C binary you're likely to see.

Quite common on games targeting consoles.