[webkit-dev] Webkit JavaScript question
Zoltan Herczeg
zherczeg at inf.u-szeged.hu
Fri May 22 11:23:20 PDT 2009
Hi,
Historical reasons. SF byte code had been implemented a year ago than jit.
SF byte code (interpreter) will never go away, since not all devices
support jit, and it is easier to generate JIT code from SF byte code than
from Abstract Syntax Tree. Perhaps the authors can tell you more about
this decision.
Zoltan
> Thanks.
>
> Can you please help me understand why SquirellFish needs to generate
> squirellFish byte code first before compile it to machine code?
>
> For v8, it "compiles JavaScript source code directly into machine code
> when it is first executed. There are no intermediate byte codes, no
> interpreter." http://code.google.com/apis/v8/design.html#mach_code
>
> Thank you.
>
>
> On Thu, May 21, 2009 at 2:12 PM, Zoltan Herczeg
> <zherczeg at inf.u-szeged.hu> wrote:
>> Hi,
>>
>> The JavaScript engine does 3 steps:
>> 1) Parse JS files
>> 2) Generate SquirellFish byte code (ByteCodeGenerator.h is part of it)
>> 3) Compile SF byte code to machine code by its JIT compiler (optional)
>>
>> The last step depends on the architecture (supported or not) and C++
>> compiler directives. If JIT is enabled (see wtf/Platform.h), it always
>> generates machine code. Otherwise an interpreter executes the byte code.
>> A
>> mixed environment (both jit and interpreter) is not yet supported.
>>
>> Zoltan
>>
>>> Hi,
>>>
>>> Can you please tell me what is the difference between
>>> ByteCodeGenerator.h and JIT.h?
>>>
>>> I assume ByteCodeGenerator is convert a raw .js file into JavaScript
>>> VM opecode and will be executed by Webkit JavaScript VM.
>>> and JIT convert a raw .js file into native machine code and will be
>>> executed by operating system of the browser?
>>>
>>> Is that correct?
>>> If yes, when/how does Webkit decide to use which approach?
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>
>>
>>
>
More information about the webkit-dev
mailing list