<br><br><div class="gmail_quote">On Fri, May 8, 2009 at 2:26 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;">
<br>
Sorry about the wrong attribution - Celeste makes a big mess of all of<br>
Eliot's emails and most replies to those emails. Unfortunately, fixing<br>
this is not currently near the top of my "to do" list so I'll just have<br>
to deal with this for a few more months.<br>
<br>
I totally agree about the value of immediates being to speed up<br>
computations by avoiding allocations. My idea for symbols was not to<br>
avoid the costly mapping of strings to new instances but rather speed up<br>
class lookup a little bit. This wouldn't help us now, but for a future<br>
modular Squeak that would be loading and unloading object graphs all the<br>
time, this could make a difference.</blockquote><div><br></div><div>One of the things I think would really helps here is to have a way of assigning the id-hash of a Symbol based on its string hash. Then MethodDictionaries and the like don't have to be rehashed on load. I could imagine a new:withHash: primitive that creates an object with a specified hash atomically, whihc is safer than adding a separate setIdHash: primtive; VW has the latter.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Like VisualWorks, Self uses 30 bit integers with a 00 tag (which makes<br>
detagging/retagging unnecessary for addition, subtraction and bitwise<br>
logical operations). </blockquote><div><br></div><div>FYI, VW does not use 00 for SmallIntegers; it uses 00 for objects. So it does have to detag for certain operations. But of course it optimizes addition/subtraction by only detagging one of the two values so it doesn't have to retag.</div>
<div><br></div><div>Self, Strongtalk and V8 all do use 00.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The other tag values represent 30 bit floats,<br>
object pointers (you always use a constant offset with these anyway, so<br>
the detagging can be built into that constant) and object headers. The<br>
memory is divided into segments (generations) and each segment stores<br>
tagged data from the bottom and binary data from the top. ByteVectors<br>
are normal tagged objects with a SmallInteger pointing to the actual<br>
bytes.<br>
<br>
The idea of a tag pattern for object headers is that you can "flatten"<br>
the memory scanning operations. You just scan from top to the limit<br>
until you found what you were looking for and then back up to the<br>
previous header to see what object contains that oop. This can be many<br>
times faster than a objects do: [ :obj | obj fieldsDo: [ :oop | ....]]<br>
nested loop.</blockquote><div><br></div><div>Yes, this is neat. They use it in become operations which are very common as slots are added and removed right?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
For my old RISC42 design I came up with the idea of having the top two<br>
bits the same to indicate SmallIntegers. This is hard to check in<br>
software, but in hardware is just a two input XOR gate. This allows you<br>
to avoid detagging not only for the operations I mentioned above, but<br>
also for multiplies, divides, left shift and signed right shift too. A<br>
few weeks ago I found out that the old Swamp Smalltalk computer from<br>
1986 used exactly the same scheme (the two patterns where the top two<br>
bits were different were used for oops and for pointers to context<br>
objects).<br>
<font color="#888888"><br>
-- Jecel<br>
<br>
</font></blockquote></div><br>