We need to distinguish between actual smis and smi-tagged values. You can
have
smi-tagged values with bits set in the 1..31 range, but not smis.
Have functions that convert an aligned pointer to a smi-tagged value *as an
intptr_t*, not a smi.
Then use Move with intptr_t (and RelocInfo::NONE) to store and load it, not
Move
of Smi*.
We need all the bits of a 64-bit value to store the pointer, so we can't
restrict ourselves to the Smi value range.
http://codereview.chromium.org/6119009/diff/1/include/v8.h
File include/v8.h (right):
http://codereview.chromium.org/6119009/diff/1/include/v8.h#newcode3437
include/v8.h:3437: reinterpret_cast<intptr_t>(smi) >> kSmiShiftSize);
I don't think this will work in 64-bit mode (kShiftSize is 31 there, so
you lose a LOT of bits). You need to use all the non-tag bits.
On the other hand, I guess you really meant kSmiTagSize.
We should just have a function (per pointer size) that embeds either an
arbitrary pointer, or just an aligned pointer, in a smi-tagged value
(bit zero is 0).
If the pointer is arbitrary, you need to throw away at least one bit.
Probably the most significant one (but you can't know that that is safe,
e.g., in Windows apps running with 3Gb user space). If it's aligned
(like a stack pointer or similar), we know that the low bit is zero, and
we can cast it directly to Smi and back.
E.g. put functions into SmiConstants<4> and SmiConstants<8> above.
http://codereview.chromium.org/6119009/diff/1/src/api.cc
File src/api.cc (right):
http://codereview.chromium.org/6119009/diff/1/src/api.cc#newcode3271
src/api.cc:3271: const intptr_t mask = (intptr_t(1) << i::kSmiTagSize) -
1;
Just use kSmiTagMask.
http://codereview.chromium.org/6119009/diff/1/src/api.cc#newcode3272
src/api.cc:3272: return ((address & mask) == 0) &&
i::Smi::IsValid(address >> i::kSmiTagSize);
Almost no addresses will be valid in 64-bit mode. Only those in the low
31-bit of the address space will work.
Let's just embed the pointer as a smi-tagged, but non-smi, value, with
bits in the lower half as well.
As long as we only read it again using GetPointerFromInternalField, or
in custom generated code that knows what it's doing, it should be safe.
http://codereview.chromium.org/6119009/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
