[SqF]Report of VI4 Project for Feb '02

Bijan Parsia bparsia at email.unc.edu
Sun Feb 3 04:24:26 UTC 2002


On Sat, 2 Feb 2002, Tim Rowledge wrote:

> Andreas Raab wrote:
>  
> > > iii) Two-bit oop tags
> 
> > I'm against this modification. Reasons:
> 
> I'm not strongly opined one way or the other myself. On the one hand,
> immediate chars works well for VW, on the other, it does indeed mean
> quite a bit of work.

I'm in favor of further, serious study. I take it that once you let them
in, it's (relatively) easy to experiment with them? I.e., if it turns out
immediate points sorta suck, we're not horrible bound to the first choices
we made? If so, I lean more toward including them.

[snip]
> I agree that there is not yet a compelling reason. That's why it is on
> the list to consider on what might be the last practical opportunity to
> give it due attention.
> 
> Other opinions? HMM, do you to present the case _for_ twobit tags?

I point to an earlier discussion:

	http://www.create.ucsb.edu/squeak/9703.html#Letter11

and quote:

-------------
> > Another idea is to make nil, true, false immediate. This could
> > possibly speed up some operations in the VM since they would deal
> > with constants instead of variables. Probably the speedup isn't
> > worth it, though.
> 
> Hmmm, aren't nil, false, true known to the VM anyhow as hard coded
> pointer values? What would be the benefit of immediate classes here?

They are not hard coded, but depend on the position of the image in
memory. This means that whenever the VM has to use one of these values, it
has to load it from a global variable in which they were stored at image
startup. One place where it hurts is the conditional jump: the object on
top of stack has to be compared with true or false first (depending on the
kind of conditional jump), and if it's not equal, it has to be compared
with the other one, too, to detect the case where a non-boolean is the
receiver of ifTrue:ifFalse:. This makes 2 memory accesses.  Having
well-known immediate values both avoids the memory access and opens up the
possibility for the compiler to use 'quick' instructions that deal with
8-bit or 16-bit immediate operands.
----------

I also point to the page about HHM's 2bit tag stuff:

	http://www.heeg.de/~hmm/squeak/2tagbits/

I point to some VisualWorks stuff:

	http://wiki.cs.uiuc.edu/VisualWorks/Immediate+Selectors

Hmm. How compelling *is* the multibyte Character case? The space savings
isn't great, yes? It seems it would come down to issues about building
character refs in #commonAt: and maybe Character comparisons?

Cheers,
Bijan Parsia.




More information about the Squeak-dev mailing list