June 19, 2012
On 19 June 2012 23:03, Walter Bright <newshound2@digitalmars.com> wrote:

> On 6/19/2012 11:57 AM, Iain Buclaw wrote:
>
>> To quote from one of the i386 backend maintainers:
>> ---
>> "Does D *really* require a new calling convention?
>>
>
> No, but the idea was to allow D to innovate on calling conventions without disturbing code that needed to interface with C.
>

Properly implemented multiple-return-values being the killer app here! Using ALL the argument registers for returning multiple values aswell ;)


 Also does it *really* require naked support?
>> I think naked support is a bad idea
>> and people who require naked support should be writing an assembly
>> function wrapper."
>> ---
>>
>
> Naked support allows people to write max efficient assembler without needing to exit the language and use the (often miserable) standalone assembler.
>

I find a thorough suite of architecture intrinsics are usually the fastest
and cleanest way to the best possible code, although 'naked' may be handy
in this circumstance too...
If a function is written from intrinsics, then it can inline and better
adapt to the calling context. It's very common that you use asm to write
super-efficient micro-function (memory copying/compression, linear algebra,
matrix routines, DSPs, etc), which are classic candidates for being inlined.
So I maintain, naked is useful, but asm is not (assuming you have a high
level way to address registers like the stack pointer directly).


Thinking more about the implications of removing the inline asm, what would
REALLY roxors, would be a keyword to insist a variable is represented by a
register, and by extension, to associate it with a specific register:
  register int x;             // compiler assigns an unused register,
promises it will remain resident, error if it can't maintain promise.
  register int x : rsp;    // x aliases RSP; can now produce a function
pre/postable in high level code.
Repeat for the argument registers -> readable, high-level custom calling
conventions!

This would almost entirely eliminate the usefulness of an inline assembler.
Better yet, this could use the 'new' attribute syntax, which most agree
will support arguments:
@register(rsp) int x;


June 19, 2012
Le 19/06/2012 22:08, Iain Buclaw a écrit :
>  From what I gathered from further discussion, it made sense for
> embedded platforms, such as ARM, but not x86.

It has proven to be useful to me, not only for performances reasons, but also for low level manipulations.

It don't see what make ARM that different on regard to inline assembly capabilities.
June 19, 2012
On 19 June 2012 23:59, deadalnix <deadalnix@gmail.com> wrote:

> Le 19/06/2012 22:08, Iain Buclaw a écrit :
>
>   From what I gathered from further discussion, it made sense for
>> embedded platforms, such as ARM, but not x86.
>>
>
> It has proven to be useful to me, not only for performances reasons, but also for low level manipulations.
>
> It don't see what make ARM that different on regard to inline assembly capabilities.
>

If you had the register alias feature I described above, would you be ale
to write such low-level manipulations using intrinsics?
I think I would be able to rewrite all x86 asm blocks I've ever written
using that feature.

ARM and PPC both have unique features relating to their branch control and
branch prediction that x86 doesn't have. Sadly, all high level languages
COMPLETELY overlook such features when designing high level expressions,
because they are traditionally designed for x86 first.
A thorough set of intrinsics can allow access to these features though,
although since they're related to branch control/conditional execution, it
feels clumsy, since you lose the feeling of structured code; ie, no scoped
if blocks, loop constructs, etc,  if you have to use intrinsics to generate
conditions or masks.

ARM is the most common architecture on earth now. It would be nice if D were able to take better advantage of the architecture.


June 19, 2012
Le 19/06/2012 23:22, Manu a écrit :
> If you had the register alias feature I described above, would you be
> ale to write such low-level manipulations using intrinsics?
> I think I would be able to rewrite all x86 asm blocks I've ever written
> using that feature.
>

No, I couldn't. Such code involved stack manipulations that cannot be emulated by such a feature.

> ARM and PPC both have unique features relating to their branch control
> and branch prediction that x86 doesn't have. Sadly, all high level
> languages COMPLETELY overlook such features when designing high level
> expressions, because they are traditionally designed for x86 first.
> A thorough set of intrinsics can allow access to these features though,
> although since they're related to branch control/conditional execution,
> it feels clumsy, since you lose the feeling of structured code; ie, no
> scoped if blocks, loop constructs, etc,  if you have to use intrinsics
> to generate conditions or masks.
>
> ARM is the most common architecture on earth now. It would be nice if D
> were able to take better advantage of the architecture.


Even if it is true, you don't address the actual interrogation. The discussion was about the naked functionality, and some advanced that naked can be useful on ARM, but not on x86. The specificities of ARM you mention here don't explain that point. (I don't want to pronounce myself on PPC as I have no experience on it).
June 19, 2012
On 6/19/2012 1:08 PM, Iain Buclaw wrote:
> On Tuesday, 19 June 2012 at 20:04:12 UTC, Walter Bright wrote:
>> Naked support allows people to write max efficient assembler without needing
>> to exit the language and use the (often miserable) standalone assembler.
>
>  From what I gathered from further discussion, it made sense for embedded
> platforms, such as ARM, but not x86.

I find occasion to use it now and then on x86.
June 19, 2012
On 6/19/2012 1:36 PM, bearophile wrote:
>> No, but the idea was to allow D to innovate on calling
>> conventions without disturbing code that needed to
>> interface with C.
>
> The idea is nice, but ideas aren't enough. Where are the benchmarks that show a
> performance improvement over the C calling convention? And even if such
> improvement is present, is it worth it in the face of people that don't want to
> add it to GCC?

GDC can certainly define its D calling convention to match GCC's. It's an "implementation defined" thing, not a language defined one.

June 19, 2012
On 6/19/2012 1:58 PM, Manu wrote:

> I find a thorough suite of architecture intrinsics are usually the fastest and
> cleanest way to the best possible code, although 'naked' may be handy in this
> circumstance too...

Do a grep for "naked" across the druntime library sources. For example, its use in druntime/src/rt/alloca.d, where it is very much needed, as alloca() is one of those "magic" functions.

> If a function is written from intrinsics, then it can inline and better adapt to
> the calling context. It's very common that you use asm to write super-efficient
> micro-function (memory copying/compression, linear algebra, matrix routines,
> DSPs, etc), which are classic candidates for being inlined.
> So I maintain, naked is useful, but asm is not (assuming you have a high level
> way to address registers like the stack pointer directly).

Do a grep for "asm" across the druntime library sources. Can you justify all of that with some other scheme?



> Thinking more about the implications of removing the inline asm, what would
> REALLY roxors, would be a keyword to insist a variable is represented by a
> register, and by extension, to associate it with a specific register:
>    register int x;             // compiler assigns an unused register, promises
> it will remain resident, error if it can't maintain promise.
>    register int x : rsp;    // x aliases RSP; can now produce a function
> pre/postable in high level code.
> Repeat for the argument registers -> readable, high-level custom calling
> conventions!

This was a failure in C.


> This would almost entirely eliminate the usefulness of an inline assembler.
> Better yet, this could use the 'new' attribute syntax, which most agree will
> support arguments:
> @register(rsp) int x;

Some C compilers did have such pseudo-register abilities. It was a failure in practice.

I really don't understand preferring all these rather convoluted enhancements to avoid something simple and straightforward like the inline assembler. The use of IA in the D runtime library, for example, has been quite successful.

For example, consider this bit from druntime/src/rt/lifetime.d:

-------------------------------------------------------------------
    auto isshared = ti.classinfo is TypeInfo_Shared.classinfo;
    auto bic = !isshared ? __getBlkInfo((*p).ptr) : null;
    auto info = bic ? *bic : gc_query((*p).ptr);
    auto size = ti.next.tsize();
    version (D_InlineAsm_X86)
    {
        size_t reqsize = void;

        asm
        {
            mov EAX, newcapacity;
            mul EAX, size;
            mov reqsize, EAX;
            jc  Loverflow;
        }
    }
    else
    {
        size_t reqsize = size * newcapacity;

        if (newcapacity > 0 && reqsize / newcapacity != size)
            goto Loverflow;
    }

    // step 2, get the actual "allocated" size.  If the allocated size does not
    // match what we expect, then we will need to reallocate anyways.

    // TODO: this probably isn't correct for shared arrays
    size_t curallocsize = void;
    size_t curcapacity = void;
    size_t offset = void;
    size_t arraypad = void;
----------------------------------------------
June 19, 2012
On 20 June 2012 00:41, deadalnix <deadalnix@gmail.com> wrote:

> Le 19/06/2012 23:22, Manu a écrit :
>
>  If you had the register alias feature I described above, would you be
>> ale to write such low-level manipulations using intrinsics?
>> I think I would be able to rewrite all x86 asm blocks I've ever written
>> using that feature.
>>
>>
> No, I couldn't. Such code involved stack manipulations that cannot be emulated by such a feature.


Really?
Can you elaborate? Give me an example that couldn't be done with register
aliasing and intrinsics?



>  Even if it is true, you don't address the actual interrogation. The
> discussion was about the naked functionality, and some advanced that naked
> can be useful on ARM, but not on x86. The specificities of ARM you mention
> here don't explain that point. (I don't want to pronounce myself on PPC as
> I have no experience on it).
>

It seemed to me your comment was about inline assembly, not about naked functions:

It don't see what make ARM that different on regard to inline assembly
> capabilities.
>

I was just listing some reasons I think the inline assembler is more useful
to ARM + PPC code than it is to x86 code.
Naked is what it is... and it's occasionally useful in very low level
situations.


June 19, 2012
Le 19/06/2012 23:54, Manu a écrit :
> On 20 June 2012 00:41, deadalnix <deadalnix@gmail.com
> <mailto:deadalnix@gmail.com>> wrote:
>
>     Le 19/06/2012 23:22, Manu a écrit :
>
>         If you had the register alias feature I described above, would
>         you be
>         ale to write such low-level manipulations using intrinsics?
>         I think I would be able to rewrite all x86 asm blocks I've ever
>         written
>         using that feature.
>
>
>     No, I couldn't. Such code involved stack manipulations that cannot
>     be emulated by such a feature.
>
>
> Really?
> Can you elaborate? Give me an example that couldn't be done with
> register aliasing and intrinsics?
>

Walter gave you examples. You'll find many others in druntime.

Here is something I wrote recently that use this again : http://www.deadalnix.me/2012/03/24/get-an-exception-from-a-segfault-on-linux-x86-and-x86_64-using-some-black-magic/
June 19, 2012
On 19-06-2012 22:56, Trass3r wrote:
>> Plus, gcc asm syntax is horrible, and DMD's is really nice.
>
> yep, AT&T vs. Intel syntax :)

Please be informed that GCC inline asm supports Intel syntax...

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org