Generated c code - Revision history

Hzwakenberg: Link to Loria file no longer valid

2024-07-02T12:39:53Z

Link to Loria file no longer valid

← Older revision		Revision as of 14:39, 2 July 2024
Line 2:		Line 2:
	*** have noted some statements that are now obsolete in view of recent compiler changes.		*** have noted some statements that are now obsolete in view of recent compiler changes.
	*** This article and its French counterpart need revising by the development team.		*** This article and its French counterpart need revising by the development team.
−
−	*** You can also read [http://SmartEiffel.loria.fr/man/c_code.html the original article]

	People who want to interface with applications and/or libraries written in C should as far as possible limit themselves to the interfaces provided by [[Cecil]], [[externals\|external]] and [[plugins]]. This page gives details about the generated C code, but these details ought not to be of any use to you. ;-)		People who want to interface with applications and/or libraries written in C should as far as possible limit themselves to the interfaces provided by [[Cecil]], [[externals\|external]] and [[plugins]]. This page gives details about the generated C code, but these details ought not to be of any use to you. ;-)

Hzwakenberg at 12:23, 3 January 2022

2022-01-03T12:23:01Z

← Older revision		Revision as of 14:23, 3 January 2022
Line 3:		Line 3:
	*** This article and its French counterpart need revising by the development team.		*** This article and its French counterpart need revising by the development team.

−	*** You can also ~~use~~ [http://SmartEiffel.loria.fr/man/c_code.html the original article]	+	*** You can also read [http://SmartEiffel.loria.fr/man/c_code.html the original article]

	People who want to interface with applications and/or libraries written in C should as far as possible limit themselves to the interfaces provided by [[Cecil]], [[externals\|external]] and [[plugins]]. This page gives details about the generated C code, but these details ought not to be of any use to you. ;-)		People who want to interface with applications and/or libraries written in C should as far as possible limit themselves to the interfaces provided by [[Cecil]], [[externals\|external]] and [[plugins]]. This page gives details about the generated C code, but these details ought not to be of any use to you. ;-)

Hzwakenberg: correct spelling/verb

2021-12-21T21:16:16Z

correct spelling/verb

← Older revision		Revision as of 23:16, 21 December 2021
Line 242:		Line 242:
	So it is likely that the root class of the system may have the identifier '''12'''. But do not rely on that too much (before all the changes to INTEGERs, it was '''11''').		So it is likely that the root class of the system may have the identifier '''12'''. But do not rely on that too much (before all the changes to INTEGERs, it was '''11''').

−	All [[library_class:NATURAL\|<tt>NATURAL</TT>]] classes ([[library_class:NATURAL\|NATURAL]], [[library_class:NATURAL_8\|NATURAL_8]], [[library_class:NATURAL_16\|NATURAL_16]], [[library_class:NATURAL_32\|NATURAL_32]], [[library_class:NATURAL_64\|NATURAL_64]] and [[library_class:NATURAL_GENERAL\|NATURAL_GENERAL]]) ~~does~~ not have a fixed id.	+	All [[library_class:NATURAL\|<tt>NATURAL</TT>]] classes ([[library_class:NATURAL\|NATURAL]], [[library_class:NATURAL_8\|NATURAL_8]], [[library_class:NATURAL_16\|NATURAL_16]], [[library_class:NATURAL_32\|NATURAL_32]], [[library_class:NATURAL_64\|NATURAL_64]] and [[library_class:NATURAL_GENERAL\|NATURAL_GENERAL]]) do not have a fixed id.

Dkearns: s/LibertyEiffel/Liberty Eiffel/

2016-07-03T06:48:04Z

s/LibertyEiffel/Liberty Eiffel/

Hzwakenberg at 17:51, 5 September 2014

2014-09-05T17:51:25Z

Ramack: using Interwiki for NATURAL classes

2013-04-28T18:05:58Z

using Interwiki for NATURAL classes

← Older revision		Revision as of 20:05, 28 April 2013
Line 243:		Line 243:
	So it is likely that the root class of the system may have the identifier '''12'''. But do not rely on that too much (before all the changes to INTEGERs, it was '''11''').		So it is likely that the root class of the system may have the identifier '''12'''. But do not rely on that too much (before all the changes to INTEGERs, it was '''11''').

−	All [[~~liberty_class~~:NATURAL\|<tt>NATURAL</TT>]] classes (NATURAL, NATURAL_8, NATURAL_16, NATURAL_32, NATURAL_64 and NATURAL_GENERAL) does not have a fixed id.	+	All [[library_class:NATURAL\|<tt>NATURAL</TT>]] classes ([[library_class:NATURAL\|NATURAL]], [[library_class:NATURAL_8\|NATURAL_8]], [[library_class:NATURAL_16\|NATURAL_16]], [[library_class:NATURAL_32\|NATURAL_32]], [[library_class:NATURAL_64\|NATURAL_64]] and [[library_class:NATURAL_GENERAL\|NATURAL_GENERAL]]) does not have a fixed id.

Tybor at 19:49, 4 April 2013

2013-04-04T19:49:11Z

← Older revision		Revision as of 21:49, 4 April 2013
Line 230:		Line 230:
	* '''2''': [[library_class:INTEGER\|<TT>INTEGER</TT>]] (or [[library_class:INTEGER_32\|<TT>INTEGER_32</TT>]])		* '''2''': [[library_class:INTEGER\|<TT>INTEGER</TT>]] (or [[library_class:INTEGER_32\|<TT>INTEGER_32</TT>]])
	* '''3''': [[library_class:CHARACTER\|<TT>CHARACTER</TT>]]		* '''3''': [[library_class:CHARACTER\|<TT>CHARACTER</TT>]]
−	* '''4''': [[library_class:~~REAL~~\|<TT>~~REAL~~</TT>]]	+	* '''4''': [[library_class:REAL_32\|<TT>REAL_32</TT>]]
−	* '''5''': [[library_class:~~DOUBLE~~\|<TT>~~DOUBLE~~</TT>]] ~~''[out~~ ~~of date~~: ~~DOUBLE is no longer supported in 2.2beta5~~]''	+	* '''5''': [[library_class:REAL_64\|<TT>REAL_64</TT>]] (or [[library_class:REAL\|<TT>REAL</TT>]])
	* '''6''': [[library_class:BOOLEAN\|<TT>BOOLEAN</TT>]]		* '''6''': [[library_class:BOOLEAN\|<TT>BOOLEAN</TT>]]
	* '''7''': [[library_class:STRING\|<TT>STRING</TT>]]		* '''7''': [[library_class:STRING\|<TT>STRING</TT>]]
Line 238:		Line 238:
	* '''10''': [[library_class:INTEGER_16\|<TT>INTEGER_16</TT>]]		* '''10''': [[library_class:INTEGER_16\|<TT>INTEGER_16</TT>]]
	* '''11''': [[library_class:INTEGER_64\|<TT>INTEGER_64</TT>]]		* '''11''': [[library_class:INTEGER_64\|<TT>INTEGER_64</TT>]]
		+	* '''12''': [[library_class:REAL_EXTENDED\|<TT>REAL_EXTENDED</TT>]]
−	* ''[what about the various kinds of REAL?]''
		+

	So it is likely that the root class of the system may have the identifier '''12'''. But do not rely on that too much (before all the changes to INTEGERs, it was '''11''').		So it is likely that the root class of the system may have the identifier '''12'''. But do not rely on that too much (before all the changes to INTEGERs, it was '''11''').
		+
		+	All [[liberty_class:NATURAL\|<tt>NATURAL</TT>]] classes (NATURAL, NATURAL_8, NATURAL_16, NATURAL_32, NATURAL_64 and NATURAL_GENERAL) does not have a fixed id.
		+
		+
	</div>		</div>

Ramack at 21:32, 5 March 2013

2013-03-05T21:32:34Z

← Older revision		Revision as of 23:32, 5 March 2013
Line 1:		Line 1:
−	[[Category:~~SmartEiffel~~]]	+	[[Category:Smarteiffel]]
	*** I have partially updated the examples here: the hello_world.id file was generated by se2.2beta5 and I		*** I have partially updated the examples here: the hello_world.id file was generated by se2.2beta5 and I
	*** have noted some statements that are now obsolete in view of recent compiler changes.		*** have noted some statements that are now obsolete in view of recent compiler changes.

Ramack at 20:54, 4 March 2013

2013-03-04T20:54:42Z

← Older revision		Revision as of 22:54, 4 March 2013
Line 1:		Line 1:
−	[[Category:~~Book~~]]	+	[[Category:SmartEiffel]]
	*** I have partially updated the examples here: the hello_world.id file was generated by se2.2beta5 and I		*** I have partially updated the examples here: the hello_world.id file was generated by se2.2beta5 and I
	*** have noted some statements that are now obsolete in view of recent compiler changes.		*** have noted some statements that are now obsolete in view of recent compiler changes.

Ramack: 15 revisions: initial import from SamrtEiffel Wiki - The Grand SmartEiffel Book

2013-03-03T21:04:51Z

15 revisions: initial import from SamrtEiffel Wiki - The Grand SmartEiffel Book

New page

[[Category:Book]]
*** I have partially updated the examples here: the hello_world.id file was generated by se2.2beta5 and I
*** have noted some statements that are now obsolete in view of recent compiler changes.
*** This article and its French counterpart need revising by the development team.

*** You can also use [http://SmartEiffel.loria.fr/man/c_code.html the original article]

People who want to interface with applications and/or libraries written in C should as far as possible limit themselves to the interfaces provided by [[Cecil]], [[externals|external]] and [[plugins]]. This page gives details about the generated C code, but these details ought not to be of any use to you. ;-)

== The type identifiers ==

=== Description ===

SmartEiffel generates one unique identifying number for each active type in the Eiffel code<sup>[[Generated c code#note1|1]]</sup>. A lot of symbols in the generated C code depend on that identifier.

'''Don't depend on those identifiers!''' The mangling table is only valid for one specific compilation of one specific application with one specific compiler version, for one compiler [[compile_to_c]] in one specific version and libraries in one specific version... We do not guarantee the stabbility of these identifiers.

If ''27'' is an identifier, then:

* The C type of an Eiffel object is '''T27''';
* The corresponding C structure is '''struct S27'''; in that structure, the names of the attributes are prefixed with an underscore (there may be some other fields used by SmartEiffel, in particular, the <TT>id</TT> field, which in this case has the value 27). <br> Each reference type can be cast to <TT>T0</TT> (although some reference types may not have the <TT>id</TT> field).
* Each method is called '''r27''method_name''()'''
* Each prefix method is called '''r27_px_''method_name''()'''
* Each infix method is called '''r27_ix_''method_name''()'''
* Each late-binding method is called '''X27''method_name''()'''
* The object's creation method (when the [[Garbage collector|garbage collector]] is used) is called '''new27()'''
* The type model is a variable called '''M27'''. Models are used for initialisation. For example:
T27 M27 = {27,NULL,NULL,0,0};
...
{T27*n=((T27*)se_malloc(sizeof(*n)));
*n=M27;
r27make(n);
...

Some characters in method names, such as <TT>"<"</TT> or <TT>"+"</TT>, will be replaced by their corresponding ASCII code in decimal.

=== An example ===

For example: [[library_class:STRING|<TT>STRING</TT>]] has the identifier '''7'''<sup>[[Generated c code#note2|2]]</sup>. So:

* The object type is '''T7'''.
typedef struct S7 T7;
* The structure is defined in '''struct S7'''.
struct S7{Tid id;T9 _storage;t2 _count;t2 _capacity;};
* The <TT>append</TT> method becomes:
void r7append(se_dump_stack*caller,T7* C,T0* a1)
(See below for details on the ''dump stack'' execution stack.)

=== The <TT>.id</TT> file ===

When the application is compiled, the list of identifiers is stored in a file whose name is suffixed <TT>.id</TT>. The file is reread in incremental compilations (which allows some stability in the identifiers, so long as the whole project is not recompiled).

This file is structured in ''entries'', each entry being separated from others by a hash character (<TT>#</TT>). This file looks like this:

5 "REAL"
class-path: "/SmartEiffel/lib/numeric/real.e"
class-name: REAL
assertion-level: all
parent-count: 1 inherit: 49
#
72 "FAST_ARRAY"
class-path: "/SmartEiffel/lib/storage/collection/fast_array.e"
class-name: FAST_ARRAY
assertion-level: all
parent-count: 1 inherit: 58
#
62 "STD_ERROR"
class-path: "/SmartEiffel/lib/io/terminal/std_error.e"
class-name: STD_ERROR
assertion-level: all
parent-count: 1 inherit: 39
c-type: T62 reference: yes
ref-status: live id-field: yes
destination-graph-nodes: ->OUTPUT_STREAM
run-time-set-count: 1
run-time-set:
STD_ERROR (62)
#
. . .

You should never depend on these identifiers. In any case, when an identifier is computed, collisions may occur, and affect the process. Thus, the identifier and name of each type depends not only on the type name, but also on the order in which the types are compiled. That is, on the order of ''application'' and ''library'' types combined... They also depend on the compilation mode used (since that can change the list of active types), and the version of the compiler you're using. So what is <TT>T145</TT> today may be <TT>T234</TT> tomorrow<sup>[[Generated c code#note3|3]]</sup>!

Consequently, '''do not ever rely on the generated identifiers, because they are not constant!''' Do not try to write in your own C code horrible things like <TT>new123</TT> or <TT>T456</TT>, because the only thing we can guarantee is that this code will not work.

== Naming convention ==

The preceding section has explained how methods are generated.

The function prototype <TT>r7append()</TT> from the example above is presented as
v7append(se_dump_stack*caller,T7* C,T0* a1);
This shows how ''Current'' and the arguments are passed. The rules are as follows:

* ''Current'' is called <TT>C</TT> and is always strongly typed (with its own exact type). This parameter may be omitted if Current is not used by the method. In some cases (when code is inlined), ''Current'' can be copied in local variables named <TT>C1</TT>, <TT>C2</TT>...
* The arguments are called <TT>a1</TT>, <TT>a2</TT>... and are typed <TT>T0*</TT> for reference types or given their exact type for expanded types (e.g. <TT>T2</TT> for an integer)
* Inside functions, a local variable <TT>R</TT> is defined. This is ''Result''.
* Local variable keep their Eiffel name, prefixed by an underscore.

=== Agent routines ===

Functions of the form _T111C222l333c444 are agent creations.

222 is the id of the class where the agent creation was written (look it up in
the .id file);
333 is the line number;
444 is the column number.

111 is a little more difficult to explain. It is the id of the type from which
this agent creation will be executed. It can be the same as 222, but it will
be different if 222 corresponds to a generic class, and it can also be
different if a class inherits from 222.

For example, function _T832C832l1362c106
was declared in class #832, on
line 1362 column 106.

== The mangling table ==

OK, now you understand why you cannot use type numbers, but you still want to know what those fields in the mangling table mean (in the <TT>.id</TT> file)>..

First, a big caveat. Although it may have been very stable for quite some time now, '''the mangling table coding may change'''! We currently have no plans to change it, and we prefer keeping it the way it is. But once again, we do not commit ourselves to the current representation.

Let's look again at the extract of a <TT>.id</TT> file. The part shown covers nearly all the possible cases:

5 "REAL"
class-path: "/SmartEiffel/lib/numeric/real.e"
class-name: REAL
assertion-level: all
parent-count: 1 inherit: 49
#
72 "FAST_ARRAY"
class-path: "/SmartEiffel/lib/storage/collection/fast_array.e"
class-name: FAST_ARRAY
assertion-level: all
parent-count: 1 inherit: 58
#
62 "STD_ERROR"
class-path: "/SmartEiffel/lib/io/terminal/std_error.e"
class-name: STD_ERROR
assertion-level: all
parent-count: 1 inherit: 39
c-type: T62 reference: yes
ref-status: live id-field: yes
destination-graph-nodes: ->OUTPUT_STREAM
run-time-set-count: 1
run-time-set:
STD_ERROR (62)
#
. . .

There is one entry per type (active or not); each entry spans many lines and is terminated by a hash symbol (<TT>#</TT>).

Each entry contains a lot of information. Not all of it is always present; missing entries take default values.

Only the first line is compulsory. It contains the type identifier, and its name (as would be returned by <TT>generating_type</TT>).

The following lines contain different fields, marked by a keyword, a colon and a value. There may be one or more fields on a single line. Those fields are:

{|
|-
| '''class-path'''
| The path to the file containing the source code. May be omitted if the class has no associated file (uncommon).
|-
| '''class-name'''
| The name of the class, as returned by <TT>generator</TT>.
|-
| '''parent-count'''
| Le number of parents.
|-
| '''inherit'''
| On the same line as '''parent-count''' if the latter is not null; it gives the list of parent class identifiers.
|-
| '''c-type'''
| The C type, usually in the form '''T27'''. If it is omitted, the class has no runnable type.
In that case, the following fields do not appear either.
|-
| '''reference'''
| On the same line as '''c-type''', <TT>yes</TT> for a reference type or <TT>no</TT> for an expanded type.
|-
| '''ref-status'''
| Either <TT>live</TT> for an active type (i.e. instances of this type are created at run-time), or <TT>dead</TT> otherwise.
|-
| '''id-field'''
| On the same line as '''ref-status''', <TT>yes</TT> if the <TT>id</TT> field has to be generated in the C structure (as its first element), <TT>no</TT> otherwise. This field is present if one of these confitions is true:
* some late binding may occur on targets of that type,
* or the structure may be accessed by an [[external]] or by [[cecil]].
Note that a lot of calls are statically computed; the type inference algorithm used in SmartEiffel increases the number of such types that do not need the id field.

|-
| '''destination-graph-nodes'''
| ????? 
|-
| '''run-time-set-count'''
| The number of concrete, active descendants of the type (including itself). This is the number of items in '''run-time-set''' below.
|-
| '''run-time-set'''
| The concrete, active heirs of this type (including itself). One class per line, tab-indented.
|}

== The dump stack ==

'''When not in boost mode''', a stack is managed by the runtime environment generated by SmartEiffel. This stack is displayed when an uncaught exception is raised. It is also used by the debugger [[sedb]].

Technically, the SmartEiffel stack is built upon the native (C) stack. Each stack element is a <TT>se_dump_stack</TT><sup>[[Generated c code#note4|4]]</sup> usually allocated on the stack<sup>[[Generated c code#note5|5]]</sup>. It is made up of several parts:

* a frame descriptor, of type <TT>se_frame_descriptor</TT><sup>[[Generated c code#note4|4]]</sup> which is a static description of the feature, as follows:
** run type,
** does it use Current,
** number and type of the local variables, and
** an anti-recursion flag (for contracts)...
* a dynamic part:
** a pointer to ''Current'' (i.e. either a pointer to an expanded object, or else a pointer to a reference object, it being a pointer to the object itself). That is why the type of the <TT>current</TT> field is <TT>Void**</TT>. This field will be <TT>NULL</TT> if ''Current'' is not used by the ''feature'',o
** the position (used mainly by [[sedb]]),
** a pointer to the caller (i.e. the <TT>se_dump_stack</TT> of the calling function),
** a pointer to the exception origin: if not <TT>NULL</TT>, it means that this <TT>se_dump_stack</TT> ''is not'' in the stack, but was malloc'ed to preserve the exception stack trace,
** an array of local variables (with double indirection as for ''Current''), hence the type void***.

Macros handle the linking between the <TT>se_dump_stack</TT> frames.

* Normally, the top of the dump stack is the global variable <TT>se_dst</TT> defined in <TT>SmartEiffel/sys/runtime/no_check.c</TT>. The macro <TT>set_dump_stack_top</TT> accomplishes the assignment of its argument in this variable.
* In [[SCOOP]] mode, each processor has its own stack. So the <TT>set_dump_stack_top</TT> macro has two arguments: the processor and the new dump stack top.

----
<div id="note1">1. There is a bijection (a one to one relationship) between the number and the ''name'' of the type (including the value of its generic parameters in the case of generic types). </div>

<div id="note2">2. There are some identifiers that are reserved for "basic" types. They are:

* '''0''': the type any other can be cast to
* '''1''': [[library_class:INTEGER_8|<TT>INTEGER_8</TT>]]
* '''2''': [[library_class:INTEGER|<TT>INTEGER</TT>]] (or [[library_class:INTEGER_32|<TT>INTEGER_32</TT>]])
* '''3''': [[library_class:CHARACTER|<TT>CHARACTER</TT>]]
* '''4''': [[library_class:REAL|<TT>REAL</TT>]]
* '''5''': [[library_class:DOUBLE|<TT>DOUBLE</TT>]] ''[out of date: DOUBLE is no longer supported in 2.2beta5]''
* '''6''': [[library_class:BOOLEAN|<TT>BOOLEAN</TT>]]
* '''7''': [[library_class:STRING|<TT>STRING</TT>]]
* '''8''': [[library_class:POINTER|<TT>POINTER</TT>]]
* '''9''': [[library_class:NATIVE_ARRAY|<TT>NATIVE_ARRAY</TT>]]<TT>[</TT>[[library_class:CHARACTER|<TT>CHARACTER</TT>]]<TT>]</TT>
* '''10''': [[library_class:INTEGER_16|<TT>INTEGER_16</TT>]]
* '''11''': [[library_class:INTEGER_64|<TT>INTEGER_64</TT>]]
* ''[what about the various kinds of REAL?]''

So it is likely that the root class of the system may have the identifier '''12'''. But do not rely on that too much (before all the changes to INTEGERs, it was '''11''').
</div>

<div id="note3">3. The compiler will do its best not to change the identifiers uselessly. The <TT>.id</TT> file is loaded at the beginning of the compilation process, and saved again at its end. But [[clean]], for example, erases that file.</div>

<div id="note4">4. You can find the definition of these structures in the <TT>SmartEiffel/sys/runtime/c/no_check.h</TT> file.</div>

<div id="note5">5. The exception is when an exception is raised: in that case, part of the stack is allocated onto the heap before the <TT>longjmp</TT>. </div>

← Older revision		Revision as of 08:48, 3 July 2016
Line 11:		Line 11:
	=== Description ===		=== Description ===

−	~~LibertyEiffel~~ generates one unique identifying number for each active type in the Eiffel code<sup>[[Generated c code#note1\|1]]</sup>. A lot of symbols in the generated C code depend on that identifier.	+	Liberty Eiffel generates one unique identifying number for each active type in the Eiffel code<sup>[[Generated c code#note1\|1]]</sup>. A lot of symbols in the generated C code depend on that identifier.

	'''Don't depend on those identifiers!''' The mangling table is only valid for one specific compilation of one specific application with one specific compiler version, for one compiler [[compile_to_c]] in one specific version and libraries in one specific version... We do not guarantee the stability of these identifiers.		'''Don't depend on those identifiers!''' The mangling table is only valid for one specific compilation of one specific application with one specific compiler version, for one compiler [[compile_to_c]] in one specific version and libraries in one specific version... We do not guarantee the stability of these identifiers.
Line 18:		Line 18:

	* The C type of an Eiffel object is '''T27''';		* The C type of an Eiffel object is '''T27''';
−	* The corresponding C structure is '''struct S27'''; in that structure, the names of the attributes are prefixed with an underscore (there may be some other fields used by ~~LibertyEiffel~~, in particular, the <TT>id</TT> field, which in this case has the value 27). <br> Each reference type can be cast to <TT>T0</TT> (although some reference types may not have the <TT>id</TT> field).	+	* The corresponding C structure is '''struct S27'''; in that structure, the names of the attributes are prefixed with an underscore (there may be some other fields used by Liberty Eiffel, in particular, the <TT>id</TT> field, which in this case has the value 27). <br> Each reference type can be cast to <TT>T0</TT> (although some reference types may not have the <TT>id</TT> field).
	* Each method is called '''r27''method_name''()'''		* Each method is called '''r27''method_name''()'''
	* Each prefix method is called '''r27_px_''method_name''()'''		* Each prefix method is called '''r27_px_''method_name''()'''
Line 198:		Line 198:
	== The dump stack ==		== The dump stack ==

−	'''When not in boost mode''', a stack is managed by the runtime environment generated by ~~LibertyEiffel~~. This stack is displayed when an uncaught exception is raised. It is also used by the debugger [[sedb]].	+	'''When not in boost mode''', a stack is managed by the runtime environment generated by Liberty Eiffel. This stack is displayed when an uncaught exception is raised. It is also used by the debugger [[sedb]].

−	Technically, the ~~LibertyEiffel~~ stack is built upon the native (C) stack. Each stack element is a <TT>se_dump_stack</TT><sup>[[Generated c code#note4\|4]]</sup> usually allocated on the stack<sup>[[Generated c code#note5\|5]]</sup>. It is made up of several parts:	+	Technically, the Liberty Eiffel stack is built upon the native (C) stack. Each stack element is a <TT>se_dump_stack</TT><sup>[[Generated c code#note4\|4]]</sup> usually allocated on the stack<sup>[[Generated c code#note5\|5]]</sup>. It is made up of several parts:

	* a frame descriptor, of type <TT>se_frame_descriptor</TT><sup>[[Generated c code#note4\|4]]</sup> which is a static description of the feature, as follows:		* a frame descriptor, of type <TT>se_frame_descriptor</TT><sup>[[Generated c code#note4\|4]]</sup> which is a static description of the feature, as follows:

← Older revision		Revision as of 19:51, 5 September 2014
Line 1:		Line 1:
−	[[Category:Smarteiffel]]
	*** I have partially updated the examples here: the hello_world.id file was generated by se2.2beta5 and I		*** I have partially updated the examples here: the hello_world.id file was generated by se2.2beta5 and I
	*** have noted some statements that are now obsolete in view of recent compiler changes.		*** have noted some statements that are now obsolete in view of recent compiler changes.
Line 12:		Line 11:
	=== Description ===		=== Description ===

−	~~SmartEiffel~~ generates one unique identifying number for each active type in the Eiffel code<sup>[[Generated c code#note1\|1]]</sup>. A lot of symbols in the generated C code depend on that identifier.	+	LibertyEiffel generates one unique identifying number for each active type in the Eiffel code<sup>[[Generated c code#note1\|1]]</sup>. A lot of symbols in the generated C code depend on that identifier.

−	'''Don't depend on those identifiers!''' The mangling table is only valid for one specific compilation of one specific application with one specific compiler version, for one compiler [[compile_to_c]] in one specific version and libraries in one specific version... We do not guarantee the ~~stabbility~~ of these identifiers.	+	'''Don't depend on those identifiers!''' The mangling table is only valid for one specific compilation of one specific application with one specific compiler version, for one compiler [[compile_to_c]] in one specific version and libraries in one specific version... We do not guarantee the stability of these identifiers.

	If ''27'' is an identifier, then:		If ''27'' is an identifier, then:

	* The C type of an Eiffel object is '''T27''';		* The C type of an Eiffel object is '''T27''';
−	* The corresponding C structure is '''struct S27'''; in that structure, the names of the attributes are prefixed with an underscore (there may be some other fields used by ~~SmartEiffel~~, in particular, the <TT>id</TT> field, which in this case has the value 27). <br> Each reference type can be cast to <TT>T0</TT> (although some reference types may not have the <TT>id</TT> field).	+	* The corresponding C structure is '''struct S27'''; in that structure, the names of the attributes are prefixed with an underscore (there may be some other fields used by LibertyEiffel, in particular, the <TT>id</TT> field, which in this case has the value 27). <br> Each reference type can be cast to <TT>T0</TT> (although some reference types may not have the <TT>id</TT> field).
	* Each method is called '''r27''method_name''()'''		* Each method is called '''r27''method_name''()'''
	* Each prefix method is called '''r27_px_''method_name''()'''		* Each prefix method is called '''r27_px_''method_name''()'''
Line 118:		Line 117:
	OK, now you understand why you cannot use type numbers, but you still want to know what those fields in the mangling table mean (in the <TT>.id</TT> file)>..		OK, now you understand why you cannot use type numbers, but you still want to know what those fields in the mangling table mean (in the <TT>.id</TT> file)>..

−	First, a big caveat. Although it may have been very stable for quite some time now, '''the mangling table coding may change'''! We currently have no plans to change it, and we prefer keeping it the way it is. But once again, we do not commit ourselves to the current representation.	+	First, a big caveat. Although it may have been very stable for quite some time now, '''the mangling table coding may change'''! We currently have no plans to change it, and we prefer keeping it the way it is. But once again: we do not commit ourselves to the current representation.

	Let's look again at the extract of a <TT>.id</TT> file. The part shown covers nearly all the possible cases:		Let's look again at the extract of a <TT>.id</TT> file. The part shown covers nearly all the possible cases:
Line 199:		Line 198:
	== The dump stack ==		== The dump stack ==

−	'''When not in boost mode''', a stack is managed by the runtime environment generated by ~~SmartEiffel~~. This stack is displayed when an uncaught exception is raised. It is also used by the debugger [[sedb]].	+	'''When not in boost mode''', a stack is managed by the runtime environment generated by LibertyEiffel. This stack is displayed when an uncaught exception is raised. It is also used by the debugger [[sedb]].

−	Technically, the ~~SmartEiffel~~ stack is built upon the native (C) stack. Each stack element is a <TT>se_dump_stack</TT><sup>[[Generated c code#note4\|4]]</sup> usually allocated on the stack<sup>[[Generated c code#note5\|5]]</sup>. It is made up of several parts:	+	Technically, the LibertyEiffel stack is built upon the native (C) stack. Each stack element is a <TT>se_dump_stack</TT><sup>[[Generated c code#note4\|4]]</sup> usually allocated on the stack<sup>[[Generated c code#note5\|5]]</sup>. It is made up of several parts:

	* a frame descriptor, of type <TT>se_frame_descriptor</TT><sup>[[Generated c code#note4\|4]]</sup> which is a static description of the feature, as follows:		* a frame descriptor, of type <TT>se_frame_descriptor</TT><sup>[[Generated c code#note4\|4]]</sup> which is a static description of the feature, as follows: