Several thoughts - keeping in mind that, though I've done IBM S/360, Zilog Z80, Motorola 6809, 68K, 6805, DEC PDP-11, and VAX-11 assembly language, I've never touched Intel x86:

SSE?  SSE2?  3DNow?  From a purely practical perspective, these are some of the more compelling reasons to use the assembler at all, since there are no compiler features to access them.  (You can target D's native double float type at SSE2 "scalar" instructions - and this would be a good idea - but you probably wouldn't touch the "packed" instructions.)

The semantics of the "$" special identifier: it should refer to the *current* instruction, not the *following* instruction.  "jmp $" should be an infinite loop.  Or does Intel specify $ that way?  They're unique if so.

I think I'd add to the language spec that the inline assembler is standardised, but an implementation may omit it - else you're going to have a great deal of trouble with "dfront."

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net  (personal)

"Richard Krehbiel" <rich@kastle.com> wrote in message news:a5invb$tcv$1@digitaldaemon.com...
> SSE?  SSE2?  3DNow?  From a purely practical perspective, these are some
of
> the more compelling reasons to use the assembler at all, since there are
no
> compiler features to access them.  (You can target D's native double float type at SSE2 "scalar" instructions - and this would be a good idea - but
you
> probably wouldn't touch the "packed" instructions.)

Yeah, I should add the extended instructions. I just wanted to make sure the basic ones worked.

> The semantics of the "$" special identifier: it should refer to the *current* instruction, not the *following* instruction.  "jmp $" should be an infinite loop.  Or does Intel specify $ that way?  They're unique if
so.

That's the way it's usually done with the x86.

> I think I'd add to the language spec that the inline assembler is standardised, but an implementation may omit it - else you're going to
have
> a great deal of trouble with "dfront."

dfront isn't going to support inline assembler, so I do need to fix that.

"Walter" <walter@digitalmars.com> wrote in message news:a5j64b$145f$1@digitaldaemon.com...

> > The semantics of the "$" special identifier: it should refer to the *current* instruction, not the *following* instruction.  "jmp $" should
be
> > an infinite loop.  Or does Intel specify $ that way?  They're unique if
> so.
>
> That's the way it's usually done with the x86.

I'm not sure for MASM/TASM (didn't use 'em), but NASM specifies
$ as current instruction.

> > I think I'd add to the language spec that the inline assembler is standardised, but an implementation may omit it - else you're going to
> have
> > a great deal of trouble with "dfront."
>
> dfront isn't going to support inline assembler, so I do need to fix that.

Maybe something like "the implementation should either support
asm-blocks according to the specification for a specific architecture,
or stop compilation, displaying an error, 'inline assembler not supported'"?

"Richard Krehbiel" <rich@kastle.com> wrote in message news:a5invb$tcv$1@digitaldaemon.com...
> SSE?  SSE2?  3DNow?  From a purely practical perspective, these are some
of
> the more compelling reasons to use the assembler at all, since there are
no
> compiler features to access them.  (You can target D's native double float type at SSE2 "scalar" instructions - and this would be a good idea - but
you
> probably wouldn't touch the "packed" instructions.)

Ok, the SSE and SSE2 instructions are now implemented in the inline assembler.

www.digitalmars.com/dmdalpha.zip

"Walter" <walter@digitalmars.com> wrote in message news:a64ppe$rud$1@digitaldaemon.com...

> www.digitalmars.com/dmdalpha.zip

I believe the correct URL is ftp://ftp.digitalmars.com/dmdalpha.zip -
at least that's where I've got it (and your link brought me
to the "resource not found" page).

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a68nq1$6im$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a64ppe$rud$1@digitaldaemon.com...
>
> > www.digitalmars.com/dmdalpha.zip
>
> I believe the correct URL is ftp://ftp.digitalmars.com/dmdalpha.zip -
> at least that's where I've got it (and your link brought me
> to the "resource not found" page).

You're correct. Thanks!