Hacker News Reader

Comment by ddevault | Hacker News Reader

C doesn't necessarily teach you how computers work. But it does teach you how software works. Our modern software empire is built on mountains of C, and deference to C is pervasive throughout higher-level software design.

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

View on HN

> Our modern software empire is built on mountains of C, and deference to C is pervasive throughout higher-level software design.

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.

For those who don't know what ABI means (as I did not) and thought it might be a typo.

ABI = Application Binary Interface

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

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

Yup. In compiled-languages land it's common to see things that are API-compatible but not ABI-compatible: the compiled objects don't work together, but if you recompiled the same source code it would work with no changes. This happens (sometimes) when you do things like reorder members of a structure or switch to a larger integer type for the same variable.

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.

To save you the read: in web terms, the API is e.g. Stripe and the ABI is HTTP.

There is not really any such thing as "the" C ABI -- different platforms have totally different conventions, even on the same instruction set.

It's shorthand for "the ABI relevant to the current context", which is entirely reasonable.

It wasn't at all clear to me from the post I responded to that this is what the poster meant, or that they knew the fact I was stating.

I'm assuming "the" C ABI probably means System V.

C at the very least teaches the difference between stack and heap memory, a crucial concept obscured by most higher-level languages.

There is no difference inside the computer between those concepts.

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.

I think this is lawyering a bit. There might not be a "heap", per se, but there is stack allocation (which is embedded all the way into the ISA) and "everything else". You can, after all, build a simple "heap" on top of an adequately large static buffer.

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.

The distinction is important for apartmented thread models, such as those found on Windows, where you do have multiple heaps, and pointers allocated on one are not valid in another.

Stack allocation of return addresses is embedded in most ISAs- but stack allocation of local variables isn't (because that's not A Thing at the ISA level).

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.

In what sense is stack-relative addressing, PUSH, POP, and addition/subtraction on the stack pointer not ISA-level support for stack allocation of local variables?

Addition, subtraction, and stack-relative addressing are, in most architectures I'm familiar with, generic- stack-relative addressing ends up just being a special case of register-relative addressing, and addition and subtraction are rather important instructions in their own right.

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

On x86, push/pop have dedicated hardware optimizations known as the stack engine which perform most of the rsp increments/decrements and passes those offsets into the decoder, instead of using executions slots on them. push/pop are also much smaller than the corresponding mov/add instructions.

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.

There's a reason 32-bit ARM has 'move base register down and then do some stores' and 'do loads and then move base register up' (stmdb and ldmia) rather than just plain old ldm and stm, and I'm pretty sure it's because it makes the entry and exit sequences for function calls with a stack shorter. (The ARM ISA doesn't privilege a downward growing stack, so you can use stmib and ldmda if you want your stack to grow upward; the Thumb ISA, however, does want a downward stack for push and pop.)

That's definitely a large part of it, but it also makes small memcpys nicer (load sizeof(foo)/4 registers from sourceptr with post increment, store them to destptr with post increment)

They may not be distinguished at the instruction level, but if you’re trying to argue it’s not a useful thing to teach you’ve lost me. Dynamic vs static vs scoped (stack) allocation is incredibly important to reasoning about basic programs.

Like I established in my opening comment, C tells you how software works, not how hardware works. Regardless, you're still wrong in several ways here. Making it out of several discontinuous regions of memory doesn't make your heap less of a heap. Most architectures also provide instructions for loading data from the stack and optimize for this purpose, using their caches more efficiently and making design decisions which have clearly been influenced by the C (or System V) ABI.

For your definition of 'computer', perhaps. Many microcontrollers have the stack defined by the hardware.

And some, such as RISC-V, have no predefined stack pointer at all. (Push and pop are implemented by doing them manually; call is implemented by the jump instruction optionally taking an argument for a register to use as the stack.) C, at best, teaches you the C abstract machine, which supports both of these concrete implementations equally well.

Leaning how microcontrollers work is not the same as 'learning how the computer works' in general, which is the subject at hand.

Here's the C99 standard:

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

Debates about the "stack" rage every couple of years on comp.lang.c. Invariably people conflate two different meanings: (1) an abstract data structure with LIFO ordering semantics, and (2) #1 implemented using a contiguous block of [virtual] memory.

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.

And just going to throw out there that IA64 split the function return stack and data stack into different hardware stacks, so they've been out for twenty years at this point at least.

"C" doesn't just include the spec but also the customary semantics [1] of the language. The customary semantics certainly include the stack and the heap.

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

People don’t learn C by learning the spec, and virtually every c implementation and runtime I know, it uses a stack and heap.

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

At some point, these conversations seem to always turn into a contest to see who can be the most pedantic. Which I think is pretty fun - and pretty well in the spirit of the original article - but that's me, and I can't fault anyone for being turned off by it.

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

Most languages do that internally. It's not a reason you should learn C in particular while you're trying to get an understanding of heaps and stacks.

Indeed. There's a place for language lawyering, but that place is not everywhere.

They just call stack allocation "automatic storage duration" in the spec. If you read it, you pretty much have to implement it as a stack; you just don't have to keep the frames contiguous in memory. They still need to maintain stack style LIFO access though, so the only spec compliant implementations that don't use a traditional stack have back pointers in each frame to maintain stack style LIFO semantics.

I think I only got a reasonable understanding on the stack and heap concepts when I got to make a compiler in my undergrad classes. Some 2 years after I learned C.

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

Or passing by value vs passing a pointer, or the importance of memory management...

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.

They don't solve problems created by C, they just solve problems C doesn't. The problems still exist, and sometimes the high-level compiler even picks the wrong solution. Learning C helps you understand when and why this has happened.

Arguably those problems did not exist before the C-era as software wasn't large or complicated enough. C++ directly attempts to improve over C by providing new mechanisms to solve problems encountered by C developers every day.

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.

When I see templates, I run in the opposite direction at a dead sprint. C++ has added very little of value to the language and templates are one of their worst offerings. Metaprogramming is an antipattern in C.

> Metaprogramming is an antipattern in C.

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?

You can write bad code in any language, C is no exception. We also see people persistently arguing in favor of simpler and less magical C. If you want reliable, maintainable code in any language, do not use magic. Metaprogramming is cool, no doubt about it, but it's unnecessary and creates bad code.

"Exploding" undefined behaviour is a problem created by C. Other languages don't have it, not even assembly languages.

There are many languages which have undefined behavior.

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

If a language lets you cause undefined behaviour via FFI into C, I think it's fair to say that that remains a problem created by C.

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.

> I think it's fair to say that that remains a problem created by C.

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.

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

> assembly-like unsafeness

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

You are right that there's no inherent need for UB. However, we made the choice to have it.

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.

> If a language lets you cause undefined behaviour via FFI into C,

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.

> FFI isn't into "C", it's into your operating system's binary format.

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.

Rust does not have a spec, so all Rust behavior is undefined.

This is literally true but also overly reductive; we do make certain kinds of guarantees, even if there isn't a full specification of the entire language yet.

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.

In my opinion as an onlooker of Rust, it seems more interested in shiny features and breaking the language every month than in becoming stable and writing a spec. It's far from replacing C in this regard.

What breaks in the language every month? That’s not the experience our users report. There are some areas where we do reserve the right to tweak things, but we take great care to ensure that these breakages are theoretical, rather than an actual pain. We have large (hundreds of thousands of LOC, and maybe even a few 1MM ones) code bases in production in the wild now, we cannot afford to break things willy-nilly.

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.

The language doesn't break as much today, but what constitutes "idiomatic" Rust is constantly changing. I don't use Rust but I spend a lot of time with people who do and am echoing what I've heard from them, and seen for myself as a casual user of Rust software and occasional drive-by contributor.

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

Thanks. That’s much more reasonable, IMHO.

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

But C never set out to be what it is today. It was a long time before anyone thought a spec was worth writing. For a language with the stated design goals of Rust, a specification and alternative implementations should be priority #1. You can't eliminate undefined behavior if you don't define any!

After recently (1 year) learning Rust I noticed that Rust teaches about low-level CS concepts of passing by value vs passing by pointer a lot better than C. Because you not just have references and values, but also have to think about richer semantics of what you are trying to do: sharing, mutability, and move semantics. So you learn not only that a few low level concepts exist, but you also learn how to use them correctly.

Memory management in C is very different than memory management in JavaScript, which throws exceptions when you try to access invalid memory, but will gladly let you create memory leaks inside event callbacks or other loops and keep chugging along gladly until it can't anymore. Writing a safe, efficient, high performing JavaScript app is very different than writing the same thing in C, and although I know both deeply well, I don't think learning C has helped me write better JS.

Just playing devil's advocate here... why is this such a "crucial" concept, for someone who is using a higher level language (like Python or Ruby)?

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?

I can’t make a thorough argument, but u/flyinglizard (in a comment adjacent to mine) mentioned what I was thinking: Ruby/Python almost entirely abstracts the concept of pointers, references, and memory. For beginners and intermediates, it’s not a big deal until you get mutable data structures like lists and dicts. When I learned CS, we were taught C/C++ first, and I remember the concept of mutability and object identity being not at all difficult.

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.

true. it's like interior decorator vs. interior designer

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.

It's also like fluid dynamicist vs quantum physicists. If you're just going to move oil around and put down differential equations, who cares about a solid foundation of quantum gravity and chromodynamics.

Yep. In truth, one can almost never win the argument of, "...but do I really need to know this?" But people should be aware that knowing fundamental things provides insight and advantages.

For sure, but there are diminishing returns. My rule of thumb is that understanding two levels of abstraction below whatever you're doing is usually worth it.

Compared to people who know only high level languages I have noticed that with my C background I can figure out performance problems better because I have an idea how the higher languages are implemented.

Because we haven't figured out a large body of non-leaky or resilient abstractions yet. If a higher level construct was indeed a true superset of lower level functionality, or was robust enough to be applied to a wide variety of situations, then it would be okay. Right now in web software, because we optimize for development velocity so heavily, the tools a smaller product would reach for are fundamentally different from the tools a very high load service would. Until we can come up with a set of robust higher level abstractions that scale well (or better than they currently do) then we'll be stuck where we're at. Thread pools will saturate, GC will stutter, sockets will timeout, and all sorts of stuff that higher level abstractions do not capture well.

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

> C at the very least teaches the difference between stack and heap memory, a crucial concept obscured by most higher-level languages.

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

No. In the machine model used by Go, everything is allocated on the heap. The optimizing part of the compiler can then move allocations from the heap onto the stack if it can prove that the allocation does not escape the lifetime of a stack frame.

No, it doesn't. Go does escape analysis and allocates stuff on heap if needed.

You can also learn that difference in something like C#. You don't need C for that.

And C pretends there's a distinction between the stack & heap that doesn't actually exist. There is no significant difference there.

I suggest maybe you learn C :) or Rust.

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.

Those performance and strategy differences only exist inside C or other high-level languages, as a result of abstractions created by those languages. They are not in any way reflective of "the computer."

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

You are more than welcome to use a stack in an assembly language too. What you say certainly can be true, but many architectures include dedicated stack pointer registers and operations to manipulate them, either special-purpose (AVR, __SP_H__ and __SP_L__, push, pop) or more generic (x86 %sp, push, pop). I'd argue that functions exist at the hardware level to some extent too in architectures that support, for instance, link registers (PPC $LR) and special instructions (call, ret instead of a generic jump family). Calling conventions, sure, are an attraction over functions.

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

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.

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

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)

Exactly, this will vary wildly between architectures. I would accept the statement on, for instance, a Harvard architecture but the world is a lot more nuanced in the much more common von Neumann architecture.

No no, haha, that's also not quite right. You can save the stack frame to memory then load it back which is what green threads do [1]. This includes the register state also, which is not what we're talking about here when we say "stack" -- we're referring to stack variables, not full frames. Full frames are even further from the heap, by virtue of including register states which must be restored also.

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

> On the heap, allocation might be cheap or it might be expensive, deallocation might be cheap or it might be expensive,

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.

I'd argue that given special purpose registers exist on most platforms to support a stack, and instructions dedicated to manipulating them (x86 %sp, push, pop) that the stack is in fact a hardware concept. The heap, however, is left as an exercise to the reader.

> I'd argue that given special purpose registers exist on most platforms to support a stack, and instructions dedicated to manipulating them (x86 %sp, push, pop) that the stack is in fact a hardware concept.

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.

Well, you can just write a naive allocator that just bumps pointer and never deallocates things :). To appreciate stack vs heap, you have to learn a bit about memory management and some basic algorithms like dlmalloc, imho.

Definitely, as I've replied elsewhere, the stack is in fact a hardware concept whereas the heap is left as an exercise to the reader.

You're joking. There's a very serious distinction between the stack and the heap - perhaps they live in the same memory but they are used very differently and if you mix them up your things will break.

There is no hardware distinction between stack memory and heap memory.

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.

There definitely is, unless there's a hardware heap pointer and hardware allocation and deallocation instructions, as there are for the stack :)

This isn't true. Modern instruction sets have clearly been influenced by and designed to optimize the C ABI.

...like returning a pointer to the stack:

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

stack_ret.c:5:10: warning: function returns address of local variable [-Wreturn-local-addr] return new;

Why is this a warning and not an error? Are there situations in which you would want to return the address of a local variable?

I'm not sure it really pretends that there is so much a distinction so much as C supports stack allocation/management as a language feature, but heap support is provided by libraries.

Exactly. Maybe we could say that for 99% of software C is the lowest level. Its implemented in something, that's implemented in something, that's implemented in C. So, if you learn it, you can understand your software stack completely.

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.

Our popular software stacks are written in C and C++, but that's more because of history than anything else. I rarely reach for just "classic" C for performance anymore. These days I'm more likely to reach for GPUs, SIMD intrinsics (available in Rust), or at least Rust/Rayon for code that needs maximum performance.

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.

Except even when you think vectorized processing should be a performance win, it often isn't: http://www.vldb.org/pvldb/vol11/p2209-kersten.pdf

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.

Vectorised processing is a win according to that paper: it is faster than scalar code. The key point of the paper is that compiled queries---doing loop fusion---is sometimes more of a win (in a database context, where "vectorisation" doesn't always mean SIMD as in this discussion).

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

Depends on what you mean by "general purpose computing". Is machine learning general purpose? Are graphics general purpose? Is playing video and audio general purpose? If those aren't general purpose, I'm not sure what "general purpose" means.

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.

Are you promoting Rust on every topic about GC / performance topics?

Rust is fundamentally a scalar language too. If anything, I'm promoting vector languages like GLSL/Metal/etc.

Exactly, if you want to know how a computer works, you should take a course in Computer Architecture. I remember that subject from BSc quite fondly.

I don't disagree with anything you said, but I wanted to point out you also don't disagree with the author. Your point ("this phrase is an approximation") is also the author's point. I felt he walked through the why fairly and with nuance.

It varies from application to application.

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

That requires special Hardware in contrast to C code.

I spent like a thousand dollars on the box sitting under my desk; I'm pretty sure my C code runs on special hardware too. ;)

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

Intel will not sell you an x86 processor without a GPU capable of compute these days.

That will affect a raspberry pi user how?

Raspberry Pi has a Videocore IV GPU on the chip.

> there are many kinds of different computers, with different architectures

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

On hardware level, all those use von Neumann architecture. Wasm, however, exposes Harvard architecture (implemented on top on von Neumann machines). Yet, you can compile C to Wasm, which is a data point about how abstract C is: so abstract that it can target Harvard architecture despite targeting just von Neumann architecture being sufficient for targeting modern hardware.

If only things were so simple... https://en.m.wikipedia.org/wiki/Modified_Harvard_architectur...

C is a useful and universal model of computation not just because most native software is ultimately built on C, but because any hardware that people end up widely using also has to have a sensible C compiler.

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.

Reply on news.ycombinator.com