[Webkit-unassigned] [Bug 99154] New: Refactor MacroAssembler interfaces to differentiate the pointer operands from the 64-bit integer operands

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Oct 12 02:26:13 PDT 2012


https://bugs.webkit.org/show_bug.cgi?id=99154

           Summary: Refactor MacroAssembler interfaces to differentiate
                    the pointer operands from the 64-bit integer operands
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: yuqiang.xian at intel.com
                CC: barraclough at apple.com, fpizlo at apple.com
            Blocks: 99153


In current JavaScriptCore implementation for JSVALUE64 platform (i.e., the X64 platform), we assume 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 interfaces for both JSValue and pointer operands. We need 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. This would help us supporting other JSVALUE64 platforms where pointer size is not necessarily 64-bits, for example x32 (bug #99153).

The major modification I made is to introduce the "*64" interfaces in the MacroAssembler for those operations on JSValues, keep the "*Ptr" interfaces for those operations on real pointers, and go through all the JIT compiler code to correct the usage.

Patch forthcoming.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list