Andreas Raab wrote:

> Tim,
>
> > iii) Two-bit oop tags
> > Hans Martin has suggested moving to two tag bits on OOPS in order to
> > allow more immediate classes. Currently the only really serious
> > candidate class is Character, but it does have advantages relating to
> > unicode and internationalisation. Other possibilities include short
> > floats, immediate small points and err.... well.
>
> I'm against this modification. Reasons:
>
> * Decreased SmallInteger range. In many media-type applications (sound,
> graphics) SmallIntegers are in 32 bit range. In such algorithms we often
> carefully optimize for integer computations to stay in SmallInteger
> range in order to be efficient. Falling back to LargeInts decreases
> efficiency by roughly two orders of magnitude. Decreasing SmallInteger
> range means that these computations get even less efficient and harder
> to make efficient.

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. If you've
already coded carefully to avoid the 32-bit range, you've quite likely
avoided the 31-bit range as well. But I did not analyze it much.

> * Other classes are not "worthy" of being immediate. Unicode characters
> can be created by the equivalent means of the current Character
> implementation, e.g., by providing a character table (which could even
> be segmented in order to save space and augmented with addl. primitives
> for fast creation).

You're probably right here, I did not measure effects.

> Immediate floats are useless for all numerical
> operations anyways (since the accuracy is to low) and for large scale
> floating point manipulation the set of operations in float arrays can be
> used which (at that scale) will be even more efficent than any immediate
> float representation.

Immediate floats are nonsense, you're right. I just mentioned them when Tim
pressed me for examples :-)

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

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.

> * Increased complexity in VM. In order to become efficient, any new
> immediate class would require wide-ranging modification in the areas of
> bytecodes, primitives, method lookups and garbage collection. An
> additional immediate will require new and possibly more complicated
> tests to be performed in various time-critical areas and may even
> decrease overall performance.

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.

> * Change of primitive interface. A modification of the tag bits will
> require to review and possibly rewrite all plugins many of which rely on
> the fact that various functions (like pushInteger:
> storeInteger:ofObject:withValue:) use 31 bit integers. All of them may
> break in unexpected ways when an additional tag bit is added. In
> addition, all plugins using the new immediate need to be rewritten in
> order to access it correctly.

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.

Cheers,
Hans-Martin