We could implement that in the following way:
intTag : -1 : 0xffffffff
boolTag : - 2 : 0xfffffffe
isInt : tag >= -2
isStrictInt : tag >= -1
isBothInt : (tag1 & tag2) >= -2
isBothStrictInt : (tag1 & tag2) >= -1
(can be signed or unsigned comparison)
Regards,
Zoltan
> 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
>>> [email protected]
>>> http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
>>
>>
>
>
> _______________________________________________
> squirrelfish-dev mailing list
> [email protected]
> http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
>
_______________________________________________
squirrelfish-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
