Thanks to everyone who is contributing to this thread! I should have
been more explicit about my interest in this area: a good floating point
unit is about the same size as a reasonably compact integer core. So for
the same cost I can have twice as many processors if I am willing to
have slow floating point. The worst case would be to have both half as
many processors (with a FPU each) *and* slow floating point anyway due
to Squeak's limitations.

Squeak does have a scheme for good floating point performance: the
FloatArray. In a previous discussion about this with Bryce, he felt that
between this and being about to compile away boxing/unboxing operations
within a single method (also mentioned by Hans-Martin in this thread) we
could have essentially the same performance as immediate floats (and
Hans-Martin pointed out that the bit pattern I suggested is already in
use anyway).

Nicolas evaluated the advantages of the "64 bit everything is a float"
scheme, which I unfortunately don't remember who was the inventor. One
trick that some old mainframes used was to represent integers as
denormalized floating point numbers, so you would need no checks nor
conversions. The IEEE 754 standard doesn't seem to support this,
however.

As Bert pointed out, lack of floating point hardware was the reason
given for not choosing the ARM for the first OLPC machine. Ivan
mentioned fixed point as an alternative, and this is actually what I
have used in my projects (specially the Forth based ones) for most of
the past ten years. But for Squeak I would rather just give people what
they are used to (not counting Fractions, LargeIntegers and such, of
course). Juan gave a list of application domains where floats are
considered fundamental.

Hans-Martin and Claus asked about the availability of 64 bit hardware
for the scheme I mentioned. That is indeed a problem (only my old Sparc
machine would be able to run a 64 bit Squeak of the 14 or so computers I
have around here, for example) but it could be solved by doing some
conversions when saving/loading images. We need to do transformations
when moving between 32 and 64 images anyway and unboxing floats would be
one of the simplest.

-- Jecel