I would create a delegate for the function, and then cast the delegate to int*, and dump some first and second level indirections from that and see what comes out. I e, dump the first 8 words of the address of the delegate, then the first 8 words of each of those words treated as a pointer. Perhaps follow another level, too, just for good measure.

Then try to disassemble each of those dumps (assuming you get valid addresses at all) and see which one looks like good instructions :-)

To get the address of a delegate, create a local variable holding it, with some ints or something you can take the address of around it, and hope that it shows up in the middle on the stack. You can probably do this by just looking at the memory window in the debugger.

jwatte:

I bet you could use unsafe code to do a memory dump of the entire memory image of the executing .NET CLR, and somehow get it back to the PC. Probably through Console.WriteLine() (ugh!) and then take a disassembler to that to see what's going on. Would be very slow. Perhaps an alternative would be to see if Xbox/PC Live! were interoperable, and try to get data out that way, although I think that's not going to work.

I don't see what the problem is with just using the Network API... put them both in a System Link game and away you go... (at 39KB/s), no need to use Console.WriteLine() for that (or screenshots) any more.

jwatte:

I would create a delegate for the function, and then cast the delegate to int*, and dump some first and second level indirections from that and see what comes out. I e, dump the first 8 words of the address of the delegate, then the first 8 words of each of those words treated as a pointer. Perhaps follow another level, too, just for good measure.

Good call, that worked.  You just need three indirections from the delegate pointer on the stack to get the address of the first instruction of the target method.  I still need to figure out the layout of the data structures in the intermediate indirections, but using the first word in each seems to do the trick for both static and instance methods.  The real problem is determining code size.  At the moment I just make a guess of the number of instructions in the function, and keep going until I hit a blr instruction.  If 'blr' is guaranteed to be the last instruction in every method, then it may be possible to just dump until you see 0x4E800020 (the encoding for blr).  This is turning out to be quite educational!

The ref version of Matrix.Multiply comes in at 521 instructions. :)

Once you have some disassembly, you can diassemble a function that calls a delegate (and one that creates a delegate) to figure out the precise calling convention, rather than guessing. Unfortunately, blr can come in the middle of the function, too, for early returns and stuff. Some compilers also hoist things like switch tables to after the main return code. I suppose you can just keep fetching until you run into an address not valid exception :-)

Oh, and please do post more findings such as the Matrix.Multiply instruction count! Although ideally in a new thread, as the poor guy at the top probably isn't being helped so much more in this thread :-)

 

ShawMishrak:

The ref version of Matrix.Multiply comes in at 521 instructions. :)

That's really a lot of instructions for just a matrix multiply where everything is passed on the stack.

jwatte:

Although ideally in a new thread, as the poor guy at the top probably isn't being helped so much more in this thread :-)

So, can anyone create a new thread?  =)