Igor Stasenko wrote:

> Btw, about GC:
> 
> http://lambda-the-ultimate.org/node/2391
> 
> Garbage Collection without Paging, Matthew Hertz, Yi Feng, Emery D.
> Berger. PLDI 2005

The old Mushroom papers are also worth a look:

http://www.wolczko.com/mushroom/index.html

About the original thread, I liked the idea Andreas had proposed of a 6
bit class index for immediate values. It fits in well with the existing
compact classes and is easy to optimize in software. Having worked with
Self and Logo where characters are strings of length 1, I can say that I
like that scheme very much and will use it in any language I design but
don't think it is worth changing Squeak to be like this.

I didn't understand Eliot's comment in his first post:

> The problem 30 bit floats have is that they're not a useful subset
> of Float.  A 60-bit immediate float is a different beast altogether.
> You really need the number of bits to be sihnificanty greater than
> the size of the mantissa.  With 30 bits it is still 23 bits short.

It doesn't seem that 32 bits is that much better, but it is what we have
with FloatArrays.

Let me explain my motivation for starting this discussion - when people
hear that I am designing a hardware implementation of the SqueakVM, the
most frequent question I get is about what kind of FPU (floating point
unit) the device will have. My reply is that with boxed floats we have
so much overhead (no, I don't have actual numbers...) that I prefer to
include as little hardware support as possible. Just to give you an
example - if you select to have a FPU in the open source Leon 3
processor (32 bit Sparc), that will take up three times the area of the
Leon itself. With unboxed floats, I would be more interested in having
better hardware for them. But I don't want this hardware to be
incompatible with the software VMs and don't want to fork over this
issue.

-- Jecel