Re: [webkit-dev] x32 support of JavaScriptCore

2012-10-12 Thread Xian, Yuqiang
Thank you Gavin.

I have created a bug entry and proposed a patch for MacroAssembler refactoring 
at https://bugs.webkit.org/show_bug.cgi?id=99154.

Also, a bug entry is created to trace the x32 support of JavaScriptCore at 
https://bugs.webkit.org/show_bug.cgi?id=99153. There you could also find how 
the code should be (based on the refactoring work) to support x32 in 
JavaScriptCore. Note that currently the low level interpreter on x32 is not 
enabled yet but on the plan.

Would you like to have a look at them?

Thanks much, -Yuqiang

-Original Message-
From: Gavin Barraclough [mailto:barraclo...@apple.com] 
Sent: 2012年10月12日 2:22
To: Xian, Yuqiang
Cc: WebKit Development
Subject: Re: [webkit-dev] x32 support of JavaScriptCore

Hi Yuqiang,

I think that this could be a good refactoring for the MacroAssembler – to move 
all ( Ptr-32 / Ptr-64 ) remapping into MacroAssembler.h, introduce a Imm64, 
rename all the current *Ptr* methods in MacroAssemblerX86_64 to *64*, etc – 
please feel free to put up patches for this, and cc me.  If this is the bulk of 
your changes, it may not be a problem to upstream support if you'll be prepared 
to maintain, and if that doesn't work out it should at least reduce the size of 
your diff.  We prefer incremental changes, so please split out any refactoring 
that will affect all platforms from changes to support x32, these should be 
landed separately.

cheers,
G.


On Oct 11, 2012, at 1:52 AM, Xian, Yuqiang wrote:

 On X32, the size of a pointer or a long integer is 4 bytes instead of 8 
 bytes on X64, while the register size is still 8 bytes.
 
 In JavaScriptCore implementation for X64, it assumes that the JSValue size is 
 same to the pointer size, and thus EncodedJSValue is simply type defined as a 
 void*. In the JIT compiler, we also take this assumption and invoke the 
 same macro assembler interface for both JSValue and pointer operands. So the 
 primary task for x32 support is to differentiate the operations on pointers 
 from the operations on JSValues, and let them invoking different macro 
 assembler interfaces. For example, we now use the interface of loadPtr to 
 load either a pointer or a JSValue, and we need to switch to using loadPtr 
 to load a pointer and some new load64 interface to load a JSValue.
 The major modification I made is to introduce the *64 interfaces in the 
 MacroAssembler, make the *Ptr interfaces platform dependent implemented 
 (one for X32 and the other for X64), and go through all the JIT compiler code 
 to identify which interfaces should be used.
 Also, the calling convention needs to be cared. For example on X64 you may 
 need two registers to pass or return a structure with two pointer size 
 members, while on X32 those two members are placed in one register.
 
 Thanks, -Yuqiang
 
 -Original Message-
 From: Zoltan Herczeg [mailto:zherc...@webkit.org] 
 Sent: 2012年10月11日 15:43
 To: Xian, Yuqiang
 Cc: Kenneth Rohde Christiansen; webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] x32 support of JavaScriptCore
 
 Just out of curiosity, how much code modifications are required? I read
 the ABI documentation the link you attached, and x32 is a regular 64 bit
 mode, except it seems to me that the global descriptor table is tweaked to
 store the same descriptors for all 4G address spaces, so the upper 32 bit
 is basically ignored when you access a memory address. It is called Small
 Code Model or something. I suspect the changes in the JIT code are
 minimal.
 
 Regards,
 Zoltan
 
 Thanks for the suggestions, Kenneth.
 
 I'm refining the code and trying to enable the last major component - the
 low level interpreter for x32.
 Yes it's ideal if we can upstream the code, and as you mentioned, keep
 maintaining it. The buildbot is a good idea while we are still way far
 from it - it requires a mature x32 system which at least supports all of
 the things that a WebKit port depends on. I know there're efforts porting
 Gentoo and Fedora to x32 - we may depend on each other.
 
 Currently I'm testing the JSC shell only. Though I use the EFL port, I
 eliminated most of the unnecessary dependencies on EFL libraries to run
 the JSC shell, so that I don't need to put efforts on compiling and
 enabling those dependencies for x32 at current stage.
 
 Thanks, -Yuqiang
 
 -Original Message-
 From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com]
 Sent: 2012年10月11日 5:51
 To: Xian, Yuqiang
 Cc: webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] x32 support of JavaScriptCore
 
 Hi,
 
 I don't think another branch on webkit.org will help you much; then
 you can as well have a branch anywhere.
 
 If you want this code to be well tested and maintained, you need to
 get it upstream (through all the review process) and promise that you
 have resources to keep maintaining it. It will also be an advantage if
 we can get a buildbot running this exact configuration, so that others
 can make sure they don't break your

Re: [webkit-dev] x32 support of JavaScriptCore

2012-10-11 Thread Xian, Yuqiang
Thanks for the suggestions, Kenneth.

I'm refining the code and trying to enable the last major component - the low 
level interpreter for x32.
Yes it's ideal if we can upstream the code, and as you mentioned, keep 
maintaining it. The buildbot is a good idea while we are still way far from it 
- it requires a mature x32 system which at least supports all of the things 
that a WebKit port depends on. I know there're efforts porting Gentoo and 
Fedora to x32 - we may depend on each other.

Currently I'm testing the JSC shell only. Though I use the EFL port, I 
eliminated most of the unnecessary dependencies on EFL libraries to run the JSC 
shell, so that I don't need to put efforts on compiling and enabling those 
dependencies for x32 at current stage.

Thanks, -Yuqiang

-Original Message-
From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com] 
Sent: 2012年10月11日 5:51
To: Xian, Yuqiang
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] x32 support of JavaScriptCore

Hi,

I don't think another branch on webkit.org will help you much; then
you can as well have a branch anywhere.

If you want this code to be well tested and maintained, you need to
get it upstream (through all the review process) and promise that you
have resources to keep maintaining it. It will also be an advantage if
we can get a buildbot running this exact configuration, so that others
can make sure they don't break your code.

I think that whether the community will accept it upstream depends
much about your commitment and the quality of the code, as well as how
well you interact with the community during the reviews.

Which port of WebKit is you currently using for testing?

Cheers
Kenneth


On Wed, Oct 10, 2012 at 5:02 PM, Xian, Yuqiang yuqiang.x...@intel.com wrote:
 Hi,



 As you may already know there’s a new x32 ABI – a 32-bit psABI for x86-64
 with 32-bit pointer size. It tries to leverage the advantage of more
 registers and IP relative addressing from x64 and the advantage of smaller
 memory footprint from IA32. You can find more details of the x32 ABI here:
 https://sites.google.com/site/x32abi/.



 The Linux kernel supports x32 since 3.4, and the commonly used development
 tools and libraries are getting in the x32 support. Also more details about
 current status is available in the above link.



 Now back to WebKit. In theory most part of the WebKit code should be fine
 (or require less efforts) to support x32, if they’re pure C++ code and can
 be compiled with the x32 toolchain. The major challenge is the JIT compiler
 in the JavaScript engine (and the low level interpreter) and some
 hand-written assembly code. So I’m currently working on enabling the x32
 support of JavaScriptCore, the WebKit JavaScript engine, to try to remove
 the major obstacle. My current status is that I have enabled the baseline
 JIT, the DFG JIT and the Yarr JIT on x32 – it passes all the JavaScriptCore
 tests and the 3 major benchmarks.



 I’m posting this message in order to seek for some advices on how we should
 have our work shared to more people. I understand that it’s not very
 appropriate to try to get it into current WebKit trunk considering current
 x32 support status in major systems and the lack of maintenance in upstream,
 but we want to keep it synchronized with the newest changes of the WebKit
 code. So is it possible for us to maintain the code in a separate branch
 hosted at the WebKit server?



 Any suggestions are appreciated.



 Thanks, -Yuqiang


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev




-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

﹆﹆﹆
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] x32 support of JavaScriptCore

2012-10-11 Thread Zoltan Herczeg
Just out of curiosity, how much code modifications are required? I read
the ABI documentation the link you attached, and x32 is a regular 64 bit
mode, except it seems to me that the global descriptor table is tweaked to
store the same descriptors for all 4G address spaces, so the upper 32 bit
is basically ignored when you access a memory address. It is called Small
Code Model or something. I suspect the changes in the JIT code are
minimal.

Regards,
Zoltan

 Thanks for the suggestions, Kenneth.

 I'm refining the code and trying to enable the last major component - the
 low level interpreter for x32.
 Yes it's ideal if we can upstream the code, and as you mentioned, keep
 maintaining it. The buildbot is a good idea while we are still way far
 from it - it requires a mature x32 system which at least supports all of
 the things that a WebKit port depends on. I know there're efforts porting
 Gentoo and Fedora to x32 - we may depend on each other.

 Currently I'm testing the JSC shell only. Though I use the EFL port, I
 eliminated most of the unnecessary dependencies on EFL libraries to run
 the JSC shell, so that I don't need to put efforts on compiling and
 enabling those dependencies for x32 at current stage.

 Thanks, -Yuqiang

 -Original Message-
 From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com]
 Sent: 2012年10月11日 5:51
 To: Xian, Yuqiang
 Cc: webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] x32 support of JavaScriptCore

 Hi,

 I don't think another branch on webkit.org will help you much; then
 you can as well have a branch anywhere.

 If you want this code to be well tested and maintained, you need to
 get it upstream (through all the review process) and promise that you
 have resources to keep maintaining it. It will also be an advantage if
 we can get a buildbot running this exact configuration, so that others
 can make sure they don't break your code.

 I think that whether the community will accept it upstream depends
 much about your commitment and the quality of the code, as well as how
 well you interact with the community during the reviews.

 Which port of WebKit is you currently using for testing?

 Cheers
 Kenneth


 On Wed, Oct 10, 2012 at 5:02 PM, Xian, Yuqiang yuqiang.x...@intel.com
 wrote:
 Hi,



 As you may already know there’s a new x32 ABI – a 32-bit psABI for
 x86-64
 with 32-bit pointer size. It tries to leverage the advantage of more
 registers and IP relative addressing from x64 and the advantage of
 smaller
 memory footprint from IA32. You can find more details of the x32 ABI
 here:
 https://sites.google.com/site/x32abi/.



 The Linux kernel supports x32 since 3.4, and the commonly used
 development
 tools and libraries are getting in the x32 support. Also more details
 about
 current status is available in the above link.



 Now back to WebKit. In theory most part of the WebKit code should be
 fine
 (or require less efforts) to support x32, if they’re pure C++ code and
 can
 be compiled with the x32 toolchain. The major challenge is the JIT
 compiler
 in the JavaScript engine (and the low level interpreter) and some
 hand-written assembly code. So I’m currently working on enabling the
 x32
 support of JavaScriptCore, the WebKit JavaScript engine, to try to
 remove
 the major obstacle. My current status is that I have enabled the
 baseline
 JIT, the DFG JIT and the Yarr JIT on x32 – it passes all the
 JavaScriptCore
 tests and the 3 major benchmarks.



 I’m posting this message in order to seek for some advices on how we
 should
 have our work shared to more people. I understand that it’s not very
 appropriate to try to get it into current WebKit trunk considering
 current
 x32 support status in major systems and the lack of maintenance in
 upstream,
 but we want to keep it synchronized with the newest changes of the
 WebKit
 code. So is it possible for us to maintain the code in a separate
 branch
 hosted at the WebKit server?



 Any suggestions are appreciated.



 Thanks, -Yuqiang


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev




 --
 Kenneth Rohde Christiansen
 Senior Engineer, WebKit, Qt, EFL
 Phone  +45 4093 0598 / E-mail kenneth at webkit.org

 ﹆﹆﹆
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] x32 support of JavaScriptCore

2012-10-11 Thread Xian, Yuqiang
On X32, the size of a pointer or a long integer is 4 bytes instead of 8 bytes 
on X64, while the register size is still 8 bytes.

In JavaScriptCore implementation for X64, it assumes that the JSValue size is 
same to the pointer size, and thus EncodedJSValue is simply type defined as a 
void*. In the JIT compiler, we also take this assumption and invoke the same 
macro assembler interface for both JSValue and pointer operands. So the primary 
task for x32 support is to differentiate the operations on pointers from the 
operations on JSValues, and let them invoking different macro assembler 
interfaces. For example, we now use the interface of loadPtr to load either a 
pointer or a JSValue, and we need to switch to using loadPtr to load a 
pointer and some new load64 interface to load a JSValue.
The major modification I made is to introduce the *64 interfaces in the 
MacroAssembler, make the *Ptr interfaces platform dependent implemented (one 
for X32 and the other for X64), and go through all the JIT compiler code to 
identify which interfaces should be used.
Also, the calling convention needs to be cared. For example on X64 you may need 
two registers to pass or return a structure with two pointer size members, 
while on X32 those two members are placed in one register.

Thanks, -Yuqiang

-Original Message-
From: Zoltan Herczeg [mailto:zherc...@webkit.org] 
Sent: 2012年10月11日 15:43
To: Xian, Yuqiang
Cc: Kenneth Rohde Christiansen; webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] x32 support of JavaScriptCore

Just out of curiosity, how much code modifications are required? I read
the ABI documentation the link you attached, and x32 is a regular 64 bit
mode, except it seems to me that the global descriptor table is tweaked to
store the same descriptors for all 4G address spaces, so the upper 32 bit
is basically ignored when you access a memory address. It is called Small
Code Model or something. I suspect the changes in the JIT code are
minimal.

Regards,
Zoltan

 Thanks for the suggestions, Kenneth.

 I'm refining the code and trying to enable the last major component - the
 low level interpreter for x32.
 Yes it's ideal if we can upstream the code, and as you mentioned, keep
 maintaining it. The buildbot is a good idea while we are still way far
 from it - it requires a mature x32 system which at least supports all of
 the things that a WebKit port depends on. I know there're efforts porting
 Gentoo and Fedora to x32 - we may depend on each other.

 Currently I'm testing the JSC shell only. Though I use the EFL port, I
 eliminated most of the unnecessary dependencies on EFL libraries to run
 the JSC shell, so that I don't need to put efforts on compiling and
 enabling those dependencies for x32 at current stage.

 Thanks, -Yuqiang

 -Original Message-
 From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com]
 Sent: 2012年10月11日 5:51
 To: Xian, Yuqiang
 Cc: webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] x32 support of JavaScriptCore

 Hi,

 I don't think another branch on webkit.org will help you much; then
 you can as well have a branch anywhere.

 If you want this code to be well tested and maintained, you need to
 get it upstream (through all the review process) and promise that you
 have resources to keep maintaining it. It will also be an advantage if
 we can get a buildbot running this exact configuration, so that others
 can make sure they don't break your code.

 I think that whether the community will accept it upstream depends
 much about your commitment and the quality of the code, as well as how
 well you interact with the community during the reviews.

 Which port of WebKit is you currently using for testing?

 Cheers
 Kenneth


 On Wed, Oct 10, 2012 at 5:02 PM, Xian, Yuqiang yuqiang.x...@intel.com
 wrote:
 Hi,



 As you may already know there’s a new x32 ABI – a 32-bit psABI for
 x86-64
 with 32-bit pointer size. It tries to leverage the advantage of more
 registers and IP relative addressing from x64 and the advantage of
 smaller
 memory footprint from IA32. You can find more details of the x32 ABI
 here:
 https://sites.google.com/site/x32abi/.



 The Linux kernel supports x32 since 3.4, and the commonly used
 development
 tools and libraries are getting in the x32 support. Also more details
 about
 current status is available in the above link.



 Now back to WebKit. In theory most part of the WebKit code should be
 fine
 (or require less efforts) to support x32, if they’re pure C++ code and
 can
 be compiled with the x32 toolchain. The major challenge is the JIT
 compiler
 in the JavaScript engine (and the low level interpreter) and some
 hand-written assembly code. So I’m currently working on enabling the
 x32
 support of JavaScriptCore, the WebKit JavaScript engine, to try to
 remove
 the major obstacle. My current status is that I have enabled the
 baseline
 JIT, the DFG JIT and the Yarr JIT on x32 – it passes all the
 JavaScriptCore

Re: [webkit-dev] x32 support of JavaScriptCore

2012-10-11 Thread Kenneth Rohde Christiansen
OK, I see.

If most of your changes are in JavaScriptCore, it might be possible to
just have a build bot that builds that and runs the unit tests for
now, then later get all of WebKit tested.

Kenneth

On Thu, Oct 11, 2012 at 9:13 AM, Xian, Yuqiang yuqiang.x...@intel.com wrote:
 Thanks for the suggestions, Kenneth.

 I'm refining the code and trying to enable the last major component - the low 
 level interpreter for x32.
 Yes it's ideal if we can upstream the code, and as you mentioned, keep 
 maintaining it. The buildbot is a good idea while we are still way far from 
 it - it requires a mature x32 system which at least supports all of the 
 things that a WebKit port depends on. I know there're efforts porting Gentoo 
 and Fedora to x32 - we may depend on each other.

 Currently I'm testing the JSC shell only. Though I use the EFL port, I 
 eliminated most of the unnecessary dependencies on EFL libraries to run the 
 JSC shell, so that I don't need to put efforts on compiling and enabling 
 those dependencies for x32 at current stage.

 Thanks, -Yuqiang

 -Original Message-
 From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com]
 Sent: 2012年10月11日 5:51
 To: Xian, Yuqiang
 Cc: webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] x32 support of JavaScriptCore

 Hi,

 I don't think another branch on webkit.org will help you much; then
 you can as well have a branch anywhere.

 If you want this code to be well tested and maintained, you need to
 get it upstream (through all the review process) and promise that you
 have resources to keep maintaining it. It will also be an advantage if
 we can get a buildbot running this exact configuration, so that others
 can make sure they don't break your code.

 I think that whether the community will accept it upstream depends
 much about your commitment and the quality of the code, as well as how
 well you interact with the community during the reviews.

 Which port of WebKit is you currently using for testing?

 Cheers
 Kenneth


 On Wed, Oct 10, 2012 at 5:02 PM, Xian, Yuqiang yuqiang.x...@intel.com wrote:
 Hi,



 As you may already know there’s a new x32 ABI – a 32-bit psABI for x86-64
 with 32-bit pointer size. It tries to leverage the advantage of more
 registers and IP relative addressing from x64 and the advantage of smaller
 memory footprint from IA32. You can find more details of the x32 ABI here:
 https://sites.google.com/site/x32abi/.



 The Linux kernel supports x32 since 3.4, and the commonly used development
 tools and libraries are getting in the x32 support. Also more details about
 current status is available in the above link.



 Now back to WebKit. In theory most part of the WebKit code should be fine
 (or require less efforts) to support x32, if they’re pure C++ code and can
 be compiled with the x32 toolchain. The major challenge is the JIT compiler
 in the JavaScript engine (and the low level interpreter) and some
 hand-written assembly code. So I’m currently working on enabling the x32
 support of JavaScriptCore, the WebKit JavaScript engine, to try to remove
 the major obstacle. My current status is that I have enabled the baseline
 JIT, the DFG JIT and the Yarr JIT on x32 – it passes all the JavaScriptCore
 tests and the 3 major benchmarks.



 I’m posting this message in order to seek for some advices on how we should
 have our work shared to more people. I understand that it’s not very
 appropriate to try to get it into current WebKit trunk considering current
 x32 support status in major systems and the lack of maintenance in upstream,
 but we want to keep it synchronized with the newest changes of the WebKit
 code. So is it possible for us to maintain the code in a separate branch
 hosted at the WebKit server?



 Any suggestions are appreciated.



 Thanks, -Yuqiang


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev




 --
 Kenneth Rohde Christiansen
 Senior Engineer, WebKit, Qt, EFL
 Phone  +45 4093 0598 / E-mail kenneth at webkit.org

 ﹆﹆﹆



-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

﹆﹆﹆
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] x32 support of JavaScriptCore

2012-10-10 Thread Kenneth Rohde Christiansen
Hi,

I don't think another branch on webkit.org will help you much; then
you can as well have a branch anywhere.

If you want this code to be well tested and maintained, you need to
get it upstream (through all the review process) and promise that you
have resources to keep maintaining it. It will also be an advantage if
we can get a buildbot running this exact configuration, so that others
can make sure they don't break your code.

I think that whether the community will accept it upstream depends
much about your commitment and the quality of the code, as well as how
well you interact with the community during the reviews.

Which port of WebKit is you currently using for testing?

Cheers
Kenneth


On Wed, Oct 10, 2012 at 5:02 PM, Xian, Yuqiang yuqiang.x...@intel.com wrote:
 Hi,



 As you may already know there’s a new x32 ABI – a 32-bit psABI for x86-64
 with 32-bit pointer size. It tries to leverage the advantage of more
 registers and IP relative addressing from x64 and the advantage of smaller
 memory footprint from IA32. You can find more details of the x32 ABI here:
 https://sites.google.com/site/x32abi/.



 The Linux kernel supports x32 since 3.4, and the commonly used development
 tools and libraries are getting in the x32 support. Also more details about
 current status is available in the above link.



 Now back to WebKit. In theory most part of the WebKit code should be fine
 (or require less efforts) to support x32, if they’re pure C++ code and can
 be compiled with the x32 toolchain. The major challenge is the JIT compiler
 in the JavaScript engine (and the low level interpreter) and some
 hand-written assembly code. So I’m currently working on enabling the x32
 support of JavaScriptCore, the WebKit JavaScript engine, to try to remove
 the major obstacle. My current status is that I have enabled the baseline
 JIT, the DFG JIT and the Yarr JIT on x32 – it passes all the JavaScriptCore
 tests and the 3 major benchmarks.



 I’m posting this message in order to seek for some advices on how we should
 have our work shared to more people. I understand that it’s not very
 appropriate to try to get it into current WebKit trunk considering current
 x32 support status in major systems and the lack of maintenance in upstream,
 but we want to keep it synchronized with the newest changes of the WebKit
 code. So is it possible for us to maintain the code in a separate branch
 hosted at the WebKit server?



 Any suggestions are appreciated.



 Thanks, -Yuqiang


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev




-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

﹆﹆﹆
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev