[Mono-bugs] [Bug 58026][Wis] Changed - Add infrastructure for implementing icalls in IL

[bugzilla-daemon@bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by lupus@ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=58026

--- shadow/58026	2004-05-04 22:25:31.000000000 -0400
+++ shadow/58026.tmp.17468	2004-05-05 06:27:01.000000000 -0400
@@ -86,6 +86,37 @@
 There are a few advantages to this, imho:
 
 1) I am not sure how your solution would play with the interp.
 2) I think the code above is alot cleaner :-).
 3) If one is required to write IL to do this stuff, i highly doubt it
 will be used as often as it can be.
+
+------- Additional Comments From lupus@ximian.com  2004-05-05 06:27 -------
+Zoltan, we currently already optimize get_Rank and a few of the other
+simple icalls. I guess you mean ByteLengthInternal() in this specific
+case, but that is a method which is not so easily expressed in IL code
+(but looking at it it could be optimized and simplified: max_length
+should already be the total number of elements in the array).
+The only issue is with mono_class_array_element_size (), but that
+could be precomputed anyway. With these changes ByteLengthInternal()
+can be implemented with a fairly simple opcode, with:
+ lookup array->vtable->element_class
+ check type is primitive (subtraction and unsigned compare)
+ multiply element_size * max_length
+So this will be pretty fast.
+As a general rule, simple icalls should be implemented like the
+current GETRANK, STRLEN etc. If you look at the implementation of
+OP_ARRAY_RANK in inssel.brg, it looks to me cleaner than the above
+code and it also requires way less processing at JIT time.
+Some other icalls could be implemented with metadata/marshal.c, mostly
+because as soon as it is non-trivial (and hence implementable with the
+general rule), you'll need more data than can be expressed in IL code.
+The third implementation idea which I tinkered with for a bit could be
+used for some very specialized icalls that are very performance
+critical, like String.Equals, the string copy stuff etc.
+Basically we would have processor and arch-specific snippets of
+assembly (this is an optimization, archs won't need to write this
+code): when present, the JIT will simply skip all the compilation and
+just use this code (we need it's length and a few other bits for
+unwinding, so we won't generally be able to use C implementations for
+these).
+Ben: we are not going to expose those internal data structures.