JavaScriptCore renames
I carried out the renames that we discussed a long time ago on webkit- dev in order to remove the kjs/ directory. I don't think these were perfect, although very few involved renaming files. The final 'approval' process for these was carried out over IRC. There is now talk of new renames on the horizon off of this list, but I think we should bring it up for discussion here and come to a reasonable consensus. Cameron
There is now talk of new renames on the horizon off of this list, but I think we should bring it up for discussion here and come to a reasonable consensus.
I have a > 2MB rename+move patch, which I developed after a morning- long conversation with 4-5 WebKit contributors. Sam just finished reviewing it in my office. Your input -- and others' -- on names is certainly welcome. If there are names that you don't like, by all means, let's come up with better ones. However, I don't think we need to subject this patch to any scrutiny above and beyond the normal contribution guidelines. Do you? Geoff
On 14-Nov-08, at 5:48 PM, Geoffrey Garen wrote:
There is now talk of new renames on the horizon off of this list, but I think we should bring it up for discussion here and come to a reasonable consensus.
I have a > 2MB rename+move patch, which I developed after a morning- long conversation with 4-5 WebKit contributors. Sam just finished reviewing it in my office.
Your input -- and others' -- on names is certainly welcome. If there are names that you don't like, by all means, let's come up with better ones. However, I don't think we need to subject this patch to any scrutiny above and beyond the normal contribution guidelines. Do you?
There was more scrutiny than a normal patch for the last round of file moves. I don't think this set of files renames should be any different. Do you? Cameron
There was more scrutiny than a normal patch for the last round of file moves. I don't think this set of files renames should be any different. Do you?
I can't speak to what procedure you followed when moving files -- I don't know what it was. If you're asking, do I think I need even more than 4-5 people's input before checking in a patch, no, I don't think I do. Like I said before, though, your input -- and other's -- is certainly welcome. A simple way to provide input is to suggest new names for things you don't like. Geoff
On Nov 14, 2008, at 5:51 PM, Cameron Zwarich wrote:
On 14-Nov-08, at 5:48 PM, Geoffrey Garen wrote:
There is now talk of new renames on the horizon off of this list, but I think we should bring it up for discussion here and come to a reasonable consensus.
I have a > 2MB rename+move patch, which I developed after a morning- long conversation with 4-5 WebKit contributors. Sam just finished reviewing it in my office.
Your input -- and others' -- on names is certainly welcome. If there are names that you don't like, by all means, let's come up with better ones. However, I don't think we need to subject this patch to any scrutiny above and beyond the normal contribution guidelines. Do you?
There was more scrutiny than a normal patch for the last round of file moves. I don't think this set of files renames should be any different. Do you?
We can always re-rename things. The reason we normally have more up- front discussion of renames is because they are more disruptive and more work, so it is a greater cost to redo them if someone has input after the fact. That being said, an overview of the renames planned would be helpful. - Maciej
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
On Nov 15, 2008, at 12:07 PM, Geoffrey Garen wrote:
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.
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"
* "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.
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.
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.
I'm not a huge fan of this but I must admit m_jit would be wrong and saying m_assembler all the time would strain readability. Regards, Maciej
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
On Nov 15, 2008, at 3:33 PM, Geoffrey Garen wrote:
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?
I agree. The old Interpreter class is the only thing that prevented me from suggesting this long ago.
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*
Sounds great. - Maciej
participants (3)
-
Cameron Zwarich
-
Geoffrey Garen
-
Maciej Stachowiak