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;