<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<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>
<br>
Cheers,<br>
Florin<br>
</body>
</html>