Re: [Squeak-VMdev] Versiojn 4 changes

[Yoshiki O. <Yos...@ac...>]

  Dan and Andreas,

> > Compact classes
> > I put these in way back, and they do save almost a word per
> > object in small kernel images.  They complicate things a bit,
> > but the code is already written, and it has been stable for
> > nearly a decade now.
> >
> > On the other hand, the complexity is an inhibition to trying
> > out various other cool hacks.  Moreover if we dropped the compact
> > class feature, we could pick up 5 more bits of object hash, which
> > would definitely be nice.  With regard to compactness, my experience
> > is that the savings due to this feature is less than the difference
> > between a well-designed kernel and a poor one, so I don't consider
> > it a bit issue.  Even PDA's have plenty of space these days (yes,
> > there's an upside to the Microsoft world ;-), and for extreme
> > compactness issues (like web downloads), there are all sorts of
> > other compactness strategies.
> >
> > I'm inclined to drop them and give the bits back to the hash,
> > but it's only a mild inclination.  How do you guys feel?
> 
> No strong opinions here. If we agree that the savings in size aren't worth
> it, we should go with whatever is best for speed (both, current and future
> such as a JIT - it might have a benefit to "tag classes" via their cc
> index).

  I agree this.  1.5MB image with compact classes and 2MB image
without compact classes (a made up example) are pretty much in the
same ballpark.

> > Immediate objects (tagging)
> > We *could* do lots of things here -- enough so I start to get
> > worried about doing too much.  For instance, we could have
> > immediate Floats of, say, 30 bits, and immediate Characters
> > of 30 bits, in addition to our current immediate SmallIntegers.
> >
> > I'm inclined not to do any of these, but how do you feel?
> 
> A very clear "NO" to the idea of taking away a bit from SmallInteger. 30bit
> floats are almost useless - if I had understood the trouble I'm getting into
> when I first encountered them in VW I would've never used them ;-) Even
> 32bit floats are almost always useless except in very limited situations
> (say 3D stuff where accuracy really doesn't count all that much).

  Yes. 30bit or (62 bit) float save us too much.

> Here is an alternative that I considered a while ago: Instead of using
> "another tag" bit we could declare a tag pattern which looks like:
> 
> 00 - OOP
> 10 - Immediate
> x1 - SmallInteger
> 
> With "Immediate" being described by 6 further bits which specify the index
> into the "immediate classes array" (precisely the same as compact classes).
> This would leave 24 bits which I could (out of my mind) think of 4
> situations in which they would be useful:
> * Colors (8 bits each)
> * Immediate Points (signed 12 bits x/y)
> * Wide characters (Unicode is defined as 21 bit; but Yoshiki really needs
> 24)
> * Scaled decimals (16.8 or 12.12)

  I'd like to have 30 bit for a char.

  I think once Tim suggested this, but how about using "01" for OOP
and "00" for SmallInteger?  Some processor's addressing mode let us
access the word-aligned memory with such pointer, while "no-tag" for
SmallInteger may save some bit-operations.

  (Well, I'd admit that the saving we can do here is small compared to
keeping the compatibility with 32-bit image format.  So, I don't push
this idea too much.)

-- Yoshiki