According to the author, the old way was to store all JS vars in 32bit C variables, so a small int was able to be stored inline, but floats, objects and strings were stores as pointers.
The author says that the last four bits stored the type info for the variable. But, since memory addresses are 8 hex characters long, a bitmask was used to convert the last four bits into another hex character, thus establishing the full pointer address.
How does this work? I mean, you only have the four bits, if the info is not right there in front of my face in those four bits, how can a mask tease out the hex character?
I couldn't figure that out either, so I asked a friend who actually worked on this code and I came away feeling just a tad dirty but smarter. :)
The last three bits of the real address are always 000.
If you ask C's malloc for enough space to store a JS string, object, or float, the address that it gives you will be aligned on a 32-bit boundary, so the last three bits of the address will be 0. SpiderMonkey has it's own allocator, mostly because they do GC, but this allocator also guarantees that any address allocated for one of these types is aligned.
Because of this, the last three bits can always be used to store the type tag and then masked away to restore the proper 000 bits.
I'm not sure I'm understanding you right; a hex character is four bits. To tease a hex character out of a 32 bit int, you'd apply a max of 0000000F, where F is the last four bits.
In the example, if the last four bits are 1100, it's a string. The first seven four-bit quadruplets, plus a bitmask'd version of the last quadruplet (1100) comprised eight sets for four bits. My questions is: how can four bits, if they don't already encode the hex character I'm looking for, be bitmask'd into displaying it, and still be capable of encoding any of the 16 possible hex characters?
Where do you see 4 bits? I only see him mention 3 bits:
The old jsval representation fit in a 32 bit value, using the 3 lowest bits as a way to tag the value as a particular type. These were called type tags.
In the examples given, the lowest three bits are masked to 0s when determining the address. That's a loss of precision, meaning there's no way to represent a pointer to an address that's not modulo 8 == 0. Another way of saying this is that objects must be aligned to 8 byte boundaries.
Isn't this a waste of space? Probably not. My guess is very few objects are less than 8 bytes in length, so that space is not really wasted. Even if objects ARE shorter, this is a dynamically typed language, we probably want to keep spare memory anyway, to reduce the chance that adding values to an object will require costly memory allocation.
If the last 3 bits are 100 then the value is a pointer to a string. You mask off those 3 bits and you get the address of the string -- you just have to ensure your strings are aligned to 8 byte boundaries.
Wow, that's a whole lot of pretty major changes just for this beta. It's great that the Add-Ons manager is in a tab now rather than a window. Hopefully the Downloads window gets the same treatment.
Also: The "tabs on top" on OS X could use some touching-up - right now the tab bar is just swapped with the toolbar, and still below the window's title area. Something more like Chrome (or that Safari beta, for that matter) would be nice.
Really? I find it's much better on Linux than on Mac (where most of the time it doesn't behave the way a Mac app should). I have no problem using it on Linux or Windows though, it works great there, the way the rest of the OS works.
I suppose this makes me that guy that shows up in every Firefox thread complaining that it's a shitty Mac app.
That, and a dev version of Tab Mix Plus, because the only truly cannot-use-if-feature-doesn't-exist for me is address bar, search bar, history, and bookmarks all opening in new tabs by default. It's the only thing I require.
Search bar is supported in about:config, but the others aren't.
So far, the beta looks good to me. But I'm dying without the rest of my extensions.
According to the author, the old way was to store all JS vars in 32bit C variables, so a small int was able to be stored inline, but floats, objects and strings were stores as pointers.
The author says that the last four bits stored the type info for the variable. But, since memory addresses are 8 hex characters long, a bitmask was used to convert the last four bits into another hex character, thus establishing the full pointer address.
How does this work? I mean, you only have the four bits, if the info is not right there in front of my face in those four bits, how can a mask tease out the hex character?