[Mono-dev] Mono.Simd Acceleration Attributes

Christophe Guillon christophe.guillon.perso at gmail.com
Fri Nov 7 04:44:53 EST 2008

Hi all,
Looking at the proposal for the Mono.Simd  primitives I'm wondering how the
Mono.Simd.Acceleration attributes and the corresponding Mono.Simd.AccelMode
parameters are useful.
Thus I'm wondering what is the rational of having these attributes defined
and used in the definition of the primitives.

It seems that as soon as the Mono.Simd primitives have a well defined
semantic it is not useful to specify which architecture feature is able to
emulate each of these primitives. I would have expected this to be the
choice of the virtual execution environment.

For instance the add with saturation for the Vector16b type which is defined

public static Vector16b<http://go-mono.com/docs/monodoc.ashx?link=T%3aMono.Simd.Vector16b>

Well, but:
- if my underlying hardware XXX (not SSE2) is able to support efficiently
add with saturation, I do not have to know whether SSE2 also supports it,
the virtual machine for XXX can use the corresponding add with saturation
instruction of XXX at the call sites of AddWithSaturation()   anyway,
- if my underlying hardware features SSE2, the attribute is not useful, the
virtual machine knows the underlying hardware and thus know that a SSE2
instruction is able to emulate this,
- if the attribute is there to restrict the mapping to only SSE2 (and above)
machines, it is an important restriction to the usage of the library.
Imagine as above that I have in the future a hardware support XXX that is
able to do AddWithSaturation on Vector16b; if I want a virtual machine to
execute efficiently this primitive on XXX I would first have to modify the
Mono.Simd library to add the corresponding XXX attribute and modify the
primitives declaration to account for it.

  -- Christophe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081107/3ea296ce/attachment.html 

More information about the Mono-devel-list mailing list