On 2013-12-21 11:14, Russel Winder wrote:

> Inline assembly language is a huge disadvantage in many (most?) case.

I don't know. Would you like to move all the current inline assembly in druntime to their own files? I don't use assembly myself but it seems convenient to have support for inline assembly for use cases like in druntime. Most inline assembly in drunimte only consists of 1-10 lines of code.

-- 
/Jacob Carlborg

On Sat, 2013-12-21 at 14:03 +0100, Jacob Carlborg wrote:
> On 2013-12-21 11:14, Russel Winder wrote:
> 
> > Inline assembly language is a huge disadvantage in many (most?) case.
> 
> I don't know. Would you like to move all the current inline assembly in druntime to their own files? I don't use assembly myself but it seems convenient to have support for inline assembly for use cases like in druntime. Most inline assembly in drunimte only consists of 1-10 lines of code.

Inline assembly means you have to have the assembly code for each supported platform in the code with all the conditionals to the compiler. Having separate files is often much easier to manage and to build from.

OK so D only support Intel processors just now so only one inline assembly type, but this is part of the problem not the solution.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 21.12.2013 14:03, Jacob Carlborg wrote:
> On 2013-12-21 11:14, Russel Winder wrote:
>
>> Inline assembly language is a huge disadvantage in many (most?) case.
>
> I don't know. Would you like to move all the current inline assembly in
> druntime to their own files? I don't use assembly myself but it seems
> convenient to have support for inline assembly for use cases like in
> druntime. Most inline assembly in drunimte only consists of 1-10 lines
> of code.
>

Personally I rather use powerful external macro assemblers like NASM/MASM than inline assemblers, as I mentioned a few times here.

Specially since most inline assemblers I used tend to be rather limited in comparison.


--
Paulo

> Inline assembly means you have to have the assembly code for each
> supported platform in the code with all the conditionals to the
> compiler. Having separate files is often much easier to manage and to
> build from.
>

No, that's a completely orthogonal issue: You can easily have architecture dependent code in separate modules.

The point of an inline assembler is that the compiler knows things like field offsets and so can provide useful features no external assembler can. It can also inline the assembler code eliminating any function call overhead. Your ignorance doesn't make these things misfeatures.

On 12/21/2013 6:44 AM, Russel Winder wrote:
> Inline assembly means you have to have the assembly code for each
> supported platform in the code with all the conditionals to the
> compiler. Having separate files is often much easier to manage and to
> build from.

You can still put D inline assembly in separate files. What you don't need is an assembler.

> OK so D only support Intel processors just now so only one inline
> assembly type, but this is part of the problem not the solution.

There is no case where D's support for intel inline assembler is worse than forcing you to use a separate assembler.

>
> Personally I rather use powerful external macro assemblers like NASM/MASM than inline assemblers, as I mentioned a few times here.
>
> Specially since most inline assemblers I used tend to be rather limited in comparison.

Actually DMD might be the most powerful macro assembler out there:

    import std.stdio;
    import std.conv;

    int test(int Result)()
    {
        asm { naked; }
        mixin(r"
        asm
        {
            mov EAX, " ~ to!string(Result) ~ r";
            ret;
        }"
        );
    }

    void main()
    {
        writefln("%s", test!4());
        writefln("%s", test!5());
    }

On Saturday, 21 December 2013 at 10:14:32 UTC, Russel Winder wrote:
> C, C++, Go, D have the advantage of using separate files with the
> assembly code in.
>
> Inline assembly language is a huge disadvantage in many (most?) case.

Depends, it allows you to add support for locking-mechanisms/SIMD instructions/etc before getting language support. You want that inlined and the compiler to do register assignment. I believe LLVM just pass it on to the assembler almost verbatim. If done right you wouldn't need to update the compiler in order to add support for new instructions/trap mechanisms, updating an external assembler should be sufficient, so it is a future-proof technology. I think inline asm wrapped up as inline functions is pretty neat, in the rare case where you need it (some rare CPUs have built in true random() functionality for instance).

On Sat, 2013-12-21 at 20:18 +0100, Araq wrote:
[…]
> The point of an inline assembler is that the compiler knows things like field offsets and so can provide useful features no external assembler can. It can also inline the assembler code eliminating any function call overhead. Your ignorance doesn't make these things misfeatures.

and your lack of courteous commentary makes debate with you a waste of both our time.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sat, 2013-12-21 at 11:29 -0800, Walter Bright wrote:
> On 12/21/2013 6:44 AM, Russel Winder wrote:
> > Inline assembly means you have to have the assembly code for each supported platform in the code with all the conditionals to the compiler. Having separate files is often much easier to manage and to build from.
> 
> You can still put D inline assembly in separate files. What you don't need is an assembler.

But this implies the D compiler has to be able to handle Intel, Sparc, AMD, ARM, ARM Thumb, Atmel, … Certainly compiler code generators have to know things about the target, but does this necessarily include the ability to do inline?

D compile-time decision making certainly changes the game compared to C/C++, but the problem is that D only really supports Intel just now so we don't really have data on how complicated things are for multiple backends.

Of course having exited the embedded space (8051, Atmel, etc.) I am now
just Intel/AMD/ARM oriented.

> > OK so D only support Intel processors just now so only one inline assembly type, but this is part of the problem not the solution.
> 
> There is no case where D's support for intel inline assembler is worse than forcing you to use a separate assembler.

My point is really that D needs to support ARM pdq to have any chance of
getting traction in an increasingly bi-partisan (Intel/AMD and ARM)
rather than monopolistic (Intel/AMD) data centre.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sun, 2013-12-22 at 04:48 +0000, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= […]
> Depends, it allows you to add support for locking-mechanisms/SIMD instructions/etc before getting language support. You want that inlined and the compiler to do register assignment. I believe LLVM just pass it on to the assembler almost verbatim. If done right you wouldn't need to update the compiler in order to add support for new instructions/trap mechanisms, updating an external assembler should be sufficient, so it is a future-proof technology. I think inline asm wrapped up as inline functions is pretty neat, in the rare case where you need it (some rare CPUs have built in true random() functionality for instance).

Historically, and anecdotally, I found that as soon as the assembly language was a function, it was better as a separate entity, that inline assembler only worked for accessing a processor instruction that the code generator could not generate. So I think you are making this same point, cf. SIMD instructions at the bleeding edge.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder