<div dir="ltr">Hi Chris,<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 13, 2014 at 12:24 PM, Chris Muller <span dir="ltr"><<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>></span> wrote:<br><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">Hi Eliot and all, while moving some serialized objects from a Cog<br>
image into a Spur image, I am encountered an issue materializaing a<br>
CompiledMethod instance in the target Spur image due to the new<br>
implementation of #numLiterals. In Cog it's:<br>
<br>
numLiterals<br>
"Answer the number of literals used by the receiver."<br>
| header |<br>
^(header := self header) < 0<br>
ifTrue: [header bitAnd: 65535]<br>
ifFalse: [(header bitShift: -9) bitAnd: 16rFF]<br>
<br>
but in Spur, only the negative header condition is present:<br>
<br>
numLiterals<br>
"Answer the number of literals used by the receiver."<br>
^self header bitAnd: 65535<br></blockquote><div><br></div><div>Right.</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">The header was positive in the source Cog image, in fact, there are NO<br>
instances of CM's with negative headers in either my Cog or Spur<br>
images. So after constructing the CompiledMethod for materialization<br>
within the Spur image with the same #header it had in Cog, it reports<br>
the wrong #numLiterals and can't finish the materialization because of<br>
that.<br></blockquote><div><br></div><div>Right.</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">I'm able to force a correct materialization by changing the place<br>
where I access "numLiterals" to the original True condition of Cog --<br>
"(header bitShift: -9) bitAnd: 16rFF".<br></blockquote><div><br></div><div>Good. That is the "right thing to do" (tm). Or rather it is the right thing to do when trying to import methods from Cog to Spur.</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">But that's just "making it work" and not understanding the<br>
implications of what I'm doing. I know Spur can allow more literals<br>
per CM, but assuming I'm willing to stay with a max of just 255<br>
literals for now, is my override above the best way to handle this<br>
need to be able to transfer objects back-and-forth within a<br>
heterogeneous environment of Cog and Spur images?<br></blockquote><div><br></div><div>Yes, as long as it is on;y used for porting. You obviously /don'/ need it when materializing in Spur methods that have been dematerialized in Spur (BTW, I like the "official" terms, "pickled" and "unpickled").</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">Thanks for any advice and insight..<br>
</blockquote></div><div class="gmail_extra"><br></div>So the new format was introduced to lift the limit on the number of literals. I first implemented it for Newspeak a couple of years ago for Cadence. At this point it used the sign bit to allow both the old and new header formats to coexist:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"> numLiterals</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"> "Answer the number of literals used by the receiver."</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"> | header |</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"> ^(header := self header) < 0</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"> ifTrue: [header bitAnd: 65535]</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"> ifFalse: [(header bitShift: -9) bitAnd: 16rFF]</span><br><br clear="all"><div><br></div><div>The problems with this are</div><div>- that sign bit allows choosing between bytecode sets, and so it couples bytecode set choice with literal limit, and</div><div>- there is a cost, at least in code density, even if not necessarily much in performance, in the VM using the "mixed" format.</div><div><br></div><div>I realised in late summer with Spur that I had a chance of eliminating the coupling and performance issues by insisting on the one format in Spur. So I decided to eliminate the old format and just go with the simple format (this taken from CompiledMethod's class comment in its Spur version):</div><div><br></div><div><div>The header is a 31-bit signed integer (a SmallInteger) in the following format:</div><div><br></div><div><span class="" style="white-space:pre">        </span>(index 0)<span class="" style="white-space:pre">                </span>16 bits:<span class="" style="white-space:pre">        </span>number of literals (#numLiterals)</div><div><span class="" style="white-space:pre">        </span>(index 16)<span class="" style="white-space:pre">                </span> 1 bit:<span class="" style="white-space:pre">        </span>has primitive</div><div><span class="" style="white-space:pre">        </span>(index 17)<span class="" style="white-space:pre">                </span> 1 bit:<span class="" style="white-space:pre">        </span>whether a large frame size is needed (#frameSize => either SmallFrame or LargeFrame)</div><div><span class="" style="white-space:pre">        </span>(index 18)<span class="" style="white-space:pre">                </span> 6 bits:<span class="" style="white-space:pre">        </span>number of temporary variables (#numTemps)</div><div><span class="" style="white-space:pre">        </span>(index 24)<span class="" style="white-space:pre">                </span> 4 bits:<span class="" style="white-space:pre">        </span>number of arguments to the method (#numArgs)</div><div><span class="" style="white-space:pre">        </span>(index 28)<span class="" style="white-space:pre">                </span> 2 bits:<span class="" style="white-space:pre">        </span>reserved for an access modifier (00-unused, 01-private, 10-protected, 11-public), although accessors for bit 29 exist (see #flag).</div><div><span class="" style="white-space:pre">        </span>(index 30/63)<span class="" style="white-space:pre">        </span>sign bit: 1 selects the Secondary instruction set (e.g. NewsqueakV4, 0 selects the primary instruction set, e.g. SqueakV3PlusClosures) (#signFlag)</div></div><div><br></div><div>This a) makes the VM slimmer and b) makes it much less complicated to use the two bytecode sets. The ability to use two bytecode sets provides a smoother transition to Sista when it arrives next year.</div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>