Difference between revisions of "Runtime Type Encoding"

(Decoding)
Line 16: Line 16:
 
== Decoding ==
 
== Decoding ==
  
Decoding of a TYPE_A always occur within a context. This is needed to resolve the case of LIKE_CURRENT_TYPE and FORMAL_TYPE. 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 our type resolver.
+
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:
 
Instead the Eiffel compiler must generate some code to fill the gap. For the following example:
Line 27: Line 27:
 
#ID for LIST
 
#ID for LIST
 
#ID for `like item'
 
#ID for `like item'
meaning that it computed the ID for `like item'.
+
meaning that at runtime, we compute the ID for `like item'.
  
 
In pseudo-C code it looks like:
 
In pseudo-C code it looks like:
Line 33: Line 33:
 
<code>
 
<code>
 
   typearr = { LIST_ID, 0, TERMINATOR_TYPE};
 
   typearr = { LIST_ID, 0, TERMINATOR_TYPE};
   typearr[1] = ID_of_like_item;
+
   typearr[1] = Result_of_computation_of_id_of_like_item;
 
</code>
 
</code>
  
In melted code, we do include them in the encoding, because the interpreted 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 C code before passing it to our 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 14:59, 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.