[Mono-dev] memcpy and memset (opcodes, C#, marshaling)

Kornél Pál kornelpal at gmail.com
Mon Mar 26 08:01:17 EDT 2007


>> Mono's String class has great managed memcpy and memset methods that
>> internal. cpblk and initblk opcodes map to these two methods when cannot 
>> be
>> easily inlined. But I know no way to make a C# compiler emit either cpblk 
>> or
>> initblk using my own pointer parameters.
> Which ones do you have in mind?

Actually both of them (cpblk and initblk as well) I just wasn't clear 

> Extending the C# compiler to support a special syntax for this would be
> trivial and incompatible with CSC.   But I guess that internally there
> is no point in limiting ourselves to what CSC can do.

This sounds to be a great idea because this would not limit the binary 
compatibility or the source compatibility otherwise.

I propose these new C# keywords (unsafe context required for IntPtr versions 
as well):
__memcpy (IntPtr/void* dest, IntPtr/void* src, int size) -> unaligned.cpblk
__memset (IntPtr/void* dest, int val, int len) -> unaligned.initblk

> What would you like to use these for?

Using optimized memcpy and memmove is vital if you want to efficiently copy 
or initialize data. Sometimes I need that in my onw programs and I have seen 
some places in our Class Library that could benefit from memcpy and/or 
memmove. (I can't currently recall such a situation.)

>> System.Runtime.InteropServices.Marshal currently uses internal calls for
>> methods I think are not doing any managed-to-unmanaged marshaling at all:
>> Copy, Read... and Write... methods. Could these methods be implemented 
>> using
>> enirely managed code (inline implemenation or a managed-to-managed)?
> I think most of the internal calls there could be moved to managed code.
> Some might be using unmanaged code as the performance would be higher.
> Some other routines could be completely done without internal calls
> (some string conversion helper routines).

Thanks for pointing out this as well. Note that the above __memcpy and 
__memset are for use outside corlib because corlib can use the internal 
string.memcpy directly that I think would speed up Marshal.Copy for example.


More information about the Mono-devel-list mailing list