[Mono-dev] memcpy and memset (opcodes, C#, marshaling)
cetin.sert at gmail.com
Mon Mar 26 08:51:36 EDT 2007
I'm totally against the introduction of new mono-only C# keywords. Access to
mentioned function calls should, if really needed, be provided in the form
of a class residing in some mono namespace.
----- Original Message -----
From: "Kornél Pál" <kornelpal at gmail.com>
To: "Miguel de Icaza" <miguel at novell.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Monday, March 26, 2007 2:01 PM
Subject: Re: [Mono-dev] memcpy and memset (opcodes, C#, marshaling)
>> Mono's String class has great managed memcpy and memset methods that
>> internal. cpblk and initblk opcodes map to these two methods when cannot
>> easily inlined. But I know no way to make a C# compiler emit either cpblk
>> 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
__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
>> 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.
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list