On Sun, Mar 15, 2009 at 2:35 PM, Jecel Assumpcao Jr <jecel at merlintec.com>wrote:

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


...and SPARC is one of the worst 64-bit implementations out there.
 Question, how much bigger is a 64-bit literal load instruction vs a 32-bit
literal load in x86/x86-64 and SPARC32/SPARC64?


>
> -- Jecel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090316/823c3490/attachment.htm