Hi,
apologies for the cross-post to two lists, but I wasn't too sure where to ask this. I've just been browsing the VM sources for details on the encoding of class formats used in object instantiation. Apparently, it seems as if the class format word that can be retrieved by sending #format to a class has the same layout as the standard header word of all objects. The only difference seems to be that the format word is shifted left by 1. Can anyone confirm this? Or am I wrong? Thanks, Michael |
> Can anyone confirm this? Or am I wrong?
That is exactly correct. It's a little implementation trick so that the format doesn't have to be "normalized" for allocation. It originates from the days when even a shift was too slow in allocation; personally I find it a little awkward. Cheers, - Andreas Michael Haupt wrote: > Hi, > > apologies for the cross-post to two lists, but I wasn't too sure where > to ask this. > > I've just been browsing the VM sources for details on the encoding of > class formats used in object instantiation. > > Apparently, it seems as if the class format word that can be retrieved > by sending #format to a class has the same layout as the standard > header word of all objects. The only difference seems to be that the > format word is shifted left by 1. > > Can anyone confirm this? Or am I wrong? > > Thanks, > > Michael > > |
Hi Andreas,
On 5/16/06, Andreas Raab <[hidden email]> wrote: > > Can anyone confirm this? Or am I wrong? > > That is exactly correct. It's a little implementation trick so that the > format doesn't have to be "normalized" for allocation. It originates > from the days when even a shift was too slow in allocation; personally I > find it a little awkward. thanks for your answer. Would a reimplementation in a different way significantly speed things up, or is that just aesthetically unsatisfying? (I suspect shifts are faster now.) Best, Michael |
Michael Haupt wrote:
>> That is exactly correct. It's a little implementation trick so that the >> format doesn't have to be "normalized" for allocation. It originates >> from the days when even a shift was too slow in allocation; personally I >> find it a little awkward. > > Would a reimplementation in a different way significantly speed things > up, or is that just aesthetically unsatisfying? (I suspect shifts are > faster now.) You won't know until you measure it ;-) But I wouldn't think there is any difference whatsoever; it's really just unpleasing to get one number in the image and another one in the VM (because if you do VM stuff then then you need to look at these at times). Cheers, - Andreas |
>Michael Haupt wrote:
>>>That is exactly correct. It's a little implementation trick so that the >>>format doesn't have to be "normalized" for allocation. It originates >>>from the days when even a shift was too slow in allocation; personally I >>>find it a little awkward. >> >>Would a reimplementation in a different way significantly speed things >>up, or is that just aesthetically unsatisfying? (I suspect shifts are >>faster now.) > >You won't know until you measure it ;-) But I wouldn't think there is any difference whatsoever; it's really just unpleasing to get one number in the image and another one in the VM (because if you do VM stuff then then you need to look at these at times). I made it this way, and I have to agree with Andreas's criticism -- even I get confused by it! But in answer to the question about speedups, the *thought* I had about this was that at some point the whole format word could just be blatted into a new instance, thus saving some time. At least this is where my head was when I started. Now when you back off a bit, it's clear that the better way to achieve this is to copy a prototype, thus initializing *all* the state in a single move. Squeak's #clone primitive was added to provide exactly that kind of speedup, and thus to give a little help to anyone wanting to build a prototype-oriented kernel (we talked about this a lot back in the early days, and Tweak is a more recent example with a fully-developed user architecture). - Dan |
Free forum by Nabble | Edit this page |