[squirrelfish] JavaScriptCore renames

[Geoffrey Garen]

> 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