4 ms·

None of the "registers" in x86 assembly are real. Few of the instructions are implemented in hardware, most are impelmented in software microcode. Advanced ha

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.
  - pvg 9y ago
    Right, and the point I'm trying to make is this is a pretty lousy analogy. For one thing, an x86 CPU is not nearly as VM-y as you make it out - renamed registers are very much real registers, big piles of the most common instructions execute in 1 or 2 uOps. For another, the VM you've picked as an example is singularly uncpu-like. C also exposes an abstract machine, would you use that as an analogy? Probably not. 'An abstraction that is interpreted or compiled at runtime' is so broad it's exactly the what I said up top - it's analogous in the way everything is analogous to everything else. It's the sort of thing that might be true if you squint but offers somewhere between zero and negative insight.
    - admax88q 9y ago
      I don't know I think you're getting caught up too much on the specifics of what they're doing. CPU's are adopting JIT like tendencies in order to increase performance. Instruction reorder, register renaming, branch prediction, etc. > if you squint but offers somewhere between zero and negative insight. The insight I bring from this is that we should look moving those features out of the hardware and into the software level. Let us take advantage of them in our compilers and virtual machines. The JVM can beat C in many scenarios because it can make optimizations based upon runtime information that a static compiler will never have available. Imagine what we could do if we weren't chained to the x86 abstractions.

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.
- pvg 9y ago
  Right, and the point I'm trying to make is this is a pretty lousy analogy. For one thing, an x86 CPU is not nearly as VM-y as you make it out - renamed registers are very much real registers, big piles of the most common instructions execute in 1 or 2 uOps. For another, the VM you've picked as an example is singularly uncpu-like. C also exposes an abstract machine, would you use that as an analogy? Probably not. 'An abstraction that is interpreted or compiled at runtime' is so broad it's exactly the what I said up top - it's analogous in the way everything is analogous to everything else. It's the sort of thing that might be true if you squint but offers somewhere between zero and negative insight.
  - admax88q 9y ago
    I don't know I think you're getting caught up too much on the specifics of what they're doing. CPU's are adopting JIT like tendencies in order to increase performance. Instruction reorder, register renaming, branch prediction, etc. > if you squint but offers somewhere between zero and negative insight. The insight I bring from this is that we should look moving those features out of the hardware and into the software level. Let us take advantage of them in our compilers and virtual machines. The JVM can beat C in many scenarios because it can make optimizations based upon runtime information that a static compiler will never have available. Imagine what we could do if we weren't chained to the x86 abstractions.