3 ms·

I have written far more compilers/interpreters in my career than I probably should have, and I reached the same conclusion. For most of them, I probably couldn'

I have written far more compilers/interpreters in my career than I probably should have, and I reached the same conclusion. For most of them, I probably couldn't even tell you weather or not what I had involved a compiler. At this point, my working distinction is that a compiler produces a serialized representation. If you feed the AST directly into the runtime, then you just have an interperater. I don't see any practical benifit to this distinction, but it seems to match up with what people consider a "compiler". As an asside, I had a simmilar insight when I built a computer from logic gates [0]. Essentially, the control unit had an EEPROM of microcode, and the logic to execute an actual instruction was to use the upper 4 bits of the instruction as an index into a lookup table, then write the result to the microcode program counter. Eg: switch(OP & 0xf0): case 1: jmp &add case 2: jmp &sub ... Which looks a lot like an interperator. It wouldn't suprise me if modern CPUs actually added an additional step, where they first translate (compile?) the input stream into some internal instruction set, and then have microcode that acts as an interperator for that. [0] Also EEPROM, and various composite circuits.

nickpsecurity 8y ago
"It wouldn't suprise me if modern CPUs actually added an additional step, where they first translate (compile?) the input stream into some internal instruction set, and then have microcode that acts as an interperator for that." Among Java processors, there was quite a mix of methods ranging from CISC to RISC to in-hardware to interpret-to-regular-CPU's: https://www.electronicdesign.com/embedded/java-processors https://www.electronicdesign.com/embedded/java-processors IBM's System/38 also did something with portable microcode that got converted to internal microcode: https://homes.cs.washington.edu/~levy/capabook/index.html https://homes.cs.washington.edu/~levy/capabook/index.html
gmueckl 8y ago
All modern x86 CPUs do this to some extent. The details changed over the decades, but the basic principle these days is that the CPUs decode the x86 instruction set into a secret, internal only, more orthogonal sequence of instructions. My understanding is that these sequences can be quite long for the more involved CISC operations. And according to the manuals written by Agner Fox, some instructions even have special cases based on their operands to do something equivalent, but much faster. One particular example that I remember is xor ax,ax which is often used to set ax to zero and is a one byte instruction. Modern CPUs don't compute the xor in the ALU, but just rename ax to a register that is set to 0.
- teddyh 8y ago
  So in practice, nobody uses actual x86 assembly anymore, but everybody uses it as a target for compilation. It’s just like The Birth & Death of JavaScript¹, but non-fictional, and on a lower level – a Birth & Death of x86 assembly, if you will. 1. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
  - MrBuddyCasino 8y ago
    Or JVM byte code.
  - gameswithgo 8y ago
    >nobody uses actual x86 assembly anymore, well almost.

nickpsecurity 8y ago

"It wouldn't suprise me if modern CPUs actually added an additional step, where they first translate (compile?) the input stream into some internal instruction set, and then have microcode that acts as an interperator for that." Among Java processors, there was quite a mix of methods ranging from CISC to RISC to in-hardware to interpret-to-regular-CPU's: https://www.electronicdesign.com/embedded/java-processors https://www.electronicdesign.com/embedded/java-processors IBM's System/38 also did something with portable microcode that got converted to internal microcode: https://homes.cs.washington.edu/~levy/capabook/index.html https://homes.cs.washington.edu/~levy/capabook/index.html

gmueckl 8y ago

All modern x86 CPUs do this to some extent. The details changed over the decades, but the basic principle these days is that the CPUs decode the x86 instruction set into a secret, internal only, more orthogonal sequence of instructions. My understanding is that these sequences can be quite long for the more involved CISC operations. And according to the manuals written by Agner Fox, some instructions even have special cases based on their operands to do something equivalent, but much faster. One particular example that I remember is xor ax,ax which is often used to set ax to zero and is a one byte instruction. Modern CPUs don't compute the xor in the ALU, but just rename ax to a register that is set to 0.

teddyh 8y ago
So in practice, nobody uses actual x86 assembly anymore, but everybody uses it as a target for compilation. It’s just like The Birth & Death of JavaScript¹, but non-fictional, and on a lower level – a Birth & Death of x86 assembly, if you will. 1. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- MrBuddyCasino 8y ago
  Or JVM byte code.
- gameswithgo 8y ago
  >nobody uses actual x86 assembly anymore, well almost.