[webkit-dev] x32 support of JavaScriptCore

Fri Oct 12 03:13:07 PDT 2012

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:barraclough at 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:zherczeg at webkit.org] 
> Sent: 2012年10月11日 15:43
> To: Xian, Yuqiang
> Cc: Kenneth Rohde Christiansen; webkit-dev at 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.christiansen at gmail.com]
>> Sent: 2012年10月11日 5:51
>> To: Xian, Yuqiang
>> Cc: webkit-dev at 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.xian at 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 at 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 at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev