4 ms·

> If C is not a low level language then a low level language does not exist for modern CPUs I think that's a fair conclusion though, I don't think the article

> If C is not a low level language then a low level language does not exist for modern CPUs I think that's a fair conclusion though, I don't think the article is misleading. x86 assembly is a high level language. It's analogous to JVM bytecode. Modern x86 processors are more like a virtual machine for x86 bytecode.

pvg 9y ago
It's analogous to JVM bytecode. That's only true in the way everything is analogous to everything.
- chubot 9y ago
  I think it's a good analogy because it's saying that nontrivial optimizations happen below the code layer. In early CPUs, nothing was optimized. They just executed your instructions. Now there are nontrivial optimizations and rewriting, just like the JVM.
- coldtea 9y ago
  Nope, also in the way the parent explains right after that sentence.
  - pvg 9y ago
    It's a pretty terrible analogy in nearly every obvious technical way. What an x86 cpu does with its instructions is almost but not entirely unlike what a JVM does.
    - admax88q 9y ago
      None of the "registers" in x86 assembly are real. Few of the instructions are implemented in hardware, most are impelmented in software microcode. Advanced hardware will re-order and pipeline instructions based upon data dependencies. Sure it's not doing the exact same things the JVM does with bytecode but the point is that x86 assembly is not the language of the hardware. It's a language that the hardware+firmware knows how to interpret and optimize at runtime similar to what your JVM does with java bytecode.
      - pvg 9y ago
        It isn't at all similar. JVM bytecode is a pretty high-level IR for tokenized Java. The JVM's main unit of optimization is a method, not instructions. Its key component is a compiler, it's even called that. An x86 cpu, as the article points out, spends inordinate resources looking for ILP. It's not a compiler in any reasonable sense of the word, while a JVM is.
        coldacid 9y ago
        `javac` is a compiler. The JVM is an execution platform, just like modern x86.
        pvg 9y ago
        What's the word that comes after 'JIT'?
        coldtea 9y ago
        What the word is not really important. JITting is also called "dynamic translation", which is what a CPU does with microcode. Whether that's a full compiler or not is beyond pedantic -- and irrelevant to the parent's point.
        pvg 9y ago
        The parent is telling me how the JVM doesn't have a compiler, which was my claim. It has a couple full-blown compilers. which is what a CPU does with microcode. Either you know something about current x86 CPUs that I don't or words and technical terms are, indeed, not important and have no meaning.
        admax88q 9y ago
        The point I'm trying to make with the analogy is that the x86 instruction set is not representative of what the hardware is actually doing. It is not "low level" because it is an abstraction or virtual platform that the processor exposes and then interprets using its own internal resources and programming interface (microcode). The x86 interface does not map closely to the actual hardware, just as the article states. It exposes a flat memory model with sequential execution and only a handful of registers. Much the same way that the JVM exposes a virtual machine that doesn't directly map to any of the platforms that it runs on. It's an abstraction that is interpreted or compiled at runtime. I don't understand why you think the two are so different just because the JVM is higher level.
mikepurvis 9y ago
The JVM provides native primitives around memory and thread management which are not present in x86, but that's a matter of degree.
- fixermark 9y ago
  x86 provides all sorts of memory abstractions. The whole memory segmentation model is an abstraction. https://en.wikipedia.org/wiki/X86_memory_segmentation https://en.wikipedia.org/wiki/X86_memory_segmentation
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
ninkendo 9y ago
It's a fair conclusion if you're willing to accept that the phrase "low-level language" has approximately zero modern examples. Or maybe we should relax the definition of "low-level language" a bit?
- scott_s 9y ago
  I think the author of the article is willing to accept that, and it's part of his point. The point is not to label languages, but to illuminate how we ended up with our current combination of software and hardware design. He points out that we are in a local-maximum with respect to processor performance because most of the optimizations we've made in processor design the past few decades break the C abstract machine. That requires the compiler and processor to go through awkward contortions to present the fiction of that abstract machine while still getting good performance. The final section, "Imagining a Non-C Processor", is where he explores this idea.
- namibj 9y ago
  Take a look at maxas [0], and the maxwell/pascal microarchitecture if you want a modern example of low-level language (iirc. they are still manufactured on small mainstream process nodes). [0] https://github.com/NervanaSystems/maxas https://github.com/NervanaSystems/maxas
jrochkind1 9y ago
Hmm, what does "virtual machine" mean if the "virtual machine" is implemented in hardware? And, is nothing but actual binary machine code a "low level language"? I guess it's the lowest, I don't _think_ you can go lower than that... but someone's probably gonna tell me I'm wrong.
- ummonk 9y ago
  VHDL / Verilog is lower level! In all seriousness, the "assembly is high level" argument is ridiculous and robs the "low level" vs "high level" categorization of all meaning.
  - jrochkind1 9y ago
    Perhaps C is a "medium-level language"? :)
  - Avshalom 9y ago
    Taxonomies have been rendered meaningless constantly throughout history, fighting it is usually fighting reality.
magduf 9y ago
>x86 assembly is a high level language. It's analogous to JVM bytecode. If you take this position, then having the distinction between "low level" and "high level" languages becomes pointless, and we have no way to distinguish between languages like x86 assembly and C and languages like Python and Haskell. This is why we use the terms "low level" and "high level": some of these languages have a lower level of abstraction than others. The fact that it's not giving you a great idea of exactly what's happening in the transistors is irrelevant: "low" and "high" are relative terms, not absolute.
- munificent 9y ago
  > The fact that it's not giving you a great idea of exactly what's happening in the transistors is irrelevant The author's point is that what's happening in the transistors is relevant — not controlling it is what led to Spectre and heavy performance losses if you aren't smart about cache usage. Thinking of C as a "low-level language" makes it easier for people to overlook that fact.
  - ori_b 9y ago
    And the parent's point is that there should be a distinction in level between Haskell and C, for example.
    - Avshalom 9y ago
      Then we need a finer grained taxonomy instead of the current model that is essentially: machine code;c/forth; literally everything else. I mean that should be blindingly obvious anyway looking at the actual history of programming languages and CPUs but here we are in 2018 insisting that we must have exactly three categories with exactly the definitions of: assembly;C/forth; everything else.

pvg 9y ago

It's analogous to JVM bytecode. That's only true in the way everything is analogous to everything.

chubot 9y ago
I think it's a good analogy because it's saying that nontrivial optimizations happen below the code layer. In early CPUs, nothing was optimized. They just executed your instructions. Now there are nontrivial optimizations and rewriting, just like the JVM.
coldtea 9y ago
Nope, also in the way the parent explains right after that sentence.
- pvg 9y ago
  It's a pretty terrible analogy in nearly every obvious technical way. What an x86 cpu does with its instructions is almost but not entirely unlike what a JVM does.
  - admax88q 9y ago
    None of the "registers" in x86 assembly are real. Few of the instructions are implemented in hardware, most are impelmented in software microcode. Advanced hardware will re-order and pipeline instructions based upon data dependencies. Sure it's not doing the exact same things the JVM does with bytecode but the point is that x86 assembly is not the language of the hardware. It's a language that the hardware+firmware knows how to interpret and optimize at runtime similar to what your JVM does with java bytecode.
    - pvg 9y ago
      It isn't at all similar. JVM bytecode is a pretty high-level IR for tokenized Java. The JVM's main unit of optimization is a method, not instructions. Its key component is a compiler, it's even called that. An x86 cpu, as the article points out, spends inordinate resources looking for ILP. It's not a compiler in any reasonable sense of the word, while a JVM is.
      - coldacid 9y ago
        `javac` is a compiler. The JVM is an execution platform, just like modern x86.
        pvg 9y ago
        What's the word that comes after 'JIT'?
        coldtea 9y ago
        What the word is not really important. JITting is also called "dynamic translation", which is what a CPU does with microcode. Whether that's a full compiler or not is beyond pedantic -- and irrelevant to the parent's point.
        pvg 9y ago
        The parent is telling me how the JVM doesn't have a compiler, which was my claim. It has a couple full-blown compilers. which is what a CPU does with microcode. Either you know something about current x86 CPUs that I don't or words and technical terms are, indeed, not important and have no meaning.
      - admax88q 9y ago
        The point I'm trying to make with the analogy is that the x86 instruction set is not representative of what the hardware is actually doing. It is not "low level" because it is an abstraction or virtual platform that the processor exposes and then interprets using its own internal resources and programming interface (microcode). The x86 interface does not map closely to the actual hardware, just as the article states. It exposes a flat memory model with sequential execution and only a handful of registers. Much the same way that the JVM exposes a virtual machine that doesn't directly map to any of the platforms that it runs on. It's an abstraction that is interpreted or compiled at runtime. I don't understand why you think the two are so different just because the JVM is higher level.

mikepurvis 9y ago

The JVM provides native primitives around memory and thread management which are not present in x86, but that's a matter of degree.

fixermark 9y ago
x86 provides all sorts of memory abstractions. The whole memory segmentation model is an abstraction. https://en.wikipedia.org/wiki/X86_memory_segmentation https://en.wikipedia.org/wiki/X86_memory_segmentation

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

ninkendo 9y ago

It's a fair conclusion if you're willing to accept that the phrase "low-level language" has approximately zero modern examples. Or maybe we should relax the definition of "low-level language" a bit?

scott_s 9y ago
I think the author of the article is willing to accept that, and it's part of his point. The point is not to label languages, but to illuminate how we ended up with our current combination of software and hardware design. He points out that we are in a local-maximum with respect to processor performance because most of the optimizations we've made in processor design the past few decades break the C abstract machine. That requires the compiler and processor to go through awkward contortions to present the fiction of that abstract machine while still getting good performance. The final section, "Imagining a Non-C Processor", is where he explores this idea.
namibj 9y ago
Take a look at maxas [0], and the maxwell/pascal microarchitecture if you want a modern example of low-level language (iirc. they are still manufactured on small mainstream process nodes). [0] https://github.com/NervanaSystems/maxas https://github.com/NervanaSystems/maxas

jrochkind1 9y ago

Hmm, what does "virtual machine" mean if the "virtual machine" is implemented in hardware? And, is nothing but actual binary machine code a "low level language"? I guess it's the lowest, I don't _think_ you can go lower than that... but someone's probably gonna tell me I'm wrong.

ummonk 9y ago
VHDL / Verilog is lower level! In all seriousness, the "assembly is high level" argument is ridiculous and robs the "low level" vs "high level" categorization of all meaning.
- jrochkind1 9y ago
  Perhaps C is a "medium-level language"? :)
- Avshalom 9y ago
  Taxonomies have been rendered meaningless constantly throughout history, fighting it is usually fighting reality.

magduf 9y ago

>x86 assembly is a high level language. It's analogous to JVM bytecode. If you take this position, then having the distinction between "low level" and "high level" languages becomes pointless, and we have no way to distinguish between languages like x86 assembly and C and languages like Python and Haskell. This is why we use the terms "low level" and "high level": some of these languages have a lower level of abstraction than others. The fact that it's not giving you a great idea of exactly what's happening in the transistors is irrelevant: "low" and "high" are relative terms, not absolute.

munificent 9y ago
> The fact that it's not giving you a great idea of exactly what's happening in the transistors is irrelevant The author's point is that what's happening in the transistors is relevant — not controlling it is what led to Spectre and heavy performance losses if you aren't smart about cache usage. Thinking of C as a "low-level language" makes it easier for people to overlook that fact.
- ori_b 9y ago
  And the parent's point is that there should be a distinction in level between Haskell and C, for example.
  - Avshalom 9y ago
    Then we need a finer grained taxonomy instead of the current model that is essentially: machine code;c/forth; literally everything else. I mean that should be blindingly obvious anyway looking at the actual history of programming languages and CPUs but here we are in 2018 insisting that we must have exactly three categories with exactly the definitions of: assembly;C/forth; everything else.