[webkit-dev] compile webkit on windows
Hi all I try to compile webkit on Window+cygwin+vs2005 ES(Sp1), But I got some error like this: QTMovieWin.obj : error LNK2001: external symbol __impCFStringMakeConstantString *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol __imp__CFStringGetCharacters *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol __imp__CFStringCompare *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol __imp__CFRelease *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol __imp__CFStringCreateWithCString *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol __imp__CFURLCreateWithString *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol __imp__kCFAllocatorDefault *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol __imp__CFStringHasPrefix *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol __imp__CFStringCreateWithCharacters *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol __imp__CFStringGetLength *is unresolved*。 d:\cygwin\zhangj\webkit\WebKitBuild\bin\QTMovieWin.dll : fatal error LNK1120: I installed QuickTime SDK and set the include/liberay folder. How can I fix that errors? Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] compile webkit on windows
Hi Did you try installing a safari ? Thanks Regards Niilesh 2009/3/6 jie zhang ketsu.c...@gmail.com: Hi all I try to compile webkit on Window+cygwin+vs2005 ES(Sp1), But I got some error like this: QTMovieWin.obj : error LNK2001: external symbol __imp CFStringMakeConstantString is unresolved。 QTMovieWin.obj : error LNK2001: external symbol __imp__CFStringGetCharacters is unresolved。 QTMovieWin.obj : error LNK2001: external symbol __imp__CFStringCompare is unresolved。 QTMovieWin.obj : error LNK2001: external symbol __imp__CFRelease is unresolved。 QTMovieWin.obj : error LNK2001: external symbol __imp__CFStringCreateWithCString is unresolved。 QTMovieWin.obj : error LNK2001: external symbol __imp__CFURLCreateWithString is unresolved。 QTMovieWin.obj : error LNK2001: external symbol __imp__kCFAllocatorDefault is unresolved。 QTMovieWin.obj : error LNK2001: external symbol __imp__CFStringHasPrefix is unresolved。 QTMovieWin.obj : error LNK2001: external symbol __imp__CFStringCreateWithCharacters is unresolved。 QTMovieWin.obj : error LNK2001: external symbol __imp__CFStringGetLength is unresolved。 d:\cygwin\zhangj\webkit\WebKitBuild\bin\QTMovieWin.dll : fatal error LNK1120: I installed QuickTime SDK and set the include/liberay folder. How can I fix that errors? Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] currently failing regression tests on Mac OS X Leopard
After fixing the test I could easily deal with myself, the following tests are failing for me: fast/block/float/t0905-c414-flt-fit-01-d-g.html fast/block/float/t0905-c5525-fltblck-00-d-ag.html fast/block/float/t0905-c5526-flthw-00-c-g.html It looks like the check-in to deal with the YinYang character included some incorrect test results, or at least results that don't work on my computer. We need to correct the test results. fast/repaint/transform-absolute-in-positioned-container.html Simon, you added this test originally so maybe you can figure out why it's giving me a result with an element 20 pixels wide instead of 40 now. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A question regarding to JavaScriptCore's C/C++ API.
ping. On Thu, Mar 5, 2009 at 2:44 PM, Zhe Su james...@gmail.com wrote: Hi, I'm developing an application which uses webkit's JavaScriptCore and a customized global object (by providing a special class when creating the context). My customized global object provides some built-in properties that can be accessed by javascript code. Now, I want to support a special behavior: allows javascript code to override a built-in property of global object by using variable declaraction statement. For example, assuming the global object has a built-in property, named foo, a var foo; statement shall create a javascript variable, named foo and the original built-in foo shall be overrid by this new javascript variable. But if there is no var foo; statement, the built-in foo shall be able to get and set from javascript code. Now the problem is, current JavaScriptCore's C API (especially those HasProperty, GetProperty, SetProperty callbacks of a class definition) can't distinguish variable delcaration statement and variable assigment statement. I checked SpiderMonkey's API and found it can distinguish such things by providing a flag when calling ResolveProperty callback. Do you have any idea on this issue? How can I implement such behavior based on current API? Regards James Su ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
On Mar 6, 2009, at 7:47 AM, Darin Adler da...@apple.com wrote: After fixing the test I could easily deal with myself, the following tests are failing for me: fast/block/float/t0905-c414-flt-fit-01-d-g.html fast/block/float/t0905-c5525-fltblck-00-d-ag.html fast/block/float/t0905-c5526-flthw-00-c-g.html It looks like the check-in to deal with the YinYang character included some incorrect test results, or at least results that don't work on my computer. We need to correct the test results. fast/repaint/transform-absolute-in-positioned-container.html This was caused by Hyatt's continuations patch. I filed a bug in Bugzilla and copied him. Simon, you added this test originally so maybe you can figure out why it's giving me a result with an element 20 pixels wide instead of 40 now. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
On Mar 6, 2009, at 8:01 AM, Dan Bernstein wrote: On Mar 6, 2009, at 7:47 AM, Darin Adler da...@apple.com wrote: After fixing the test I could easily deal with myself, the following tests are failing for me: fast/block/float/t0905-c414-flt-fit-01-d-g.html fast/block/float/t0905-c5525-fltblck-00-d-ag.html fast/block/float/t0905-c5526-flthw-00-c-g.html It looks like the check-in to deal with the YinYang character included some incorrect test results, or at least results that don't work on my computer. We need to correct the test results. fast/repaint/transform-absolute-in-positioned-container.html This was caused by Hyatt's continuations patch. I filed a bug in Bugzilla and copied him. When I mentioned this to Hyatt he said it was a progression, and a new expected should be checked in. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
On Mar 6, 2009, at 8:36 AM, Dimitri Glazkov wrote: Since I checked in the failing tests, I feel responsible, too. I'd say let's remove these tests and work to get the CSS2.1 suite updated. WDYT? I think it's an acceptable strategy to have these new separate tests. I just think someone needs to generate the correct expected results. Changing the CSS 2.1 suite itself would be OK, but I don't think it would have a big effect. We'd still need correct expected results. I think the main question is who will generate expected results that are correct for Mac OS X. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
Jungshik already did, just waiting for review: https://bugs.webkit.org/show_bug.cgi?id=23482 :DG On Fri, Mar 6, 2009 at 9:20 AM, Darin Adler da...@apple.com wrote: On Mar 6, 2009, at 8:36 AM, Dimitri Glazkov wrote: Since I checked in the failing tests, I feel responsible, too. I'd say let's remove these tests and work to get the CSS2.1 suite updated. WDYT? I think it's an acceptable strategy to have these new separate tests. I just think someone needs to generate the correct expected results. Changing the CSS 2.1 suite itself would be OK, but I don't think it would have a big effect. We'd still need correct expected results. I think the main question is who will generate expected results that are correct for Mac OS X. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
Oh wait. He did an in-place update patch. I'll ask him. :DG On Fri, Mar 6, 2009 at 9:25 AM, Dimitri Glazkov dglaz...@chromium.org wrote: Jungshik already did, just waiting for review: https://bugs.webkit.org/show_bug.cgi?id=23482 :DG On Fri, Mar 6, 2009 at 9:20 AM, Darin Adler da...@apple.com wrote: On Mar 6, 2009, at 8:36 AM, Dimitri Glazkov wrote: Since I checked in the failing tests, I feel responsible, too. I'd say let's remove these tests and work to get the CSS2.1 suite updated. WDYT? I think it's an acceptable strategy to have these new separate tests. I just think someone needs to generate the correct expected results. Changing the CSS 2.1 suite itself would be OK, but I don't think it would have a big effect. We'd still need correct expected results. I think the main question is who will generate expected results that are correct for Mac OS X. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
On Mar 6, 2009, at 9:25 AM, Dimitri Glazkov wrote: Jungshik already did, just waiting for review: https://bugs.webkit.org/show_bug.cgi?id=23482 I am really confused now. I thought we agreed to leave the CSS 2.1 tests alone unless the official test suite changed. I'd like to see a patch that just fixes the current regression test failures and doesn't make additional changes. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
On Fri, Mar 6, 2009 at 7:47 AM, Darin Adler da...@apple.com wrote: After fixing the test I could easily deal with myself, the following tests are failing for me: fast/block/float/t0905-c414-flt-fit-01-d-g.html fast/block/float/t0905-c5525-fltblck-00-d-ag.html fast/block/float/t0905-c5526-flthw-00-c-g.html It looks like the check-in to deal with the YinYang character included some incorrect test results, or at least results that don't work on my computer. We need to correct the test results. It may not be the only problem, but those tests are missing some necessary resources. None of the images in support/ that they look for are there. - Pam fast/repaint/transform-absolute-in-positioned-container.html Simon, you added this test originally so maybe you can figure out why it's giving me a result with an element 20 pixels wide instead of 40 now. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Safari 4 Beta now required for building Apple's Windows WebKit port
Hi everyone- As of today we now require Safari 4 Beta for building/running Apple's Windows WebKit port. Just a heads up! -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
Oops. I meant reply-to-all but just replied to Darin. 2009/3/6 Jungshik Shin (신정식, 申政湜) js...@chromium.org 2009/3/6 Darin Adler da...@apple.com On Mar 6, 2009, at 8:36 AM, Dimitri Glazkov wrote: Since I checked in the failing tests, I feel responsible, too. I'd say let's remove these tests and work to get the CSS2.1 suite updated. WDYT? I think it's an acceptable strategy to have these new separate tests. I just think someone needs to generate the correct expected results. Changing the CSS 2.1 suite itself would be OK, but I don't think it would have a big effect. We'd still need correct expected results. Sorry for all the confusion. I mentioned the following on IRC and in the bug, but perhaps, I was not clear enough. What happened was that test results are correct, but actual test files (html files) that were svn-copied to a new location were NOT revised in the new place. (my patch has new html files, but during the landing, svn-apply did not work as intended and svn-copied files without actual changes went int). As a result, there's a mismatch between the expected result and what's supposed to be new test files (that ARE actually just the copies of the original tests). So, we can do any of the following (I'm also replying to Darin's question here). 1. What Dave suggested on IRC. 1a. Revise the original CSS 2.1 tests in place and remove what's added recently. (this will be done by landing the latest patch in bug 23482) 1b. Same end result as 1a: - roll out what's added recently right away without waiting for Dave's r+. - once Dave gives me a nod for in-place modification of the original tests, make that change. 2. Leave the original tests alone and just update 'new' test html files in fast/block/float to match expected results. If we do 1a/1b, I'm willing to talk to Ian once more about our changes and talk him into revising CSS 2.1 suite the same way. I already asked him in the bugzilla, but he may have missed it. #2 was what was agreed upon and what my second latest patch does, but yesterday, Dave said that it's better to revise the original tests in place. So, I made the latest patch (3rd patch in the bug) and asked him for review. Jungshik I think the main question is who will generate expected results that are correct for Mac OS X. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A question regarding to JavaScriptCore's C/C++ API.
Hi Zhe. I'm developing an application which uses webkit's JavaScriptCore and a customized global object (by providing a special class when creating the context). My customized global object provides some built-in properties that can be accessed by javascript code. Now, I want to support a special behavior: allows javascript code to override a built-in property of global object by using variable declaraction statement. For example, assuming the global object has a built-in property, named foo, a var foo; statement shall create a javascript variable, named foo and the original built-in foo shall be overrid by this new javascript variable. But if there is no var foo; statement, the built-in foo shall be able to get and set from javascript code. Now the problem is, current JavaScriptCore's C API (especially those HasProperty, GetProperty, SetProperty callbacks of a class definition) can't distinguish variable delcaration statement and variable assigment statement. I checked SpiderMonkey's API and found it can distinguish such things by providing a flag when calling ResolveProperty callback. I'm surprised to hear that SpiderMonkey's property setting API includes a flag distinguishing var declarations from other kinds of property setting. Internet Explorer supports shadowing global properties with var declarations, but Firefox does not. (Perhaps you're thinking of the SpiderMonkey flag to distinguish x = y syntax from this.x = y syntax, which is slightly different.) It may not be my place, but I would discourage you from giving var declarations a special behavior, distinct from their behavior on the web. Much of the value of JavaScript derives from the fact that so many programmers understand how it works, due to their experience with the web. Do you have any idea on this issue? How can I implement such behavior based on current API? There is no API in JavaScriptCore for distinguishing between var and other property setting. I'm not sure how you would implement that. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] compile webkit on windows
Hi, 2009/3/6 jie zhang ketsu.c...@gmail.com: Hi all I try to compile webkit on Window+cygwin+vs2005 ES(Sp1), But I got some error like this: QTMovieWin.obj : error LNK2001: external symbol __imp CFStringMakeConstantString is unresolved。 [...] You do not have the Apple support libraries in your build path, either because you did not follow the instruction about doing so, or you did not follow the instruction about downloading and installing them (see http://webkit.org/building/checkout.html, Install the WebKit Support Libraries). These error messages indicate that you are missing the CoreFoundation.lib link library. Good luck! -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] want to port JIT to MIPS - can anybody explain JIT::linkCall?
e.g, emitted asm code before/after patch? what does its four pointers do? MacroAssembler::CodeLocationNearCall callReturnLocation; MacroAssembler::CodeLocationDataLabelPtr hotPathBegin; MacroAssembler::CodeLocationNearCall hotPathOther; MacroAssembler::CodeLocationLabel coldPathOther; CodeBlock* callee; anywhere got doc of the JIT implementations? thanks a lot! joe --- On Wed, 3/4/09, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: From: Zoltan Herczeg zherc...@inf.u-szeged.hu Subject: Re: [webkit-dev] want to port JIT to MIPS - how patchOffset* constant determined? To: webkit-dev@lists.webkit.org Date: Wednesday, March 4, 2009, 3:33 PM Hi, they generate instructions, which size is known in advance. Think about the following sequence: hotPathBegin: mov regX, 32bit_const - 6 bytes (*) (**) add regX, regY - 2 bytes jo 32bit_addr - 5 bytes (*) * (Note) : these instructions will be modified during runtime. ** (Note) : there is a short form for mov regX, 8bit_const, which length is only 3 bytes, but they force the longer version in such cases to keep the size of the instruction. As you can see, the address of jo is always (hotPathBegin + 6 + 2). They simply introduce a new constant: patchOffsetXXX = 8, and use this constant to access the jo instruction later. In ARM we can't rely on such constant, because the constant pool can be placed after any instruction. hotPathBegin: ldr rX, [pc + const_pool_addr] ; 32 bit const [...] - the const pool can be placed here add rX, rX, rY [...] - the const pool can be placed here hotPath2: ldr pc, [pc + const_pool_addr] ; 32 bit target address We need to store both pointers (hotPathBegin and hotPath2). Zoltan Zoltan, Thanks for reply, I'm trying to understand your example. But,X86 instruction size is from 1 to 17bytes, not constant. I may misunderstand your comments? Many X86 instruction can have imm32 at the end, thus this pointer can be used for patch as well as next address after call. Does Arm have similar things? or else you still need to figure out why patchOffsetOpCallCompareToJump = 9;? may be some instruction lengths relates to the 9? rgds joe --- On Wed, 3/4/09, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: From: Zoltan Herczeg zherc...@inf.u-szeged.hu Subject: Re: [webkit-dev] want to port JIT to MIPS - how patchOffset* constant determined? To: webkit-dev@lists.webkit.org Date: Wednesday, March 4, 2009, 3:45 AM On x86, the size of the instructions are fixed. If you want to access multiple instructions in the instruction stream, you only need to store the address of the first one, and can access the others by their relative address. This saves a little memory. Example (see JIT::linkCall): instruction at callLinkInfo-hotPathBegin: points to callee comparison instruction at callLinkInfo-hotPathBegin + patchOffsetOpCallCompareToJump: points to the slow case entry jump Zoltan in jit.h, for example: static const int patchOffsetOpCallCompareToJump = 9; static const int patchOffsetPutByIdStructure = 7; static const int patchOffsetPutByIdPropertyMapOffset = 22; static const int patchOffsetGetByIdBranchToSlowCase = 13; thanks for help, I'm stucked here now. joe --- On Sat, 2/28/09, Gavin Barraclough barraclo...@apple.com wrote: From: Gavin Barraclough barraclo...@apple.com Subject: Re: [webkit-dev] want to port JIT to MIPS - JIT reg usage clean up? To: WebKit Development webkit-dev@lists.webkit.org Date: Saturday, February 28, 2009, 12:19 PM On Feb 27, 2009, at 4:55 PM, x yz wrote: The regTx seems to be working registers here, yet their definition are regparm(3) registers for function arugments. Such usage would cause conflict on other platforms. May I suggest that we use individual defined set of regs for func i/o argument and working? First up, I think you're getting slightly confused about regparm(3). This is not used anywhere in the JS language JIT, only in WREC. In some configurations of the JIT we use fastcall semantics on x86... but none of this is really relevant to MIPS. Just ignore all this. Stick to the default MIPS ABI for stub functions. Reading between the lines, I'm guessing your concern here is that in setting up arguments for a JIT stub call you may trample the JIT's temporary registers? If so, I think you need to look at the argument passing more closely. The mechanisms to pass arguments to stub functions pass all arguments in memory – typically passing a single pointer to the stub functions, which can be used to retrieve the arguments. This pointer argument can be set up immediately prior to the call, so it does not interfere with the regT?
Re: [webkit-dev] A question regarding to JavaScriptCore's C/C++ API.
Thanks for your reply. On Sat, Mar 7, 2009 at 7:41 AM, Geoffrey Garen gga...@apple.com wrote: Hi Zhe. I'm developing an application which uses webkit's JavaScriptCore and a customized global object (by providing a special class when creating the context). My customized global object provides some built-in properties that can be accessed by javascript code. Now, I want to support a special behavior: allows javascript code to override a built-in property of global object by using variable declaraction statement. For example, assuming the global object has a built-in property, named foo, a var foo; statement shall create a javascript variable, named foo and the original built-in foo shall be overrid by this new javascript variable. But if there is no var foo; statement, the built-in foo shall be able to get and set from javascript code. Now the problem is, current JavaScriptCore's C API (especially those HasProperty, GetProperty, SetProperty callbacks of a class definition) can't distinguish variable delcaration statement and variable assigment statement. I checked SpiderMonkey's API and found it can distinguish such things by providing a flag when calling ResolveProperty callback. I'm surprised to hear that SpiderMonkey's property setting API includes a flag distinguishing var declarations from other kinds of property setting. Internet Explorer supports shadowing global properties with var declarations, but Firefox does not. (Perhaps you're thinking of the SpiderMonkey flag to distinguish x = y syntax from this.x = y syntax, which is slightly different.) SpiderMonkey can distinguish among many different type of statements. See https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Reference/JSNewResolveOp It may not be my place, but I would discourage you from giving var declarations a special behavior, distinct from their behavior on the web. Much of the value of JavaScript derives from the fact that so many programmers understand how it works, due to their experience with the web. I also don't want to support such non-standard behavior, however we need support legacy javascript code written for windows which rely on this behavior. What a pity. Anyway, thanks for your reply. Do you have any idea on this issue? How can I implement such behavior based on current API? There is no API in JavaScriptCore for distinguishing between var and other property setting. I'm not sure how you would implement that. JavaScriptCore's API is simple and easy to use, however in most cases, it's too simple to achieve some feature, comparing to SpiderMonkey, which is too complex and flexible. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] want to port JIT to MIPS - can anybody explain JIT::linkCall?
The hot path for a call performs a check for a specific callee, with a fast mechanism for making JS-JS calls. The code is generated such that it will initially always bail out to the slow path, and the second time the call is executed it will dynamically linked itself to that callee. There are currently two slow paths generated for each callee, the initial one that calls out to relink the code, and a second form that does not. hotPathBegin hotPathOther are used (along with an offset) to find three things to repatch in the hot path: (1) The JSFunction* value that is checked, to identify the callee (2) The jump out to the slow path, so this can be relinked to the second form (which will not attempt to relink – this is stored in coldPathOther). (3) The call instruction to be linked the callee's code. The value callReturnLocation points to the call in the cold path to the relink mechanisms. This is used by the dynamic linking mechanisms to lookup the CallLinkInfo record describing the call to be linked, and is also used in exception handling. G. On Mar 6, 2009, at 5:40 PM, x yz wrote: e.g, emitted asm code before/after patch? what does its four pointers do? MacroAssembler::CodeLocationNearCall callReturnLocation; MacroAssembler::CodeLocationDataLabelPtr hotPathBegin; MacroAssembler::CodeLocationNearCall hotPathOther; MacroAssembler::CodeLocationLabel coldPathOther; CodeBlock* callee; anywhere got doc of the JIT implementations? thanks a lot! joe --- On Wed, 3/4/09, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: From: Zoltan Herczeg zherc...@inf.u-szeged.hu Subject: Re: [webkit-dev] want to port JIT to MIPS - how patchOffset* constant determined? To: webkit-dev@lists.webkit.org Date: Wednesday, March 4, 2009, 3:33 PM Hi, they generate instructions, which size is known in advance. Think about the following sequence: hotPathBegin: mov regX, 32bit_const - 6 bytes (*) (**) add regX, regY - 2 bytes jo 32bit_addr - 5 bytes (*) * (Note) : these instructions will be modified during runtime. ** (Note) : there is a short form for mov regX, 8bit_const, which length is only 3 bytes, but they force the longer version in such cases to keep the size of the instruction. As you can see, the address of jo is always (hotPathBegin + 6 + 2). They simply introduce a new constant: patchOffsetXXX = 8, and use this constant to access the jo instruction later. In ARM we can't rely on such constant, because the constant pool can be placed after any instruction. hotPathBegin: ldr rX, [pc + const_pool_addr] ; 32 bit const [...] - the const pool can be placed here add rX, rX, rY [...] - the const pool can be placed here hotPath2: ldr pc, [pc + const_pool_addr] ; 32 bit target address We need to store both pointers (hotPathBegin and hotPath2). Zoltan Zoltan, Thanks for reply, I'm trying to understand your example. But,X86 instruction size is from 1 to 17bytes, not constant. I may misunderstand your comments? Many X86 instruction can have imm32 at the end, thus this pointer can be used for patch as well as next address after call. Does Arm have similar things? or else you still need to figure out why patchOffsetOpCallCompareToJump = 9;? may be some instruction lengths relates to the 9? rgds joe --- On Wed, 3/4/09, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: From: Zoltan Herczeg zherc...@inf.u-szeged.hu Subject: Re: [webkit-dev] want to port JIT to MIPS - how patchOffset* constant determined? To: webkit-dev@lists.webkit.org Date: Wednesday, March 4, 2009, 3:45 AM On x86, the size of the instructions are fixed. If you want to access multiple instructions in the instruction stream, you only need to store the address of the first one, and can access the others by their relative address. This saves a little memory. Example (see JIT::linkCall): instruction at callLinkInfo-hotPathBegin: points to callee comparison instruction at callLinkInfo-hotPathBegin + patchOffsetOpCallCompareToJump: points to the slow case entry jump Zoltan in jit.h, for example: static const int patchOffsetOpCallCompareToJump = 9; static const int patchOffsetPutByIdStructure = 7; static const int patchOffsetPutByIdPropertyMapOffset = 22; static const int patchOffsetGetByIdBranchToSlowCase = 13; thanks for help, I'm stucked here now. joe --- On Sat, 2/28/09, Gavin Barraclough barraclo...@apple.com wrote: From: Gavin Barraclough barraclo...@apple.com Subject: Re: [webkit-dev] want to port JIT to MIPS - JIT reg usage clean up? To: WebKit Development webkit-dev@lists.webkit.org Date: Saturday, February 28, 2009, 12:19 PM On Feb 27, 2009, at 4:55 PM, x yz wrote: The regTx seems to be working registers here, yet their definition are regparm(3) registers for function arugments. Such usage would cause conflict on other platforms. May I suggest that we use individual defined set of regs for func i/o
