On 12 April 2016 at 22:22, Walter Bright via Digitalmars-d <digitalmars-d@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.