On Sat, Aug 14, 2010 at 2:56 PM, SK <sk@metrokings.com> wrote:
> Will D try to stay current with new processor instructions or provide just a lowest common denominator?  I notice that newer x86 instructions such as CRC32 and POPCNT are not supported by the inline assembler.
>

Well, this one was certainly a dud.  ;^)  I get the feeling I'm more
down on the metal than most folks on this interesting list.
Can anyone opine about assembler plans?  Some new instructions offer a
meaningful performance boost in the right niche, so I hate to think
the assembler won't expose them.
-steve

On Mon, 16 Aug 2010, SK wrote:

> On Sat, Aug 14, 2010 at 2:56 PM, SK <sk@metrokings.com> wrote:
> > Will D try to stay current with new processor instructions or provide just a lowest common denominator?  I notice that newer x86 instructions such as CRC32 and POPCNT are not supported by the inline assembler.
> >
> 
> Well, this one was certainly a dud.  ;^)  I get the feeling I'm more
> down on the metal than most folks on this interesting list.
> Can anyone opine about assembler plans?  Some new instructions offer a
> meaningful performance boost in the right niche, so I hate to think
> the assembler won't expose them.
> -steve

Please file an enhancement bug report (at a minimum).  Even better would be to take a look at the source and produce a patch adding support for it (iasm.c in the src tree).

Adding new codes shouldn't be terribly difficult, but I've not studied that particular part of the code yet.

Later,
Brad

SK wrote:
> On Sat, Aug 14, 2010 at 2:56 PM, SK <sk@metrokings.com> wrote:
>> Will D try to stay current with new processor instructions or provide
>> just a lowest common denominator?  I notice that newer x86
>> instructions such as CRC32 and POPCNT are not supported by the inline
>> assembler.
>>
> 
> Well, this one was certainly a dud.  ;^)  I get the feeling I'm more
> down on the metal than most folks on this interesting list.
> Can anyone opine about assembler plans?  Some new instructions offer a
> meaningful performance boost in the right niche, so I hate to think
> the assembler won't expose them.

As of a couple years ago, the inline assembler supported all the opcodes. Intel and AMD keep adding them, though. Just file a bug report on the missing ones.

On Mon, Aug 16, 2010 at 7:13 PM, Brad Roberts <braddr@puremagic.com> wrote:
> Please file an enhancement bug report (at a minimum).  Even better would
> be to take a look at the source and produce a patch adding support for it
> (iasm.c in the src tree).
>
> Adding new codes shouldn't be terribly difficult, but I've not studied that particular part of the code yet.
>

Hi Brad, I followed your suggestion and looked at iasm.c, but this file has the backend license.  Code from random contributors complicates copyright -- a problem made much simpler if the relevant files were also under the Artistic/GPL.  Does it makes sense for Digital Mars to "move" the inline assembler to be considered part of the front-end?

>From src/iasm.c
/*
 * Copyright (c) 1992-1999 by Symantec
 * Copyright (c) 1999-2010 by Digital Mars
 * All Rights Reserved
 * http://www.digitalmars.com
 * Written by Mike Cote, John Micco and Walter Bright
 * D version by Walter Bright
 *
 * This source file is made available for personal use
 * only. The license is in /dmd/src/dmd/backendlicense.txt
 * For any other uses, please contact Digital Mars.
 */

SK wrote:
> Hi Brad, I followed your suggestion and looked at iasm.c, but this
> file has the backend license.  Code from random contributors
> complicates copyright -- a problem made much simpler if the relevant
> files were also under the Artistic/GPL.  Does it makes sense for
> Digital Mars to "move" the inline assembler to be considered part of
> the front-end?

It'd have to be re-implemented to do that.