Any usable SIMD implementation?

[Iain Buclaw via Digitalmars-d]

On 12 April 2016 at 22:22, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 4/12/2016 9:53 AM, Marco Leise wrote:
>> Your look on GCC (and LLVM) may be a bit biased. First of all
>> you don't need to tell it exactly which registers to use. A
>> rough classification is enough and gives the compiler a good
>> idea of where calculations should be stored upon arrival at
>> the asm statement. You can be specific down to the register
>> name or let the backend chose freely with "rm" (= any register
>> or memory).
>> An example: We have a variable x that is computed inside a
>> function followed by an asm block that multiplies it with
>> something else. Typically you would "MOV EAX, [x]" to load x
>> into the register that the MUL instruction expects. With
>> extended assemblers you can be declarative about that and just
>> state that x is needed in EAX as an input. You drop the MOV
>> from the asm block and let the compiler figure out in its
>> codegen, how x will end up in EAX. That's a step FORWARD in
>> usability.
>
>
> It's a step backwards because I can't just say "MUL EAX". I have to tell GCC
> what register the result gets put in. This is, to my mind, ridiculous. GCC's
> inline assembler apparently has no knowledge of what the opcodes actually
> do.
>

asm { "mul eax"; } - That wasn't so difficult. :-)

I don't know if D data and calling functions from DMD-IASM is safe (it
is in GDC extended IASM).  But I have always chosen the path that
requires the least amount of maintenance burden/overhead.  And I'm
sorry to say that supporting GCC-style extended assembler both comes
for free (handling is managed by the middle-end), and requires no
platform-specific support on the language implementation side.

However, I have always considered comparing the two a bit like apples
and oranges.  DMD compiles to object code, so it makes sense to me
that you have an entire assembler embedded in.  However GDC compiles
to assembly, and I expect that GNU As will know a lot more about what
opcodes actually do on, say a Motorola 68k, than the poor mans parser
I would be able to write.

There were a lot of challenges supporting DMD-style IASM, all
non-existent in DMD.  Drawing a list off the top of my head - I'll let
you decide whether IASM is pro or con in this area, but again bear in
mind that DMD doesn't have to deal with calling an external assembler.

- What dialect am I writing in? (Do I emit mul or mull? eax or %eax?)
- Some opcodes in IASM have a different name in the assembler (Emitted
fdivrp as fdivp, and fdivp as fdivrp. No idea why but I recall
std.math didn't work without the translation).
- Some opcodes are actually directives in disguise (db, ds, dw, ...)
- Frame-relative addressing/displacement of a symbol before the
backend has decided where incoming parameters will land is a good way
to get hit by a truck.
- GCC backend doesn't support naked functions on x86.
- Or even in the sense that DMD supports naked functions where there
is support (only plain text assembler allowed)
- Want to support ARM? MIPS? PPC?  At the time when GDC supported
DMD-style IASM for x86, the implementation was over 3000 LOC, adding
platform support just looked like an unmanageable nightmare.