5 ms·

I stopped reading when I got to "C also operates inside of a virtual machine." Is the author confusing virtual memory with virtual machine? Perhaps they're ref

I stopped reading when I got to "C also operates inside of a virtual machine." Is the author confusing virtual memory with virtual machine? Perhaps they're referring to the way a high level language abstracts away the details of the H/W. I didn't care enough to read on. That said, I learned the most about "how a computer works" in a class that taught Intel 8080 assembler on a system running CP/M. (Technically it was MP/M but there was only a single console.) The instructor spent a lot of time explaining what registers were, accumulators, stack pointer, addressing RAM and so on. That's why I learned about H/W details, not because I focused on a particular language. I thought the entire reason for C was to avoid having to deal directly with the H/W (though it can be done.)

tptacek 8y ago
I'm confused as well. Klabnik is no doubt reading this thread. I'd like to know more about the "virtual machine" he supposes the C language targets.
- steveklabnik 8y ago
  I am, but I also have work to do, and this has blown up a little. I’ll be replying but contrary to popular belief my job is not responding to hacker news comments. (I've now replied to your parent, let's keep it in one thread instead of two :) )
- pcwalton 8y ago
  I suspect that by "virtual machine" he means "the C abstract machine". There's arguably little relevant difference between an abstract machine and a virtual machine—for example, Android has an AOT compiler for the Java "virtual machine".
  - steveklabnik 8y ago
    To be exceedingly clear about it: yes, that is my fundamental point.
    - tptacek 8y ago
      But, I mean, how useful is that point? Virtually everything, including the X86 ISA, is an "abstract machine".
      - steveklabnik 8y ago
        So, this post isn't attempting to address the usefulness angle; that's going to be in the two follow-ups. But I'll give you a summary of where I'm going with this, because you were actually in the back of my mind when I was writing this, and I'm interested in your thoughts. First though, this post. The first reason that this is useful is that there are a lot of people out there who believe that C is somehow fundamental to computing. You and I both know that this is false, but I run into a ton of people who don't understand this. So, this first post is setting that stage: everything is always an abstraction, in the big picture sense. That's bullet point one. That said, interpreting people literally isn't a good way to have a conversation, you need to know what they are saying, which may or may not connect to the exact words they used. I think when people are saying this phrase, they don't mean it in a literal sense. Part of the reason why is that there are some differences that matter when you zoom in from the big picture. I speculate a bit as to why, but regardless, knowing that it may not be literal is point two. I've heard "all models are wrong; some models are useful" attributed to several people, but it's sort of the counter argument to bullet point one, and so makes up bullet point three. Drawing a distinction between the C abstract machine and the JVM can be a useful mental model, even if it's incorrect in some sense. The C abstract machine is closer to hardware than the JVM is, and even if it's not a perfect mapping, you'll be exposed to stuff that's closer than your high level language. As long as you know you're still working with an abstraction, learning C can be a great way to be exposed to this stuff. Just keep in mind that it's not magic, or particularly inherently special. I do think that this is useful on its own. If you reduce it down to a soundbyte, sure, that's not interesting, but the interesting thing is in the details. In some sense, this is kind of the fundamental point of the article. You may find that boring, but that's okay; this stuff isn't really for you, both in a literal and figurative (experienced C developers generally) sense. ------------------------------------ Part two is going to discuss what happens if you take this to an extreme. I have two small bits of sample code that fundamentally do the same number of operations, and have the same computational complexity, but one runs much, much faster. This is due to how it interacts with caching, which is not part of the C spec, but is the reality of x86 (at least) hardware. This exposes a sort of fundamental tension when thinking about how the abstract machine relates to the physical machine. This is where C is really interesting, because it's low level enough to allow you to control memory allocation and access, which higher-level language users aren't really exposed to. This is the "why is this useful," really. The task is to know what behaviors you can rely on and which ones you can't, and how it relates to the hardware you actually want to support. ------------------------------------ Part three is going to show what happens if you make a mistake with the ideas from part two. If you incorrectly assume that C's abstract model maps directly to hardware, you can make mistakes. This is where UB gets dangerous. While you can take advantages of some properties of the machine you're relying on, you have to know which ones fit within C's model and which ones don't. ------------------------------------ I split this into three parts because it's an MVP, in a sense. Ship the first part so that I don't continue to revise the beginning over and over and over again. They're all related to each other, and could be one whole work, but it's true that this one is less directly useful than the others, as it's really setting the stage. ... does that all make sense?
Koshkin 8y ago
C does indeed present the programmer with an abstract machine (which may be vastly different from the actual hardware).
- theprotocol 8y ago
  It's clear this was the author's intention here. He is using the term "virtual machine" broadly. Whether this makes for as effective or interesting a "twist" as he hopes it does is another matter.
deleted 8y ago
[deleted]
aschampion 8y ago
> I stopped reading when I got to "C also operates inside of a virtual machine." The very next section, beginning on the very next line, begins to explain what the author means.
steveklabnik 8y ago
> I stopped reading when I got to "C also operates inside of a virtual machine." Then you missed my actual explanation and description, which is described in the rest of the post. Since others are also apparently confused, I'll re-state it here. The C language is not defined in terms of hardware. The C language is defined in terms of an "abstract machine." This machine, being abstract, does not exist. "Virtual" and "abstract" are terms that are broadly speaking synonyms in general usage. The spec even defines this in terms of an "execution environment" which can be "freestanding" or "hosted", and most C programs are, in the spec's language, running in the execution environment of C's hosted, abstract machine. The rest of the post is exploring how this is conceptually the same, but different in details, than something like the JVM, which is what many people think of when they hear "virtual machine." As mentioned elsewhere in the thread, the sense of "virtual machine" that C uses is where LLVM gets its name from, yet people found that confusing enough that they changed the name. This comment is also a re-statement of my point, maybe it helps: https://news.ycombinator.com/item?id=18123642 https://news.ycombinator.com/item?id=18123642 You may also argue that the abstract machine is practically insignificant. I disagree, but that's what my follow-up posts are about, so this post doesn't address this question directly at all. Does that help?
- Shorel 8y ago
  The explanation helps, but it should not be required. Virtual has shifted meaning and using that word in this context confuses everyone. Abstract is a perfectly cromulent word in this case.
- fmihaila 8y ago
  > Then you missed my actual explanation and description, which is described in the rest of the post. Since others are also apparently confused, I'll re-state it here. I think the confusion stems from using the word "operates", which suggests a VM that exists at runtime: > There’s just one problem with this: C also operates inside of a virtual machine. I agree with the sibling comment that in this context the term abstract machine would be better. Also, saying "C is defined in terms of an abstract machine" instead of "operates" might be better.

tptacek 8y ago

I'm confused as well. Klabnik is no doubt reading this thread. I'd like to know more about the "virtual machine" he supposes the C language targets.

steveklabnik 8y ago
I am, but I also have work to do, and this has blown up a little. I’ll be replying but contrary to popular belief my job is not responding to hacker news comments. (I've now replied to your parent, let's keep it in one thread instead of two :) )
pcwalton 8y ago
I suspect that by "virtual machine" he means "the C abstract machine". There's arguably little relevant difference between an abstract machine and a virtual machine—for example, Android has an AOT compiler for the Java "virtual machine".
- steveklabnik 8y ago
  To be exceedingly clear about it: yes, that is my fundamental point.
  - tptacek 8y ago
    But, I mean, how useful is that point? Virtually everything, including the X86 ISA, is an "abstract machine".
    - steveklabnik 8y ago
      So, this post isn't attempting to address the usefulness angle; that's going to be in the two follow-ups. But I'll give you a summary of where I'm going with this, because you were actually in the back of my mind when I was writing this, and I'm interested in your thoughts. First though, this post. The first reason that this is useful is that there are a lot of people out there who believe that C is somehow fundamental to computing. You and I both know that this is false, but I run into a ton of people who don't understand this. So, this first post is setting that stage: everything is always an abstraction, in the big picture sense. That's bullet point one. That said, interpreting people literally isn't a good way to have a conversation, you need to know what they are saying, which may or may not connect to the exact words they used. I think when people are saying this phrase, they don't mean it in a literal sense. Part of the reason why is that there are some differences that matter when you zoom in from the big picture. I speculate a bit as to why, but regardless, knowing that it may not be literal is point two. I've heard "all models are wrong; some models are useful" attributed to several people, but it's sort of the counter argument to bullet point one, and so makes up bullet point three. Drawing a distinction between the C abstract machine and the JVM can be a useful mental model, even if it's incorrect in some sense. The C abstract machine is closer to hardware than the JVM is, and even if it's not a perfect mapping, you'll be exposed to stuff that's closer than your high level language. As long as you know you're still working with an abstraction, learning C can be a great way to be exposed to this stuff. Just keep in mind that it's not magic, or particularly inherently special. I do think that this is useful on its own. If you reduce it down to a soundbyte, sure, that's not interesting, but the interesting thing is in the details. In some sense, this is kind of the fundamental point of the article. You may find that boring, but that's okay; this stuff isn't really for you, both in a literal and figurative (experienced C developers generally) sense. ------------------------------------ Part two is going to discuss what happens if you take this to an extreme. I have two small bits of sample code that fundamentally do the same number of operations, and have the same computational complexity, but one runs much, much faster. This is due to how it interacts with caching, which is not part of the C spec, but is the reality of x86 (at least) hardware. This exposes a sort of fundamental tension when thinking about how the abstract machine relates to the physical machine. This is where C is really interesting, because it's low level enough to allow you to control memory allocation and access, which higher-level language users aren't really exposed to. This is the "why is this useful," really. The task is to know what behaviors you can rely on and which ones you can't, and how it relates to the hardware you actually want to support. ------------------------------------ Part three is going to show what happens if you make a mistake with the ideas from part two. If you incorrectly assume that C's abstract model maps directly to hardware, you can make mistakes. This is where UB gets dangerous. While you can take advantages of some properties of the machine you're relying on, you have to know which ones fit within C's model and which ones don't. ------------------------------------ I split this into three parts because it's an MVP, in a sense. Ship the first part so that I don't continue to revise the beginning over and over and over again. They're all related to each other, and could be one whole work, but it's true that this one is less directly useful than the others, as it's really setting the stage. ... does that all make sense?

Koshkin 8y ago

C does indeed present the programmer with an abstract machine (which may be vastly different from the actual hardware).

theprotocol 8y ago
It's clear this was the author's intention here. He is using the term "virtual machine" broadly. Whether this makes for as effective or interesting a "twist" as he hopes it does is another matter.

deleted 8y ago

[deleted]

aschampion 8y ago

> I stopped reading when I got to "C also operates inside of a virtual machine." The very next section, beginning on the very next line, begins to explain what the author means.

steveklabnik 8y ago

> I stopped reading when I got to "C also operates inside of a virtual machine." Then you missed my actual explanation and description, which is described in the rest of the post. Since others are also apparently confused, I'll re-state it here. The C language is not defined in terms of hardware. The C language is defined in terms of an "abstract machine." This machine, being abstract, does not exist. "Virtual" and "abstract" are terms that are broadly speaking synonyms in general usage. The spec even defines this in terms of an "execution environment" which can be "freestanding" or "hosted", and most C programs are, in the spec's language, running in the execution environment of C's hosted, abstract machine. The rest of the post is exploring how this is conceptually the same, but different in details, than something like the JVM, which is what many people think of when they hear "virtual machine." As mentioned elsewhere in the thread, the sense of "virtual machine" that C uses is where LLVM gets its name from, yet people found that confusing enough that they changed the name. This comment is also a re-statement of my point, maybe it helps: https://news.ycombinator.com/item?id=18123642 https://news.ycombinator.com/item?id=18123642 You may also argue that the abstract machine is practically insignificant. I disagree, but that's what my follow-up posts are about, so this post doesn't address this question directly at all. Does that help?

Shorel 8y ago
The explanation helps, but it should not be required. Virtual has shifted meaning and using that word in this context confuses everyone. Abstract is a perfectly cromulent word in this case.
fmihaila 8y ago
> Then you missed my actual explanation and description, which is described in the rest of the post. Since others are also apparently confused, I'll re-state it here. I think the confusion stems from using the word "operates", which suggests a VM that exists at runtime: > There’s just one problem with this: C also operates inside of a virtual machine. I agree with the sibling comment that in this context the term abstract machine would be better. Also, saying "C is defined in terms of an abstract machine" instead of "operates" might be better.