<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On Mar 11, 2016, at 5:09 PM, Florin Mateoc <<a href="mailto:florin.mateoc@gmail.com">florin.mateoc@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">On 3/11/2016 5:47 PM, Eliot Miranda
wrote:<br>
<br>
<br>
<snip><br>
<br>
</div>
<blockquote cite="mid:CAC20JE3mhN80=skpkQKV6wvYd_V4qA31kiiEHhSsmom25PPvmw@mail.gmail.com" type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>The simulation is pretty close. The JIT's simulation
closer. This is simply history, plus the fact that
debugging a JIT is more difficult and therefore more
accurate simulation helps.</div>
<div> </div>
<div>But if you're interested in closed world translations
you might contact Gerardo Richarte and Xavier Burroni and
ask them about their JIT work.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In
addition to the general question above, to help me correct
some of my misunderstandings/intuitions, which are solely<br>
based on reading this relatively obscure code, can you
please elucidate a couple of mysteries for me?<br>
<br>
1. Was this fetchLong64: bug a V3 VM bug as well or just a
simulation bug?<br>
</blockquote>
<div><br>
</div>
<div>Just a simulation bug. The code generated for the real
VM is correct.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">2.
Why do magnitude64BitValueOf: and positive64BitValueOf:
not differentiate between BigEndian and LittleEndian?<br>
</blockquote>
<div><br>
</div>
<div>They don't have to. Large Integers in Smalltalk are
always little endian. Nicolas Cellier has a prototype
that would organize then as a sequence of 32-bit words, in
which case they would be endian-dependent, but this is
problematic because in 32-bit systems SmallInteger is only
31 bits, and so accessing the one and only 32-bit word of
the large integer 16rFFFFFFFF answers that large integer
itself. Further, organizing it as a sequence of 16-bit
words doesn't help either because 16rFFFF * 16rFFFF
overflows 31-bit SmallIntegers. so if one wants to be able
to implement large integer arithmetic non-primitively in
the image using SmallIntegers, 8 bits is the largest
convenient unit.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">3.
Why do we have both primitives above? They both seem used,
but why do some primitives use the first one, coupled with<br>
separate calls for sign, instead of just using the signed
version (see primitiveAddLargeIntegers)?<br>
</blockquote>
<div><br>
</div>
<div>Some large integer primitives want to interpret the bit
patterns in large integers as bit patterns and use
magnitude64BitValueOf:. So,e primitives want to interpret
the bit patterns in large integers as arithmetic values,
failing for LargeNegativeInteger, and use
positive64BitValueOf:. Perhaps positive64BitValueOf: is
surplus to requirements, but it fits with the existing
set. BTW, they are /not/ primitives. They are run-time
support functions. Let's not get confused.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><font color="#888888">Florin<br>
</font></span></blockquote>
</div>
<div><br>
</div>
<div class="gmail_signature">
<div dir="ltr">
<div><span style="font-size:small;border-collapse:separate">
<div>_,,,^..^,,,_<br>
</div>
<div>best, Eliot</div>
</span></div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Thank you for the explanations, especially since I know you are very
busy.<br>
<br>
As for my interest in closed world translations, I am indeed
interested and I know it can be done (the type inferencing and
inlining parts), but if I don't have "customers", meaning especially
you as Squeak's main vm developer, I won't spend time on it. It is
not a trivial project.<br></div></blockquote><div><br></div>Then maybe we can pull you into some Sista work. Eventually it will make sense to work in closed world translations, especially if, as Gerardo and Xavier did, one wants to write the VM in pure Smalltalk and have it translate itself (bootstrap itself) to external code. But that may be quite an effort and be something we can collaborate on. But right now the focus is on making what else have now fast and complete. The "perfect" solution can wait until we can afford the opportunity cost.<div><br><blockquote type="cite"><div>
<br>
Cheers,<br>
Florin<br>
</div></blockquote></div></body></html>