[Mono-dev] memcpy and memset (opcodes, C#, marshaling)
Kornél Pál
kornelpal at gmail.com
Mon Mar 26 08:01:17 EDT 2007
Hi,
>> 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
enough.
> 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.
Kornél
More information about the Mono-devel-list
mailing list