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.

* 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). 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. The space reduction due to the use of short points
appears to be too small to be of practical importance.

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

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

In short, I vote against this proposal because I have yet to see a
compelling reason for the advantage of whatever the new immediate class
would be compared to the combination of added complexity and possible
negative side effects, in particular those related to VM and plugin
interface modifications.

Cheers,
  - Andreas