<br><br><div class="gmail_quote">On Tue, Oct 19, 2010 at 3:02 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;">
<div class="im">Igor Stasenko wrote:<br>
<br>
> Btw, about GC:<br>
><br>
> <a href="http://lambda-the-ultimate.org/node/2391" target="_blank">http://lambda-the-ultimate.org/node/2391</a><br>
><br>
> Garbage Collection without Paging, Matthew Hertz, Yi Feng, Emery D.<br>
> Berger. PLDI 2005<br>
<br>
</div>The old Mushroom papers are also worth a look:<br>
<br>
<a href="http://www.wolczko.com/mushroom/index.html" target="_blank">http://www.wolczko.com/mushroom/index.html</a><br>
<br>
About the original thread, I liked the idea Andreas had proposed of a 6<br>
bit class index for immediate values. It fits in well with the existing<br>
compact classes and is easy to optimize in software. Having worked with<br>
Self and Logo where characters are strings of length 1, I can say that I<br>
like that scheme very much and will use it in any language I design but<br>
don't think it is worth changing Squeak to be like this.<br>
<br>
I didn't understand Eliot's comment in his first post:<br>
<div class="im"><br>
> The problem 30 bit floats have is that they're not a useful subset<br>
> of Float. A 60-bit immediate float is a different beast altogether.<br>
> You really need the number of bits to be sihnificanty greater than<br>
> the size of the mantissa. With 30 bits it is still 23 bits short.<br></div></blockquote><div><br></div><div><br></div><div><br></div><div>Squeak uses 64 bit double precision floating-point. VisualWorks uses both 32 bit single and 64-bit double precision floating-point. In Squeak therefore an immediate float of 30 bits would represent a tiny range of the available float range, distributed sparsely within the range. In VW I implemented 61-bit immediate doubles in the 64-bit implementation. These have a full mantissa and a limited 8 bit exponent (64-it dp has an 11 bit exponent). These occupy the middle of the double precision range, approximately from +/- 10^-38 to +/- 10^38. Do math with these values and you get the same answers as with full 64-bit values provided they're in range, and /- 10^-38 to +/- 10^38 is a useful range. Do math in Squeak however and you either have a very small chance of representing a 64-bit value as an immediate or you have to introduce a 32-bit single-precision value /and/ accept a smaller range. e.g. if you chose a 6-bit exponent (to be able to keep then your range is +/- 10^-9 to +/- 10^9.</div>
<div><br></div><div>So for me an immediate float type makes excellent sense in a 64-bit context (VW's 60-bit floats are half as fast as SmallIntegers in the 64-bit VM) but doesn't make much sense in a 32-bit context, especially in a system that expects 64-bit double precision. Better spend the tag on an immediate character type, which has plenty of benefits over the current boxed representation (== works throughout the Unicode range, converting between integers and characters is fast, string access is much faster because the character table goes away).</div>
<div><br></div><div>Does that answer your question?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<br>
</div>It doesn't seem that 32 bits is that much better, but it is what we have<br>
with FloatArrays.</blockquote><div><br></div><div>Um, we can have 64-bit FloatArrays if we want too. 32-bit FloatArrays may make sense to save space, but the Squeak model of using 64-bits for consistent precision seems to work well. In VW there are contortions necessary to deal with the two different float precisions (essentially the question of whether operations on SmallIntegers that yield floats should yield 64-bit or 32-bit results is a thorny one).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Let me explain my motivation for starting this discussion - when people<br>
hear that I am designing a hardware implementation of the SqueakVM, the<br>
most frequent question I get is about what kind of FPU (floating point<br>
unit) the device will have. My reply is that with boxed floats we have<br>
so much overhead (no, I don't have actual numbers...) that I prefer to<br>
include as little hardware support as possible. Just to give you an<br>
example - if you select to have a FPU in the open source Leon 3<br>
processor (32 bit Sparc), that will take up three times the area of the<br>
Leon itself. With unboxed floats, I would be more interested in having<br>
better hardware for them. But I don't want this hardware to be<br>
incompatible with the software VMs and don't want to fork over this<br>
issue.<br></blockquote><div><br></div><div>In the immortal works of the country bumbkin asked how to get to some city "I wouldn't start from here".</div><div><br></div><div>Hardware can accelerate boxing and unboxing of floats just as Cog can. Cog has special machine code allocation for Floats and of course Float is a compact class, which helps in testing for float-ness. But IMO the current Squeak image format is too complex and too slow and we'd do better coming up with a better object representation and GC representation, which implies focussing on kernel/microsqueak/tracer efforts to produce a kernel image and VM work on implementing a new GC.</div>
<div><br></div><div>Jecel, how flexible is your design methodology? If the bytecode set or the object representation were to change how much work would be involved, just some redeclaration or a manual rewrite or somewhere in between?</div>
<div><br></div><div><br></div><div>best</div><div>Eliot</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
-- Jecel<br>
<br>
<br>
</font></blockquote></div><br>