<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 14 November 2013 17:44, Eliot Miranda <span dir="ltr">&lt;<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 14, 2013 at 3:43 AM, Igor Stasenko <span dir="ltr">&lt;<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 12 November 2013 19:23, Eliot Miranda <span dir="ltr">&lt;<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr">Hi Igor,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 12, 2013 at 3:37 AM, Igor Stasenko <span dir="ltr">&lt;<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>&gt;</span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr">And let me remind you what i proposed back then:<br><br>:)<br>===========<br>About immediates zoo.
<br><br>Keep in mind, that the more immediates we have, the more complex implementation
<br>tends to be.
<br><br>I would just keep 2 data types:
<br> - integers
<br> - floats
<br><br>and third, special &#39;arbitrary&#39; immediate , which seen by VM as a 60-bit value.
<br>The interpretation of this value depends on lookup in range-table,
<br>where developer specifying the correspondence between the value
<br>interval and class:
<br>[min .. max] -&gt; class
<br></div></blockquote><div><br></div><div>for this idea to go anywhere you&#39;d have to show at least the pseudo-code for the inline cache test in machine code methods.  These schemes seem great in theory but in practice end up with a long, complex and slow fetchClassOf: and/or inline cache test.  To remind you, you have to compete with the following in Spur Cog:</div>



<div><br></div><div><div><span style="white-space:pre-wrap">        </span>Limm:</div><div><span style="white-space:pre-wrap">                </span>andl $0x1, %eax</div><div><span style="white-space:pre-wrap">                </span>j Lcmp</div>
<div><span style="white-space:pre-wrap">        </span>Lentry:</div><div><span style="white-space:pre-wrap">                </span>movl %edx, %eax</div><div><span style="white-space:pre-wrap">                </span>andl $0x3, %eax</div>
<div><span style="white-space:pre-wrap">                </span>jnz Limm</div><div><span style="white-space:pre-wrap">                </span>movl 0(%edx), %eax</div><div><span style="white-space:pre-wrap">                </span>andl $0x3fffff, %eax</div>
<div><span style="white-space:pre-wrap">        </span>Lcmp:</div></div></div></div></div></blockquote><div><br>It is extra comparison for immediate case:<br></div><div><br>cmp eax, LowRange<br></div><div>jl miss<br></div><div>


cmp eax, HighRange<br></div><div>jg miss<br></div></div></div></div></blockquote><div><br></div><div>I don&#39;t understand.  Does that mean there are two cache entries, one for HighRange one for LowRange?  Spell it out please.  Give the pseudo-code.  Right now it is too vague for me to see how it is supposed to work.</div>

<div><br></div></div></div></div></blockquote><div><br>Two entries where? If i understand, in COG you using generated code for inline cache, by jumping onto PIC entry for checking if it hits or misses. So, you just generate different code for immediate case(s), to check that receiver oop value is tagged and within certain range (cache hit) , or not (cache miss).<br>
</div><br></div><div class="gmail_quote"></div><div class="gmail_quote">A pseudo-code for bit-pattern matching is this: <br><br></div><div class="gmail_quote">&quot;presuming least significant bit is tag&quot;<br></div><div class="gmail_quote">
(oop bitAnd: 2r101) == 2r101 ifTrue: [ hit ] ifFalse: [ miss ]<br><br>And code for range matching is this:<br><br><div class="gmail_quote">&quot;presuming least significant bit is tag&quot;<br></div>(oop odd and: [ oop between: lowValue and: highValue]) ifTrue: [ hit ] ifFalse: [ miss ]<br>
<br><div class="gmail_quote">&quot;or presuming most significant bit is tag&quot;<br></div>(oop between: lowValue and: highValue) ifTrue: [ hit ] ifFalse: [ miss ]<br><br><br><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div></div><div> <br></div>
<div>so, if value between low &amp; high range, it is already known what class it is otherwise<br></div><div>you got cache miss.<br><br></div><div>And this scheme works even better if you pick highest bit for tagging, like that you can get rid of testing tag bit completely:<br>


<div><span style="white-space:pre-wrap">                </span>andl $0x1, %eax</div><div><span style="white-space:pre-wrap">                </span>j Lcmp</div>and start straight from comparing with high and low values.<br></div><div>That of course, if we can use highest bit for tagging.<br>


</div><div><br></div><div>The class lookup then will be binary search in table of ranges, which is O(log n).<br></div></div></div></div></blockquote><div><br></div><div>So the inline cache becomes a range of entries?  That will cause a significant code bloat.</div>

<div></div></div></div></div></blockquote><div><br></div><div>i&#39;m not sure i understood, what that extra inline cache you talking about?<br>presuming that each PIC is generated code, you just generate different code for entry which specialized to detect<br>
that given oop is of certain immediate class.<br><br></div><div>But if its not, then yes, you need to hold these two values somewhere to be able to compare them with input oop.<br clear="all"></div></div>But even in that case, i fail to see how single extra comparison could cause so much bloat.<br>
</div><div class="gmail_extra"><br>And it always good to compare, how much bloat will cause bit pattern matching code.<br><br></div><div class="gmail_extra">What is clearly beneficial for immediate ranges that you can redefine them at any moment by introducing<br>
</div><div class="gmail_extra">new kinds of immediates , without need to even touch VM: language can easily control that.<br></div><div class="gmail_extra">And the potential number of immediate classes is much bigger , if you encode them in ranges, because:<br>
<br></div><div class="gmail_extra">2^31 (smallint) + 2^32 (short float) + 2^24 (character unicode)  = 6459228160<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">which leaves us:<br><br>2^63 - 6459228160 =  9223372030395547648<br>
</div><div class="gmail_extra">space for other kinds of immediates, which we can introduce later !!without!! need to ever bother VM again.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">-- <br>Best regards,<br>
Igor Stasenko.
</div></div>