Hans-Martin,

> > * Decreased SmallInteger range.
>
> It would be a decrease from 31-bit SmallInts to 30-bit 
> SmallInts. I'd like to know whether the difference makes
> a difference in practice.

I've been running into various cases where it really does matter (such
as doing operations on 32bit RGBA values) but considering Tim's proposal
about only one additional immediate this problem appears to be solvable.

> > The space reduction due to the use of short points
> > appears to be too small to be of practical importance.
> 
> Space-wise, you might be right. But I do think that 2D 
> graphics operations as they happen a lot in morphic might
> benefit performance-wise.

That I would like to see first. According to my measures we're spending
most of the time in a moderately complex morphic world with drawing
primitives (in particular text).

BTW, here's one _for_ immediate short points: The place where I could
see them most useful is for vector graphics. In other words, for stuff
like flash graphics etc. they would be highly useful considering the
amounts of points we're dealing with.

> An application of Immediate classes for performance might be 
> to make nil, true and false immediate. This doesn't gain any space,
> but all operations now checking against the value of nilOop etc. could
> check against small constants.

Again, I'd like to see some evidence first.

> > * Increased complexity in VM.
>
> Nope. The changes to the VM are pretty moderate. I don't know 
> why you think that GC and method lookups would even be affected.
> The arithmetic bytecodes would include support for immediate points,
> and String accessing methods would create immediate characters,
> but that's about it.
> The critical checks for immediateness and SmallIntegerness 
> are not affected at all.

The complexity increases at least to the point that we'd need to have
methods like #isImmediate (returning true if oop is an immediate),
#isInteger, #isCharacter, and #isShortPoint. Which means that, for
instance, #fetchClassOf: will be affected (and therefore indirectly
message lookup) and most likely various other places as well. I'm not
saying that its hard to do but to me, all these additional checks do
sound like an increase in complexity.

> > * Change of primitive interface.
> Can't comment on that. You're right that plugins will be 
> incompatible and would have to be recompiled at least. I don't
> know whether there really is a need to rewrite.

This one I'm kinda worried about because it's so simple to overlook that
some primitive might return a 31bit integer under some weird
circumstances.

Cheers,
  - Andreas