class formats

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

class formats

Michael Haupt-3
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

Reply | Threaded
Open this post in threaded view
|

Re: class formats

Andreas.Raab
 > 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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: class formats

Michael Haupt-3
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

Reply | Threaded
Open this post in threaded view
|

Re: class formats

Andreas.Raab
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

Reply | Threaded
Open this post in threaded view
|

Re: class formats

Dan Ingalls
>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