> "Juan Vuletich" <jmvsqueak at uolsinectis.com.ar> wrote
> [that with 64-bit Squeak, it would be good to have several
> immediate types, including]
>
> - Another very useful one would be Float (with a range of 61 bits, and
> primitives working with 64 bit floats. The mantissa should be completed
with
> 3 zeroes on primitive entry, and have the last 3 bits truncated on
primitive
> exit.) I believe this one would alse be useful in VI 4 32-bit image. I
> believe 32 bits pointers should be aligned by 32 bits, needing 30 bits,
and
> leaving space for 2 extra inmediate objects. Floats should be one.
> Primitives would work with 32 bits floats, and the mantissa should lose 2
> bits (instead of 3).
>
> Early versions of Quintus Prolog handled floats this way, stealing a few
bits
> out of the bottom of a word.  Bad idea.  ***BAD*** idea!   REALLY
incredibly
> bad idea.  It means, for example, that calculations done in Smalltalk and
> the same calculations done in C would not agree; for non-trivial
calculations
> the results might not even be close (probably wouldn't be).  Possibly the
> only aspect of QP that anyone despised.  We thought it would be OK for
> graphics.  We were wrong, WRONG, *WRONG*.  Don't even think of doing this
> unless you can hire Kahan or one of his students to get the details 100%
right.

Then, we could store an inmediate standard 32 bit float there. It would work
exactly as today's Floats.

> - ShortSymbol.  We could have some short symbols coded in the
> object pointer.  This would allow to shrink the symbol
> dictionary, saving memory and making symbol creation faster.
> Anyway, the only performance improvements would be on symbol
> creation, mostly when compiling methods, but it could be useful
> anyway.  ShortSymbols would only be allowed to be made of:
> A..Z, a..z, 0..9, and :. They would use only 6 bits per
> character, and they can be up to 10 characters long.  Many
> selectors could be ShortSymbols.
>
> In effect, WAM-based Prolog systems do this.  They represent *all* atoms
> as (index into atom table|TAG).  This pays off because the vast majority
> of operations on Prolog atoms are just equality tests or hash code
> determination, both of which work better on the index than on a pointer.
> However, that's not how Smalltalk works.  For Smalltalk, the increased
> cost of message sends really isn't justifiable.

Do you see an increased cost on every message send or just those sent to
symbols?
In the first case, please explain it. In the second case, perhaps the shrink
of the symbol
table justifies that cost.

> - Character. I always found strange that a character would use more memory
> space than a SmallInteger.
>
> *References* to characters are already the same size as a SmallInteger.

Yes, I agree. Characters are OK as they are.

> Perhaps a good inmediate character representation
> could make multi-lingual and multi-alphabet strings easier. I guess
Yoshiki
> could think if this is a good idea. Perhaps in 61 bits we could also have
> space for coding some format information: bold, italic, outline, font,
size,
> color, etc.
>
> Please, let's not go there.  Lisp Machine Lisp had "font" and "bits"
> attributes on characters; those were in CLtL1, but they were dropped
> completely from CLtL2 and the ANSI Common Lisp standard.  The idea of
> requiring 64 bits per character in strings (so that you can hold on to
those
> properties) doesn't appeal, and nor does a CLtL1-style distinction
> between "characters" and "string characters".  It's bad enough needing
> 21 bits for Unicode characters...  I _don't_ want to have to wonder
> whether an italic $i is equal to a slanted $i.  I particularly don't
> want to have to worry about moving a #\Paladino-12-slanted-X character
> to an image that doesn't have a Paladino font available.
>
> In short, DTSTTCPW.
>
I agree.