[squirrelfish] JavaScriptCore renames

[Geoffrey Garen]

> That being said, an overview of the renames planned would be helpful.

Okeedokee.

After much discussion, we concluded that almost all names in the field  
of virtual machines are potentially problematic, because each name can  
mean different things in different contexts, and each name usually  
fails to say precisely what it means. For example, "JIT", which  
technically just stands for "Just In Time", could refer to any of a  
million different processes on a computer, including the "just in  
time" initialization of a data member in a class. Even if we allow  
that "JIT" implicitly refers to CPU-specific translation at runtime,  
making it less vague, "just in time" is still an inaccurate phrase,  
since function-at-a-time translation will translate unlikely basic  
blocks well before they execute -- if they execute at all. Even the  
phrase "virtual machine" is problematic, since the CPU itself is a  
kind of virtual machine. It's turtles all the way down.

However, none of this changes the fact that we use certain names as  
terms of art  all the time. So, we decided to shun the siren song of  
perfect, technically accurate naming, and settle on names that  
reflected our basic everyday thinking and speech.

Therefore:

* "Bytecode"

Anything in JavaScript currently called "byte code" "opcode" "op code"  
"code" "bitcode" etc. we'll rename to "bytecode". We use one word with  
no camel case to indicate that the word is just jargon, and not a true  
compound word. It's not really one byte, but we're over that. We use  
this word every day when talking about our code, so we'll use it in  
our code, too.

* "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.

* "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.

So we have this directory structure:

bytecode
	-> generator
	-> interpreter
	-> jit
	-> sampler

It bears mentioning that JavaScriptCore also contains a bytecode and a  
JIT for regular expressions, so the names above might be vague. We  
decided that the best solution was to treat regular expression  
functionality as secondary, giving classes related to it an extra  
prefix, or a different namespace. We also decided not to bother  
changing the nomenclature in PCRE, because PCRE is frozen in time.  
Also, PCRE hurts me in the brain.

Many other small renames and file splittings are included in my patch,  
but they all tend to follow from these. The only substantial one I can  
think of is "__". Right now we have code like this:

m_jit.movl_i32r(...)

In this context, "m_jit" is a data member of "JIT", and an instance of  
the "X86Assembler" class. JIT::m_jit is weird, and calling an  
assembler a JIT is also weird. So, we opted to renamed "m_jit" to  
"m_assembler", and then for brevity, use a macro to replace  
"m_assembler." with "__", so you get this:

__ movl_i32r(...)

There are a few cases where this looks a little weird right now, but  
they're fixable. In general, this approach has worked well for other  
projects, so it will probably work well for us.

Cheers,
Geoff