Hi, I was wondering why JITArithmetic.cpp uses so many functions from X86Assembler. This should not be happened. MacroAssembler was introduced to be the 'common interface' for every back ends (not only for x86). Am I right? For example: In 'emit_op_rshift' function http://trac.webkit.org/browser/trunk/JavaScriptCore/jit/JITArithmetic.cpp#L1... 121#if USE(ALTERNATE_JSIMMEDIATE) 122 addSlowCase(emitJumpIfNotImmediateNumber(regT0)); 123 __ movq_rr(regT0, X86::xmm0); 124#else 125 emitJumpSlowCaseIfNotJSCell(regT0, op1); 126 addSlowCase(checkStructure(regT0, m_globalData->numberStructure.get())); ******************* 127 __ movsd_mr(FIELD_OFFSET(JSNumberCell, m_value), regT0, X86::xmm0); ******************* 128#endif IMHO, if a platform specific solution have to be used, creates a separate file which will contain those solutions/optimizations. What do you think about this issue? --Gabor
This branch is still in the early prototype stage and should be looked at as being final in any real sense --Oliver On May 14, 2009, at 8:08 AM, Gabor Loki wrote:
Hi,
I was wondering why JITArithmetic.cpp uses so many functions from X86Assembler. This should not be happened. MacroAssembler was introduced to be the 'common interface' for every back ends (not only for x86). Am I right?
For example: In 'emit_op_rshift' function
http://trac.webkit.org/browser/trunk/JavaScriptCore/jit/JITArithmetic.cpp#L1...
121#if USE(ALTERNATE_JSIMMEDIATE) 122 addSlowCase(emitJumpIfNotImmediateNumber(regT0)); 123 __ movq_rr(regT0, X86::xmm0); 124#else 125 emitJumpSlowCaseIfNotJSCell(regT0, op1); 126 addSlowCase(checkStructure(regT0, m_globalData-
numberStructure.get()));
127 __ movsd_mr(FIELD_OFFSET(JSNumberCell, m_value), regT0, X86::xmm0); ******************* 128#endif
IMHO, if a platform specific solution have to be used, creates a separate file which will contain those solutions/optimizations.
What do you think about this issue?
--Gabor
_______________________________________________ squirrelfish-dev mailing list squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
On 2009-05-14, at 12:35, Oliver Hunt wrote:
This branch is still in the early prototype stage and should be looked at as being final in any real sense
What do you mean by "this branch"? Gabor linked to code that is on trunk, and has been for some time. - Mark
On May 14, 2009, at 8:08 AM, Gabor Loki wrote:
Hi,
I was wondering why JITArithmetic.cpp uses so many functions from X86Assembler. This should not be happened. MacroAssembler was introduced to be the 'common interface' for every back ends (not only for x86). Am I right?
For example: In 'emit_op_rshift' function
http://trac.webkit.org/browser/trunk/JavaScriptCore/jit/JITArithmetic.cpp#L1...
121#if USE(ALTERNATE_JSIMMEDIATE) 122 addSlowCase(emitJumpIfNotImmediateNumber(regT0)); 123 __ movq_rr(regT0, X86::xmm0); 124#else 125 emitJumpSlowCaseIfNotJSCell(regT0, op1); 126 addSlowCase(checkStructure(regT0, m_globalData-
numberStructure.get()));
127 __ movsd_mr(FIELD_OFFSET(JSNumberCell, m_value), regT0, X86::xmm0); ******************* 128#endif
IMHO, if a platform specific solution have to be used, creates a separate file which will contain those solutions/optimizations.
What do you think about this issue?
--Gabor
_______________________________________________ squirrelfish-dev mailing list squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
_______________________________________________ squirrelfish-dev mailing list squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
Hi Gabor, In short, yes, definitely, these should be going through the MacroAssembler – this code predates the introduction of the MacroAssembler interface, and hasn't been brought up to date. It largely hasn't been touched since there hasn't been a need to do so yet (and I find layers of abstraction tend to be developed best where there is actually something to usefully abstract :-) ). I would imaging that interface for floating-point math would be very similar to the integer math API, something like: void add32(RegisterID src, RegisterID dest) void load32(ImplicitAddress address, RegisterID dest) void store32(ImplicitAddress address, RegisterID dest) void addDouble(FPRegisterID src, FPRegisterID dest) void loadDouble(ImplicitAddress address, FPRegisterID dest) void storeDouble(ImplicitAddress address, FPRegisterID dest) We may need put a little thought into how this will extend to cover vector operations (on x86 these operate on the same register set as floating-point, this may not be true for all platforms). As I think you may well be aware, there is currently a lot of work on our number representation going on in the nitro-extreme branch of svn; I know there has been discussion of abstracting FP through the MacroAssembler before that lands. cheers, G. On May 14, 2009, at 8:08 AM, Gabor Loki wrote:
Hi,
I was wondering why JITArithmetic.cpp uses so many functions from X86Assembler. This should not be happened. MacroAssembler was introduced to be the 'common interface' for every back ends (not only for x86). Am I right?
For example: In 'emit_op_rshift' function
http://trac.webkit.org/browser/trunk/JavaScriptCore/jit/JITArithmetic.cpp#L1...
121#if USE(ALTERNATE_JSIMMEDIATE) 122 addSlowCase(emitJumpIfNotImmediateNumber(regT0)); 123 __ movq_rr(regT0, X86::xmm0); 124#else 125 emitJumpSlowCaseIfNotJSCell(regT0, op1); 126 addSlowCase(checkStructure(regT0, m_globalData-
numberStructure.get()));
127 __ movsd_mr(FIELD_OFFSET(JSNumberCell, m_value), regT0, X86::xmm0); ******************* 128#endif
IMHO, if a platform specific solution have to be used, creates a separate file which will contain those solutions/optimizations.
What do you think about this issue?
--Gabor
_______________________________________________ squirrelfish-dev mailing list squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
On May 14, 2009, at 2:41 PM, Gavin Barraclough wrote:
void add32(RegisterID src, RegisterID dest) void load32(ImplicitAddress address, RegisterID dest) void store32(RegisterID src, ImplicitAddress address)
void addDouble(FPRegisterID src, FPRegisterID dest) void loadDouble(ImplicitAddress address, FPRegisterID dest) void storeDouble(FPRegisterID src, ImplicitAddress address)
Bah, those stores weren't very storey. I clearly meant something more like this ^^. G.
Hi, Well, since I've heard no dissenting voices I decided it was probably best to just get this done and have landed an implementation. https://bugs.webkit.org/show_bug.cgi?id=25827 cheers, G. On May 14, 2009, at 2:52 PM, Gavin Barraclough wrote:
On May 14, 2009, at 2:41 PM, Gavin Barraclough wrote:
void add32(RegisterID src, RegisterID dest) void load32(ImplicitAddress address, RegisterID dest) void store32(RegisterID src, ImplicitAddress address)
void addDouble(FPRegisterID src, FPRegisterID dest) void loadDouble(ImplicitAddress address, FPRegisterID dest) void storeDouble(FPRegisterID src, ImplicitAddress address)
Bah, those stores weren't very storey. I clearly meant something more like this ^^. G.
_______________________________________________ squirrelfish-dev mailing list squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
Gavin Barraclough wrote:
Hi,
Well, since I've heard no dissenting voices I decided it was probably best to just get this done and have landed an implementation.
This looks nice. Thanks, Gavin! Now, 'JIT::privateCompilePutByIdTransition' from JITPropertyAccess.cpp is the only function which calls X86Assembler directly. May I ask a same kind of refactoring there? ;-) --Gabor
On May 16, 2009, at 7:09 AM, Gabor Loki wrote:
Gavin Barraclough wrote:
Hi,
Well, since I've heard no dissenting voices I decided it was probably best to just get this done and have landed an implementation.
This looks nice. Thanks, Gavin!
Now, 'JIT::privateCompilePutByIdTransition' from JITPropertyAccess.cpp is the only function which calls X86Assembler directly.
May I ask a same kind of refactoring there? ;-)
FYI this has just been refactored. G.
participants (4)
-
Gabor Loki
-
Gavin Barraclough
-
Mark Rowe
-
Oliver Hunt