www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - More Front End Vector Support

reply "Iain Buclaw" <ibuclaw gdcproject.org> writes:
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
Jul 04 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jul 04 2012
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
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';
Jul 05 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jul 05 2012
parent "Mehrdad" <wfunction hotmail.com> writes:
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. ;)
Jul 05 2012