Thanks Andreas. We were putting zeros just by chance and that&#39;s why it was working, but we didn&#39;t understand why. Now we do.<br><br>Cheers<br><br>Mariano<br><br><div class="gmail_quote">On Mon, May 23, 2011 at 2:07 PM, Andreas Raab <span dir="ltr">&lt;<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <br>

  
    
    
  
  <div bgcolor="#ffffff" text="#000000">
    On 5/23/2011 11:14, Mariano Martinez Peck wrote:
    <blockquote type="cite">
      <pre> </pre>
      <br>
      <fieldset></fieldset>
      <br>
      Excellent point. Thanks Andreas. I am serializing to disk a CM and
      I want to be sure it will work when I materialize it and load back
      later on in an image (it can be even a different image). So, I
      guess that the externalPrimitiveTable can change and even more the
      module of such named primitive may not be loaded at that time.<br>
      <br>
      So, it is correct so assume that the safest approach is to put a
      zero as function index ?  this way it will always work?<br>
    </blockquote>
    <br>
    Yes.<br>
      - A.<br>
    <br>
    <blockquote type="cite"><br>
      Thanks!<br>
      <br>
      Mariano<br>
      <br>
      <div class="gmail_quote">On Mon, May 23, 2011 at 10:09 AM, Andreas
        Raab <span dir="ltr">&lt;<a href="mailto:andreas.raab@gmx.de" target="_blank">andreas.raab@gmx.de</a>&gt;</span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"> <br>
          <div bgcolor="#ffffff" text="#000000"> See the comment in
            Interpreter&gt;&gt;primitiveExternalCall.<br>
            <br>
            primitiveExternalCall<br>
                &quot;Call an external primitive. The external primitive
            methods <br>
                contain as first literal an array consisting of: <br>
                * The module name (String | Symbol) <br>
                * The function name (String | Symbol) <br>
                * The session ID (SmallInteger) [OBSOLETE] <br>
                * The function index (Integer) in the
            externalPrimitiveTable <br>
                For fast failures the primitive index of any method
            where the <br>
                external prim is not found is rewritten in the method
            cache <br>
                with zero. This allows for ultra fast responses as long
            as the <br>
                method stays in the cache. <br>
                The fast failure response relies on lkupClass being
            properly <br>
                set. This is done in <br>
                #addToMethodCacheSel:class:method:primIndex: to <br>
                compensate for execution of methods that are looked up
            in a <br>
                superclass (such as in primitivePerformAt). <br>
                With the latest modifications (e.g., actually flushing
            the <br>
                function addresses from the VM), the session ID is
            obsolete. <br>
                But for backward compatibility it is still kept around.
            Also, a <br>
                failed lookup is reported specially. If a method has
            been <br>
                looked up and not been found, the function address is
            stored <br>
                as -1 (e.g., the SmallInteger -1 to distinguish from <br>
                16rFFFFFFFF which may be returned from the lookup). <br>
                It is absolutely okay to remove the rewrite if we run
            into any <br>
                problems later on. It has an approximate speed
            difference of <br>
                30% per failed primitive call which may be noticable but
            if, <br>
                for any reasons, we run into problems (like with J3) we
            can <br>
                always remove the rewrite. <br>
                &quot;<br>
            <br>
            <br>
            On 5/23/2011 10:03, Mariano Martinez Peck wrote:
            <blockquote type="cite">
              <pre> </pre>
              <br>
              <fieldset></fieldset>
              <br>
              Hi folks. I was inspecting for example the CM of  Integer
              &gt;&gt; #bitAnd:   and the first literal is an array like
              this: #(#LargeIntegers #primDigitBitAnd 0 17)<br>
              <br clear="all">
              I understand the first and the second elements, but I
              don&#39;t the third and the fourth. What are they? (0 and 17)
              because then even seem to change their value.<br>
              <br>
              I am asking because I am serializing CompiledMethod and
              then at materialization time I am putting just two zeros
              for the moment. But I am not sure what they mean.<br>
              <br>
              Thanks in advance,<br clear="all">
              <br>
              -- <br>
              Mariano<br>
              <a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br>
              <br>
            </blockquote>
          </div>
          <br>
        </blockquote>
      </div>
      <br>
      <br clear="all">
      <br>
      -- <br>
      Mariano<br>
      <a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br>
      <br>
    </blockquote>
  </div>

<br></blockquote></div><br><br clear="all"><br>-- <br>Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br><br>