[Mono-dev] simd version patch

Jerry Maine - KF5ADY crashfourit at gmail.com
Sun Jan 17 01:53:17 EST 2010


I really like your idea (except the part of the hybrid three bits part,
I will explain that later) and I'm going to rework the patch to
implement it.

In addition, it puts simd_version on a 32 bit boundry in the struct so
there should be no padding if we changed it from 8 bit to 32 bit member.

The reason for me not liking the hybrid bit idea is keeping the bit
arraignments the same here as in AccelMode. Manly to keep things simple
for other people look at it and port the simd framework to other platforms.

But, after the NEON bit there is room for one more simd version using
this idea so we don't have to worry about that at the moment. ;)

Oh, the changes in mini.h / mini-x86.c / mini-amd64.c are needed because
I was moving simd_version from a bit index marker to a bit map to
correspond directly with AccelMode enum in C#.


Rodrigo Kumpera wrote:
> The changes in mini.h / mini-x86.c / mini-amd64.c are not needed. They
> make no difference at all.
>
> Are you sure that all those intrinsics are not supported by neon? It
> would be better to first check if
> the changes are needed first.
>
> The change to the SimdIntrinsc struct increase it's size by 7 bytes,
> with is quite significant given
> its current size is 6. We can change it to be something like:
>
> typedef struct {
> guint16 name;
> guint16 opcode;
> guint8 simd_version;
> guint8 simd_emit_mode : 4;
> guint8 flags : 4;
> } SimdIntrinsc;
>
> Which keeps its size the same and gives space for a NEON bit. In case
> we need more bits, we
> just switch to a hybrid 3 bits sse level + 5 boolean bits. Your patch
> is really not acceptable since
> it required 3 bytes align padding between simd_emit_mode
> and simd_version_flags.
>
>
>
> On Sat, Jan 16, 2010 at 6:38 PM, Jerry Maine - KF5ADY
> <crashfourit at gmail.com <mailto:crashfourit at gmail.com>> wrote:
>
>     Here is a patch to update the runtime simd version tests so that it
>     would be easier and less hackish to implement ports beyond x86/amd64
>     (like arm and altavic).
>
>     Comments? Questions?
>
>     Jerry
>
>     _______________________________________________
>     Mono-devel-list mailing list
>     Mono-devel-list at lists.ximian.com
>     <mailto:Mono-devel-list at lists.ximian.com>
>     http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100117/4e7fc38c/attachment.html 


More information about the Mono-devel-list mailing list