News for hackers. Stuff that matters.
Re:Mozilla’s new (internal) JavaScript value representation by yason on Tuesday August 03, 2010 @04:24AM (#1570497)
How is this new but merely evolutional?

You know, as soon as you're willing pass 64-bit values around, packing different values into a long long isn't really packing anymore. There are so many bits that you can easily "waste" a few of them for tags. The downside is that you most often really just need only a handful of bits and it looks like Jaegermonkey lavishly uses 32 bits for tagging of 32-bit pointers.

Of course, thinking optimistically, the new approach is better if you can at least carry some satellite information in the 32 tag bits, like object origination/permission/context data, or some length/offsets for (sub)strings. Also, locality is probably better, heap allocation is eliminated, and for 64-bit registers and moves this is a natural fit.

But I would have liked to see those 61-bit integers for the same amount of money.

Re:Mozilla’s new (internal) JavaScript value representation by andhow on Tuesday August 03, 2010 @03:27PM (#1572400)
Of course this is not new. I would have to assume that every value representation under the sun has already been invented and probably during the 60s.

61-bit integers would either require long long integer arithmetic on x86 or require more dynamic branching for arithmetic ops either of which would slow down very hot paths.