<div class="gmail_quote">On 19 June 2012 23:03, Walter Bright <span dir="ltr"><<a href="mailto:newshound2@digitalmars.com" target="_blank">newshound2@digitalmars.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 6/19/2012 11:57 AM, Iain Buclaw wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
To quote from one of the i386 backend maintainers:<br>
---<br></div><div class="im">
"Does D *really* require a new calling convention?<br>
</div></blockquote>
<br>
No, but the idea was to allow D to innovate on calling conventions without disturbing code that needed to interface with C.<br></blockquote><div><br></div><div>Properly implemented multiple-return-values being the killer app here! Using ALL the argument registers for returning multiple values aswell ;)</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Also does it *really* require naked support?<br></div><div class="im">
I think naked support is a bad idea<br></div><div class="im">
and people who require naked support should be writing an assembly<br>
function wrapper."<br></div>
---<br>
</blockquote>
<br>
Naked support allows people to write max efficient assembler without needing to exit the language and use the (often miserable) standalone assembler.<br></blockquote><div><br></div><div>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...</div>
<div>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.</div>
<div>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).</div><div><br></div><div><br></div><div>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:</div>
<div>  register int x;             // compiler assigns an unused register, promises it will remain resident, error if it can't maintain promise.</div><div>  register int x : rsp;    // x aliases RSP; can now produce a function pre/postable in high level code.</div>
<div>Repeat for the argument registers -> readable, high-level custom calling conventions!</div><div><br></div><div>This would almost entirely eliminate the usefulness of an inline assembler.</div><div>Better yet, this could use the 'new' attribute syntax, which most agree will support arguments:</div>
<div>@register(rsp) int x;</div></div>