<br><br><div class="gmail_quote">On Sun, Mar 15, 2009 at 2:35 PM, Jecel Assumpcao Jr <span dir="ltr"><<a href="mailto:jecel@merlintec.com">jecel@merlintec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Thanks to everyone who is contributing to this thread! I should have<br>
been more explicit about my interest in this area: a good floating point<br>
unit is about the same size as a reasonably compact integer core. So for<br>
the same cost I can have twice as many processors if I am willing to<br>
have slow floating point. The worst case would be to have both half as<br>
many processors (with a FPU each) *and* slow floating point anyway due<br>
to Squeak's limitations.<br>
<br>
Squeak does have a scheme for good floating point performance: the<br>
FloatArray. In a previous discussion about this with Bryce, he felt that<br>
between this and being about to compile away boxing/unboxing operations<br>
within a single method (also mentioned by Hans-Martin in this thread) we<br>
could have essentially the same performance as immediate floats (and<br>
Hans-Martin pointed out that the bit pattern I suggested is already in<br>
use anyway).<br>
<br>
Nicolas evaluated the advantages of the "64 bit everything is a float"<br>
scheme, which I unfortunately don't remember who was the inventor. One<br>
trick that some old mainframes used was to represent integers as<br>
denormalized floating point numbers, so you would need no checks nor<br>
conversions. The IEEE 754 standard doesn't seem to support this,<br>
however.<br>
<br>
As Bert pointed out, lack of floating point hardware was the reason<br>
given for not choosing the ARM for the first OLPC machine. Ivan<br>
mentioned fixed point as an alternative, and this is actually what I<br>
have used in my projects (specially the Forth based ones) for most of<br>
the past ten years. But for Squeak I would rather just give people what<br>
they are used to (not counting Fractions, LargeIntegers and such, of<br>
course). Juan gave a list of application domains where floats are<br>
considered fundamental.<br>
<br>
Hans-Martin and Claus asked about the availability of 64 bit hardware<br>
for the scheme I mentioned. That is indeed a problem (only my old Sparc<br>
machine would be able to run a 64 bit Squeak of the 14 or so computers I<br>
have around here, for example) but it could be solved by doing some<br>
conversions when saving/loading images. We need to do transformations<br>
when moving between 32 and 64 images anyway and unboxing floats would be<br>
one of the simplest.</blockquote><div><br></div><div>...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?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<font color="#888888"><br>
-- Jecel<br>
<br>
<br>
</font></blockquote></div><br>