Difference between revisions of "Runtime Type Encoding"

(Decoding)
(Decoding)
Line 20: Line 20:
 
Instead the Eiffel compiler must generate some code to fill the gap. For the following example:
 
Instead the Eiffel compiler must generate some code to fill the gap. For the following example:
  
<code>
+
<e>
 
list: LIST [like item]
 
list: LIST [like item]
</code>
+
</e>
  
 
the compiler will generate the following encoding:
 
the compiler will generate the following encoding:
Line 31: Line 31:
 
In pseudo-C code it looks like:
 
In pseudo-C code it looks like:
  
<code>
+
<c>
 
typearr = { LIST_ID, 0, TERMINATOR_TYPE};
 
typearr = { LIST_ID, 0, TERMINATOR_TYPE};
 
typearr[1] = Result_of_computation_of_id_of_like_item;
 
typearr[1] = Result_of_computation_of_id_of_like_item;
</code>
+
</c>
  
 
In melted code, we do include them in the encoding, because the interpreter will use the data from the encoding to compute the type of the anchor and then build an encoding similar to the one used for the C code generation before passing it to the run-time type resolver.
 
In melted code, we do include them in the encoding, because the interpreter will use the data from the encoding to compute the type of the anchor and then build an encoding similar to the one used for the C code generation before passing it to the run-time type resolver.

Revision as of 15:41, 1 August 2008

At runtime, when we need to describe an Eiffel type (TYPE_A instance in the compiler), we use the following encoding:


TYPE A encodings.png


Legend:

  • Words in uppercase refer to constant defined in $EIFFEL_SRC/C/run-time/include/rt_gen_types.h
  • Words in red refer to another abstraction described in the above diagram
  • Words in green are only appearing for melted code generation
  • Eiffel type_id refers to the `type_id' in finalized mode and the `static_type_id' in workbench mode.
  • All other words should be self explanatory

Decoding

The decoding of a type at run-time always occurs within a context. This is needed to resolve when type involves a formal generic parameter or an anchor to Current. The encoding does not cover the case of anchors to a feature (or an argument for pre-ECMA backward compatibility) because it is not supported by the run-time type resolver.

Instead the Eiffel compiler must generate some code to fill the gap. For the following example:

list: LIST [like item]

the compiler will generate the following encoding:

  1. ID for LIST
  2. ID for `like item'

meaning that at runtime, we compute the ID for `like item'.

In pseudo-C code it looks like:

typearr = { LIST_ID, 0, TERMINATOR_TYPE};
typearr[1] = Result_of_computation_of_id_of_like_item;

In melted code, we do include them in the encoding, because the interpreter will use the data from the encoding to compute the type of the anchor and then build an encoding similar to the one used for the C code generation before passing it to the run-time type resolver.