Dynamic Binding - Revision history

Manus at 10:14, 11 April 2007

2007-04-11T10:14:00Z

← Older revision		Revision as of 10:14, 11 April 2007
Line 1:		Line 1:
	[[Category:Compiler]]		[[Category:Compiler]]
	{{~~Warning\|'''Warning''': Article under development~~}}		{{UnderConstruction}}

	===Introduction===		===Introduction===

Konradm at 07:41, 17 January 2007

2007-01-17T07:41:38Z

← Older revision		Revision as of 07:41, 17 January 2007
Line 112:		Line 112:
	\|-valign="top" -halign="center"		\|-valign="top" -halign="center"
	\|		\|
	[[Image:ABCecall.~~jpg~~]]		[[Image:ABCecall.png]]
	\|		\|
	\|}		\|}
Line 136:		Line 136:
	\|-valign="top" -halign="center"		\|-valign="top" -halign="center"
	\|		\|
	[[Image:ABCeorg.~~jpg~~]]		[[Image:ABCeorg.png]]
	\|		\|
	\|}		\|}
Line 148:		Line 148:
	\|-valign="top" -halign="center"		\|-valign="top" -halign="center"
	\|		\|
	[[Image:ABCDescTab.~~jpg~~]]		[[Image:ABCDescTab.png]]

	\|		\|

Konradm: /* Some Ids */

2007-01-17T07:41:17Z

Some Ids

← Older revision		Revision as of 07:41, 17 January 2007
Line 21:		Line 21:
	{\|border="0" cellpadding="0" cellspacing="0" align="center"		{\|border="0" cellpadding="0" cellspacing="0" align="center"
	\|-valign="top" -halign="center"		\|-valign="top" -halign="center"
	\|[[Image:DynamicBindingABCExample.~~jpg~~]]		\|[[Image:DynamicBindingABCExample.png]]
	\|}		\|}

Konradm: /* Calculating the real_body_id */

2007-01-16T13:04:21Z

Calculating the real_body_id

← Older revision		Revision as of 13:04, 16 January 2007
Line 186:		Line 186:
	\|		\|
	\|}		\|}


	~~Dynamic binding in workbench mode is optimized for flexibility and not for speed (See [[Melting Ice Technology]].~~

Konradm: /* Calculating the rout_info */

2007-01-16T13:03:39Z

Calculating the rout_info

← Older revision		Revision as of 13:03, 16 January 2007
Line 140:		Line 140:
	\|}		\|}

	The red and blue color have the same meaning as in the previous picture.		The red and blue color have the same meaning as in the previous picture.

	====Calculating the real_body_id====		====Calculating the real_body_id====

Konradm: /* Calculating the real_body_id */

2007-01-16T13:03:02Z

Calculating the real_body_id

← Older revision		Revision as of 13:03, 16 January 2007
Line 167:		Line 167:
	Example: When doing the look up for the read call and the class_id (10) and offset (0) are already known the real_body_id is found with the following piece of C code:		Example: When doing the look up for the read call and the class_id (10) and offset (0) are already known the real_body_id is found with the following piece of C code:

			{\|border="0" cellpadding="2" cellspacing="0" align="center"
			\|-valign="top" -halign="center"
			\|
			<code>[c]
	desc_tab [10] [50] [0]		desc_tab [10] [50] [0]
			</code>
			\|
			\|}

			For the blue call with class_id 11 and offset zero the look up looks like:

			{\|border="0" cellpadding="2" cellspacing="0" align="center"
			\|-valign="top" -halign="center"
			\|
			<code>[c]
			desc_tab [11] [55] [0]
			</code>
			\|
			\|}


	Dynamic binding in workbench mode is optimized for flexibility and not for speed (See [[Melting Ice Technology]].		Dynamic binding in workbench mode is optimized for flexibility and not for speed (See [[Melting Ice Technology]].

Konradm: /* Calculating the real_body_id */

2007-01-16T13:00:54Z

Calculating the real_body_id

← Older revision		Revision as of 13:00, 16 January 2007
Line 157:		Line 157:
	Example: The table for class B has four entries, one for each of the types B [INTEGER], B [STRING], C [INTEGER] and C [STRING] with ids 52, 53, 54 and 55.		Example: The table for class B has four entries, one for each of the types B [INTEGER], B [STRING], C [INTEGER] and C [STRING] with ids 52, 53, 54 and 55.

	~~To recap, every~~ yellow table belongs to a certain origin. And so it comes, that every entry of such a yellow table references an other table with as many entries as the origin introduces features.		Every yellow table belongs to a certain origin. And so it comes, that every entry of such a yellow table references an other table with as many entries as the origin introduces features.

	These gray tables are indexed by the offset (~~see~~ rout_info) and finally yield the real_body_id.		These gray tables are indexed by the offset (of rout_info) and finally yield the real_body_id.

	Example: The entries of the yellow table for class B (with class_id 11) reference tables with one entry, since class B only introduces one feature (feature h).		Example: The entries of the yellow table for class B (with class_id 11) reference tables with one entry, since class B only introduces one feature (feature h).

	~~For all the entries of~~ the ~~yellow tables there~~ is ~~a third table (~~shown in ~~gray). The entries of the yellow table of a given origin (of the white table)~~		The exact resolution for the read call and blue call is again shown in their corresponding color.
	~~They have an every for each feature introduced by~~ their ~~origin~~.

			Example: When doing the look up for the read call and the class_id (10) and offset (0) are already known the real_body_id is found with the following piece of C code:

			desc_tab [10] [50] [0]


	~~The real work is done in step three so it is explained first.~~

Konradm: /* Calculating the real_body_id */

2007-01-16T12:54:23Z

Calculating the real_body_id

← Older revision		Revision as of 12:54, 16 January 2007
Line 153:		Line 153:
	\|}		\|}

	For every origin in the system there is a second table (shown in yellow) that has an entry for every type that is an instantiation either the origin itself or of a descendant.		For every origin in the system there is a second table (shown in yellow) that has an entry for every type that is an instantiation of either the origin itself or of a descendant.

	Example: The table for class B has four entries, one for each of the types B [INTEGER], B [STRING], C [INTEGER] and C [STRING] with ids 52, 53, 54 and 55.		Example: The table for class B has four entries, one for each of the types B [INTEGER], B [STRING], C [INTEGER] and C [STRING] with ids 52, 53, 54 and 55.

			To recap, every yellow table belongs to a certain origin. And so it comes, that every entry of such a yellow table references an other table with as many entries as the origin introduces features.

			These gray tables are indexed by the offset (see rout_info) and finally yield the real_body_id.

			Example: The entries of the yellow table for class B (with class_id 11) reference tables with one entry, since class B only introduces one feature (feature h).

			For all the entries of the yellow tables there is a third table (shown in gray). The entries of the yellow table of a given origin (of the white table)
			They have an every for each feature introduced by their origin.

Konradm: /* Calculating the real_body_id */

2007-01-16T11:18:26Z

Calculating the real_body_id

← Older revision		Revision as of 11:18, 16 January 2007
Line 143:		Line 143:

	====Calculating the real_body_id====		====Calculating the real_body_id====
			Central to the dynamic binding in workbench mode is the desc_tab. For the ABC system this table looks like this:

	~~The real work is done~~ in ~~step three so it~~ is ~~explained first~~.

	{\|border="0" cellpadding="2" cellspacing="0" align="center"		{\|border="0" cellpadding="2" cellspacing="0" align="center"
Line 154:		Line 152:
	\|		\|
	\|}		\|}

			For every origin in the system there is a second table (shown in yellow) that has an entry for every type that is an instantiation either the origin itself or of a descendant.

			Example: The table for class B has four entries, one for each of the types B [INTEGER], B [STRING], C [INTEGER] and C [STRING] with ids 52, 53, 54 and 55.



			The real work is done in step three so it is explained first.




	Dynamic binding in workbench mode is optimized for flexibility and not for speed (See [[Melting Ice Technology]].		Dynamic binding in workbench mode is optimized for flexibility and not for speed (See [[Melting Ice Technology]].

Konradm: /* Calculating the rout_info */

2007-01-16T10:53:16Z

Calculating the rout_info

← Older revision		Revision as of 10:53, 16 January 2007
Line 142:		Line 142:
	The red and blue color have the same meaning as in the previous picture.		The red and blue color have the same meaning as in the previous picture.

			====Calculating the real_body_id====