Morning,

I've noticed that 256bit vector support has been added to the D frontend during the development stages of 2.060 whilst was looking around in druntime core.

https://github.com/D-Programming-Language/druntime/commit/fcc91588e89fa48b699f0efe0cdfb8c23e2bb4ae


Is anyone willing to object if I raise a pull request to add 64bit Vector support in the D frontend too for architectures that support? This includes i386/x86_64 using MMX extensions, and ARM using NEON extensions.

Not sure how well DMD would cope with the type in it's backend though, but can always reject it in its backend with an error.


Regards
Iain

On 7/4/2012 7:19 AM, Iain Buclaw wrote:
> Morning,
>
> I've noticed that 256bit vector support has been added to the D frontend during
> the development stages of 2.060 whilst was looking around in druntime core.
>
> https://github.com/D-Programming-Language/druntime/commit/fcc91588e89fa48b699f0efe0cdfb8c23e2bb4ae
>
>
>
> Is anyone willing to object if I raise a pull request to add 64bit Vector
> support in the D frontend too for architectures that support? This includes
> i386/x86_64 using MMX extensions, and ARM using NEON extensions.
>
> Not sure how well DMD would cope with the type in it's backend though, but can
> always reject it in its backend with an error.

64 bit MMX extensions for x86 are, as far as I can tell, quite obsolete. The CPUs support those instructions for backwards compatibility, but I cannot see any reason for D to add new support for it.

On 4 July 2012 22:43, Walter Bright <newshound2@digitalmars.com> wrote:
> On 7/4/2012 7:19 AM, Iain Buclaw wrote:
>>
>> Morning,
>>
>> I've noticed that 256bit vector support has been added to the D frontend
>> during
>> the development stages of 2.060 whilst was looking around in druntime
>> core.
>>
>>
>> https://github.com/D-Programming-Language/druntime/commit/fcc91588e89fa48b699f0efe0cdfb8c23e2bb4ae
>>
>>
>>
>> Is anyone willing to object if I raise a pull request to add 64bit Vector
>> support in the D frontend too for architectures that support? This
>> includes
>> i386/x86_64 using MMX extensions, and ARM using NEON extensions.
>>
>> Not sure how well DMD would cope with the type in it's backend though, but
>> can
>> always reject it in its backend with an error.
>
>
> 64 bit MMX extensions for x86 are, as far as I can tell, quite obsolete. The CPUs support those instructions for backwards compatibility, but I cannot see any reason for D to add new support for it.
>
>

Fair enough.  Only asked as if we do Y and Z, why not X?  GCC backend already supported the use of __vector[N] sizes long before D support was added, but then again only less than of a handful of architectures actually __support__ vector operations (as I said, I think only MMX and NEON would benefit) - the rest just slowly emulate it.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 7/5/2012 12:55 AM, Iain Buclaw wrote:
> Fair enough.  Only asked as if we do Y and Z, why not X?  GCC backend
> already supported the use of __vector[N] sizes long before D support
> was added, but then again only less than of a handful of architectures
> actually __support__ vector operations (as I said, I think only MMX
> and NEON would benefit) - the rest just slowly emulate it.

I don't think D should do emulation - it should give a compiler error on vector sizes and operations that are not supported.

The reason is the user may not expect the (very) slow emulation, and gets no indication of when it happens. By giving a compiler error on them, the user has the opportunity to decide what to do about it.

After all, the only reason he is even using vector ops is for performance.

On Thursday, 5 July 2012 at 22:28:21 UTC, Walter Bright wrote:
> I don't think D should do emulation - it should give a compiler error on vector sizes and operations that are not supported.
>
> The reason is the user may not expect the (very) slow emulation, and gets no indication of when it happens. By giving a compiler error on them, the user has the opportunity to decide what to do about it.


It's called a warning. ;)