Probably no, but we could simplify such opcodes: void JIT::emit_op_jtrue(Instruction* currentInstruction) { unsigned target = currentInstruction[2].u.operand; emitGetVirtualRegister(currentInstruction[1].u.operand, regT0); Jump isZero = branchPtr(Equal, regT0, ImmPtr(JSValue::encode(jsNumber(0)))); addJump(emitJumpIfImmediateInteger(regT0), target); addJump(branchPtr(Equal, regT0, ImmPtr(JSValue::encode(jsBoolean(true)))), target); addSlowCase(branchPtr(NotEqual, regT0, ImmPtr(JSValue::encode(jsBoolean(false))))); isZero.link(this); RECORD_JUMP_TARGET(target); } The second two checks would be unnecessary, and probably we could squeeze out a little performance gain here. Zoltan PS: I didn't say this is much better, instead, I would be interested in your opinion whether you think this would be a good idea or not.
Is there a place where testing for booleans is currently expensive?
Geoff
On Mar 4, 2011, at 5:37 AM, Zoltan Herczeg wrote:
Hi,
I found something interesting in the v8 source code. They store the true and false as integers: 1 and 0. Actually it was a surprise to me, but "true + 1" is "2" in JavaScript, so this kind of object handling seems ok.
Advantage of their approach: they don't need to care about boolean values for all arithmetic and conditional operations in JIT. This could reduce the source code (maintainability), and probably faster, since you don't need to check boolean values.
Disadvantage: type resolving is a bit more difficult, but since that is a rare operation, I think the gain could be bigger.
What is your opinion about it? Would it be possible to implement something like this for JSValue32_64? Would it worth it?
Regards, Zoltan
_______________________________________________ squirrelfish-dev mailing list squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev