Runtime Type Encoding

Description

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

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

Note: We refer to FROZEN_TYPE. This is not yet an abstraction standardized by ECMA and is only present in our runtime for evaluation purpose of this new abstraction.

How to encode generic types?

When you have a generic type, the encoding is basically the addition of the encoding of each class used in the type. For example LIST [HASH_TABLE [STRING, STRING]] is encoded as

{LIST_ID, HASH_TABLE_ID, STRING_ID, STRING_ID, TERMINATOR_TYPE}

The runtime will know how to decode this properly (see below).

Decoding

Context

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;

Note: For formal generic parameter, the same code as used for anchors to feature appears all the time in workbench mode and in finalized mode only when the compiler cannot prove that in all descendants of the class in which the formal appears it is still a formal.

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.

Generic type

When you are given a generic type as LIST [HASH_TABLE [STRING, STRING]] then the runtime knows how many actual generic parameter a type expect. In this case, LIST has only 1, HASH_TABLE 2 and STRING none. The only case where we do not know the number of actual generic parameter there is is for TUPLE. This is why the encoding specifies `tuple count'.