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

[Cetin Sert]

Hi,

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.

Best Regards,
Cetin Sert

----- 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)


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

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list