digitalmars.D - More Front End Vector Support
- Iain Buclaw (13/13) Jul 04 2012 Morning,
- Walter Bright (4/13) Jul 04 2012 64 bit MMX extensions for x86 are, as far as I can tell, quite obsolete....
- Iain Buclaw (10/35) Jul 05 2012 Fair enough. Only asked as if we do Y and Z, why not X? GCC backend
- Walter Bright (7/12) Jul 05 2012 I don't think D should do emulation - it should give a compiler error on...
- Mehrdad (2/8) Jul 05 2012 It's called a warning. ;)
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
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
On 4 July 2012 22:43, Walter Bright <newshound2 digitalmars.com> wrote:On 7/4/2012 7:19 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. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';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 05 2012
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
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