Any usable SIMD implementation?

[Iain Buclaw via Digitalmars-d]

On 13 April 2016 at 07:59, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 4/12/2016 4:35 PM, Iain Buclaw via Digitalmars-d wrote:
>> - 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).
>
>
> DMD's iasm uses the opcodes as written in the Intel CPU manuals. There is no
> MULL opcode in the manual, so no MULL in DMD's iasm. It figures out which
> opcode by looking at the operands, using the Intel CPU manual as a guide.
>
> It's a bit of a pain as there are a lot of special cases, but the end result
> is pretty straightforward if you're using the Intel CPU manual as a
> reference guide.
>

My only point was that in GDC, the translation of opcodes to machine
code is done in two steps by two separate processes, rather than one.
DMD is proof that the benefit of having unified syntax is a big win.

>> - 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.
>
>
> I understand that GDC has special challenges because it writes to an
> assembler rather than direct to object code. I understand it is not easy to
> replicate DMD's iasm functionality. Which is why I haven't given you a hard
> time about it :-) and it is not terribly important.
>
> But core.cpuid needs to be made to work in GDC, whatever it takes to do so.
>

Indeed, it's been on my TODO list for a long time, among many other things. :-)

> ----
>
> Personally, I strongly dislike the fact that the GAS syntax is the reverse
> of Intel's. It isn't just GAS, it's GDB and everything else. It just sux. It
> makes my eyeballs hurt looking at it. It's like giving me a car with the
> brake and gas pedals reversed. Nothing but accidents result :-) And I don't
> like that they use different opcodes than the Intel manuals. That just sux,
> too.
>

Like riding a backwards bicycle. :-)

https://www.youtube.com/watch?v=MFzDaBzBlL0

> But I know that the GNU world is stuck with that, and GDC should behave like
> the rest of GCC.
>

Yeah, and I'm glad that you do.