Re: [Squeak-VMdev] Versiojn 4 changes

[Tim R. <ti...@su...>]

In message <003101c41c1e$345e2c00$b2d0fea9@R22>
          "Andreas Raab" <and...@gm...> wrote:

> Hi Dan,
> 
[sni]
> > or two each.  Any problems with Tim's suggestion to drop the
> > limit to 511?
> 
> Fine with me.
[snip]
The ones we'd lose are the top 8 quick instvar pushing options. Hard to
iamge that will cost anything beyond a trivial Compiler patch

> > Immediate objects (tagging)
[snip]
> A very clear "NO" to the idea of taking away a bit from SmallInteger. 30bit
> floats are almost useless
I agree.
> 
> 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)
Sounds plausible to me. There is some definite image level impact to
chaging things to be immediates; for example no more Point>x: usage.
> 
> The only problem with using the 10 tag is that the garbage collector
> currently uses that - but I believe this is fixable. In any case, there is a
> clear objection from my end against taking away a bit from SmallIntegers.
> 
> > Form bits modulus
> > I want to change the modulus of Form bitmaps to 64 bits
> > in both 32- and 64-bit images.  It will simplify things
> > for them to be the same, and I think we can convert old ones
> > on the fly for compatibility (ie, when reading in a project,
> > or an old '.form' file.  Do you see any problems with this?
> 
> A key question is whether the "bits" of a 64bit form would store 32bit
> quantities or 64bit. If the latter I'd say this is going to get problematic.
> If the first, e.g., we merely extend the form bits to make sure we have
> always 64bit aligned pixel rows, that should fine.
The equivalent approach worked fine in BrouHaHa for hainge 32bit words
supporting 16bit Form granularity.
> 
> > CompiledMethods
[snip]
> 
> I don't have a good understanding about the tradeoffs involved (Ian should
> comment on this) so I'll just throw in a general thought: I think that if we
> can (e.g., not being overly wasteful in terms of space) we should leave some
> "unused" slot. Much of the experimentation we saw in the past was only
> possible because such "unused" places existed (say, MethodContext's
> receiverMap).
For the cleaned up CM format adding extra instvars is no problem at all
since it's just a normal object. Ian once strongly advocated having the
bytecodes and literals as separate arrays, whereas my initial
implementation had the literals as indexable vars following the header,
bytecode oop, etc. The VM cost is one more pointer to chase
balanced against the flexibility provided.

tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
For every action, there is an equal and opposite criticism.