This sounds good in general, although as I pointed out on IRC and will repeat for benefit of others here, I don't think "bytecode" and "opcode" are really synonyms. My understanding of the word would be:
- bytecode is a mass noun, like "machine code" - you can't have "a bytecode" - a singular unit of bytecode is an "instruction", or "bytecode instruction" if you must - the part of the instruction that says operation to perform, rather than what the operands are, is an "opcode"
Fixed.
* "BytecodeGenerator"
The class used to generate bytecode. "Generator" clearly indicates that the class outputs bytecode, whereas a name like "compiler" might mean that the class outputs bytecode, or it might mean that the class takes bytecode as its input. Also, we thought that names like "compiler" implied a larger suite of tools not included in this class.
I do believe that the term Bytecompiler specifically refers to a compiler that outputs bytecode, and can never refer to a compiler that takes bytecode as input instead. It's a little shorter. But technically our bytecompiler encompasses not just the BytecodeGenerator class but also all the emit functions in Nodes.cpp, so I'd probably use it for a directory, not a class.
* "BytecodeInterpreter"
The class that executes a program in bytecode form. We liked the symmetry with "BytecodeGenerator". We rejected names like BytecodeVM because we thought the name "virtual machine" was a little too vague, and it implied a larger suite of functionality not limited to this class.
* "JIT"
The class that translates a program in bytecode form to CPU- specific code. We rejected "BytecodeJIT" because we couldn't tell if a BytecodeJIT had bytecode as its input or its output. It's not symmetric with BytecodeInterpreter, but oh well. We liked "JIT" because we thought that interpreter vs JIT was a widely used and understood dichotomy.
I like all of these.
Cameron and I now regret "BytecodeInterpreter". We think "JSC::Interpreter" is pretty darn clear, and it matches "JSC::JIT". Putting "bytecode" in the name just feels redundant. JSC has no non- bytecode interpreters. What do you think?
So we have this directory structure:
bytecode -> generator -> interpreter -> jit -> sampler
I'm not sure I like having a lot of subdirectories under bytecode though, particularly since they will each contain so few files. I'd propose:
- bytecodegenerator or bytecompiler at top level (Bytecompiler is a slightly more concise term of art for a compiler that outputs bytecode, with no ambiguity about whether the bytecode is going in or out) - a bytecode directory at top level containing general bytecode data structures and the bytecode interpreter - a jit directory at top level - sampler stuff relegated to one of the above
That's more in line with the directory structure we all discussed before, and which we've barely had a chance to get used to.
On IRC, we agreed to: bytecode: holds CodeBlock*, EvalCodeCache.h, Opcode*, Instruction.h bytecompiler: holds BytecodeGenerator*, RegisterID.h, Label.h, LabelScope.h, SegmentedVector.h interpreter: holds BytecodeInterpreter (Interpreter?), Register.h, RegisterFile* jit: holds JIT*, JITStubs* Geoff