[Mono-dev] Incoming changes to Mono.Simd
john.hurliman at intel.com
Wed Dec 3 12:12:24 EST 2008
> -----Original Message-----
> From: mono-devel-list-bounces at lists.ximian.com
> [mailto:mono-devel-list- bounces at lists.ximian.com] On Behalf Of
> Rodrigo Kumpera
> Sent: Wednesday, December 03, 2008 8:19 AM
> To: mono-devel-list at lists.ximian.com
> Subject: [Mono-dev] Incoming changes to Mono.Simd
> After some discussions with Mark we decided to do a few changes to
> Mono.Simd and it would be really nice to have some feedback from
> everyone on them.
> One of the motivation is that the current C# of Mono.Simd is not
> endianess safe and doesn't work as expected on platforms such as ppc.
> The other is to advance the quality of the API.
> The first change is to remove byte oriented methods from all vector
> types that don't work on byte quantities.
> Right now the only method is ExtractByteMask which is mostly used
> together with compare ops and will be replaced with proper operator
> The second change is actually a clarification, Mono.Simd have some
> arch dependent methods such as casting between vector types that are
> endian unsafe. The alternative would be to define those methods to
> have little-endian semantics and, latter on, when we add support to a
> big- endian arch revert this decision.
> The last one is a call if extension methods should be used or not.
> Extensions methods will make coding with vector types quite a bit
> simpler as a lot less typing will be needed. For example,
> "Vector8us.AddWithSaturation (a, b)" would become "a.AddWithSaturation
> (b)". Right now we already expose some extension methods for
> interoperability with arrays.
> There are two issues with extension methods, first that it requires C#
> 3.0 and .NET 3.5 if you want your code to compile for it.
> AFAIK this is no big deal as those methods would still be available
> under C# 2.0. The second issue is a limitation of the C# language,
> which require extension methods to be defined of sealed classes. This
> would mean that code written against mono 2.2 version of Mono.Simd
> might not compiler with newer versions.
> Keeping both versions of the methods is an option as well, but I'm not
> very keen on the extra bloat imposed. Either way, I would love to rear
> feedback from people evaluating or using Mono.Simd.
I think more extension methods would be a nice addition to Mono.Simd. I'm pretty sure everyone who is using Mono.Simd at this point is prepared for bugs, quirks, and breaking API changes.
More information about the Mono-devel-list