Agent Calls - Revision history

Conaclos: Object test

2014-02-01T18:46:34Z

Object test

Conaclos: Replace obsolete syntax

2014-02-01T18:44:55Z

Replace obsolete syntax

Manus: Added subcategory

2008-01-28T21:25:06Z

Added subcategory

Manus at 18:43, 30 May 2007

2007-05-30T18:43:54Z

Manus: Restored page content

2007-05-30T18:43:30Z

Restored page content

Show changes

Konradm at 16:10, 24 January 2007

2007-01-24T16:10:43Z

Show changes

Konradm: /* Strategy for optimizing dotnet Agent Calls */

2007-01-22T14:24:14Z

‎Strategy for optimizing dotnet Agent Calls

Konradm: /* Melted agent creation */

2007-01-22T14:23:51Z

‎Melted agent creation

Konradm: /* Agent calls in final code */

2007-01-22T14:14:49Z

‎Agent calls in final code

Konradm: /* Wrapper functions in final mode */

2007-01-22T14:13:36Z

‎Wrapper functions in final mode

@@ Line 355: / Line 355: @@
          -- Call function with `operands' as last set.
      do
-         if attached rout_disp.invoke (target_object, internal_operands) as al_last_result then
+         if attached {RESULT_TYPE} rout_disp.invoke (target_object, internal_operands) as al_last_result then
              last_result := al_last_result
          end

@@ Line 351: / Line 351: @@
 Compared to the Classic version, dotnet Agent Calls are slow. The a short look at feature apply of class FUNCTION shows why:
-<code>[eiffel,N]
+<e>
 apply
          -- Call function with `operands' as last set.
      do
-         last_result ?= rout_disp.invoke (target_object, internal_operands)
+         if attached rout_disp.invoke (target_object, internal_operands) as al_last_result then
      end
-</code>
+</e>
 The actual call is done through reflection. Additionally, in dotnet the two major optimizations are missing:

← Older revision		Revision as of 21:25, 28 January 2008
Line 1:		Line 1:
	[[Category:Compiler]]		[[Category:Compiler]]
		+	[[Category:Code Generation]]
	{{Warning\|Article under development}}		{{Warning\|Article under development}}

@@ Line 1: / Line 1: @@
 [[Category:Compiler]]
-{{Warning|'''Warning''': Article under development}}
+{{Warning|Article under development}}
 ====Introduction====

← Older revision		Revision as of 14:24, 22 January 2007
Line 370:		Line 370:
	* A second delegate type, that requires one Tuple (closed arguments) and all the open arguments as arguments.		* A second delegate type, that requires one Tuple (closed arguments) and all the open arguments as arguments.
	* A second static method which conforms to the second delegate type and does the ordering and '''agent callee''' call.		* A second static method which conforms to the second delegate type and does the ordering and '''agent callee''' call.
−
−	~~The class ROUTINE will contain a reference of type~~

@@ Line 331: / Line 331: @@
 The name of the wrapper for the encapsulated closed arguments always starts with one '_', whereas the other one starts with two underlines.
-== Melted agent creation ==
+====Melted agent creator====
-Of course it is possible that the agent creation is melted and hence there is no wrapper. For this situation the Eiffel runtime provides two generic wrapper functions:
+Of course it is possible that the '''agent creation''' is melted and hence there is no wrapper. For this situation the Eiffel runtime provides two generic wrapper functions:
 <code>[c, N]
@@ Line 345: / Line 345: @@
 These functions calculate the '''agent callee''' with the static type id and a feature id. Furthermore the reordering of open and closed arguments has to be done at agent call time with help of the open_map.
 == Strategy for optimizing dotnet Agent Calls ==

← Older revision		Revision as of 14:14, 22 January 2007
Line 348:		Line 348:


−	~~==== Agent calls in final code ====~~
−	~~In finalized mode the compiler further optimizes '''agent calls''' if the following conditions hold:~~
−	*The call is qualified and the target of the call is of type FUNCTION, PROCEDURE or PREDICATE.
−	*The '''agent call''' is done with a call to item or call.

−	~~In this case, the compiler generates a direct call to the wrapper function.~~
−
−	~~Quite often an '''agent call''' is done with a manifest tuple:~~
−
−	~~<code>[eiffel,N]~~
−	~~caller (f: FUNCTION [ANY, TUPLE [INTEGER, STRING], STRING]): STRING~~
−	do
−	~~Result := f.item ([1, "hello"])~~
−	~~end~~
−	~~</code>~~
−
−	This calls are further optimized by not generating the tuple but passing the elements of the tuple directly to the wrapper function. Thats why we need the second wrapper function in finalized mode. Feature caller is translated to the following c-code:
−
−	~~<code>[c,N]~~
−	~~EIF_REFERENCE Fbnoo0v (EIF_REFERENCE Current, EIF_REFERENCE arg1)~~
−	{
−	~~GTCX~~
−	~~EIF_REFERENCE tp1 = NULL;~~
−
−	~~tp1 = (FUNCTION_CAST(EIF_REFERENCE, (EIF_POINTER, EIF_REFERENCE, EIF_INTEGER_32, EIF_BOOLEAN)) (EIF_POINTER )(~~
−	~~arg1+ @PTROFF(5,4,0,3,0,0)))(~~
−	(EIF_POINTER )(arg1+ @PTROFF(5,4,0,3,0,1)),
−	(EIF_REFERENCE )(arg1 + @REFACS(1)), ((EIF_INTEGER_32) 1L), (EIF_BOOLEAN) 1);
−
−	~~return (EIF_REFERENCE)tp1;~~
−	}
−	~~</code>~~

	== Strategy for optimizing dotnet Agent Calls ==		== Strategy for optimizing dotnet Agent Calls ==

@@ Line 287: / Line 287: @@
 {|border="0" cellpadding="2" cellspacing="0" align="center"
 |-valign="top" -halign="center"
 <eiffel>
 agent c.f (?, 1, ?)
@@ Line 294: / Line 295: @@
 {|border="0" cellpadding="2" cellspacing="0" align="center"
 |-valign="top" -halign="center"
 <c>
 EIF_REFERENCE _fAaatpmf_2_4 (
@@ Line 308: / Line 310: @@
                    open [2].element.rarg);
+}
+|
 EIF_REFERENCE __fAaatpmf_2_4 (
     EIF_REFERENCE (*f_ptr)(EIF_REFERENCE,