Comment by o11c 2 days ago
In theory, an emulator is oriented around producing a result (this may mean making acceptable compromises), whereas a simulator is oriented around inspection of state (this usually means being exact).
In practice the terms are often conflated.
compiler creates a binary in elf format or other format which can be run given a shared object exists.
Intepreter either writes it in bytecode and then executes the bytecode line by line ?
Atleast that is what I believe the difference is , care to elaborate , is there some hidden joke of compiler vs intepreter that I don't know about ?
I assume GP meant that a lot of compilers also interpret and interpreters also compile.
For compilers, constant folding is a pretty obvious optimization. Instead of compiling constant expressions, like 1+2, to code that evaluates those expressions, the compiler can already evaluate it itself and just produce the final result, in this case 3.
Then, some language features require compilers to perform some interpretation, either explicitly like C++'s constexpr, or implicitly, like type checking.
Likewise, interpreters can do some compilation. You already mentioned bytecode. Producing the bytecode is a form of compilation. Incidentally, you can skip the bytecode and interpret a program by, for example, walking its abstract syntax tree.
Also, compilers don't necessarily create binaries that are immediately runnable. Java's compiler, for example, produces JVM bytecode, which requires a JVM to be run. And TypeScript's compiler outputs JavaScript.
Then what is the difference, I always thought of Java as closer to python in the sense that it's running the byte code. And python also has bytecode.
I don't know what the difference is , I know there can be intepreters of compilers but generally speaking it's hard to find compilers of intepreters
Eg C++ has compilers , intepreters both (cpi) , gcc
Js doesn't have compilers IIRC , it can have transpilers Js2c is good one but i am not sure if they are failsafe (70% ready) ,
I also have to thank you , this is a great comment
While an interpreter can do optimizations, they do not produce "byte code" -- by that time they are compilers!
As for the comparison with the JVM .. compare to a compiler that produces x86 code, it cannot be run without an x86 machine. You need a machine to run something, be it virtual or not.
I would generalize it to a compiler produces some sort of artifact that is intended to later be used directly, while for an interpreter the whole mechanism(source to execution) is intended to be used directly.
The same tool can often be used to do both. trival example: a web browser. save your web page as a pdf? compiler. otherwise interpreter. but what if the code it is executing is not artisanal handcrafted js but the result of a typescript compiler?
An interpreter runs the code as it is being read in.
A compiler processes the code and provides an intermediate result which is then "interpreted" by the machine.
So to take the "writes it in byte code" -- that is a compiler. "executes the byte code" -- is the interpreter.
If byte code is "machine code" or not, is really secondary.
Then isn't theoretically all languages assembly intepreters in the endd
Adding some anecdata, I feel like emulator is mainly used in the context of gaming, in which case they actually care a great deal about accurate reproduction (see: assembly bugs in N64 emulators that had to be reproduced in order to build TAS). I haven't seen it used much for old architectures; instead I'd call those virtual machines.
definitely agree on simulator though!
The difference is about as crystal clear as compiler/interpreter.