<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
See the comment in Interpreter>>primitiveExternalCall.<br>
<br>
primitiveExternalCall<br>
"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>
"<br>
<br>
<br>
On 5/23/2011 10:03, Mariano Martinez Peck wrote:
<blockquote
cite="mid:BANLkTim1auOfg9-SLqajU-gT+hX-sOdvUg@mail.gmail.com"
type="cite">
<pre wrap=""> </pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
Hi folks. I was inspecting for example the CM of Integer >>
#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'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 moz-do-not-send="true" href="http://marianopeck.wordpress.com"
target="_blank">http://marianopeck.wordpress.com</a><br>
<br>
</blockquote>
</body>
</html>