'naked' keyword

[Don]

Tomas Lindquist Olsen wrote:
> On Wed, Jan 7, 2009 at 12:41 PM, Don <nospam at nospam.com 
> <mailto:nospam at nospam.com>> wrote:
> 
>     Tomas Lindquist Olsen wrote:
> 
>         On Fri, Jan 2, 2009 at 9:21 AM, Don <nospam at nospam.com
>         <mailto:nospam at nospam.com> <mailto:nospam at nospam.com
>         <mailto:nospam at nospam.com>>> wrote:
> 
>            Duane Bailey wrote:
> 
>                I am currently porting LDC  to PowerPC and, hopefully,
>                eventually the POWER and CELL platforms as well. The
>         first bit
>                requires me to port the inline assembler, allowing me to
> 
>            review the problems that the D language presents LLVM.
>            Cool!!!!
> 
> 
> 
>                LLVM is not a toy virtual machine. It is, perhaps, the most
>                flexible and powerful compiler toolset ever, spanning massive
>                numbers of computing platforms. It even supports (in a
>         limited
>                manner) the PIC16 platform, require insane constraints: there
>                are no registers, memory can only be accessed in one byte
>                amounts, and some processors only have 35 instructions.
> 
> 
>            That's pretty impressive. I'm currently using a PIC, but it's so
>            memory-limited it's hard to believe D ever being workable on it.
> 
> 
>                LLVM, however, is not able to do everything. For some reason,
>                its current API does not allow the restriction of
>         prologue and
>                epilogue generation; to allow so would not make sense:  the
>                language itself depends on the maintenance of the stack. The
>                only way to establish a 'naked' function in *c* is to
>         'omit' the
>                frame pointer—technically not allowed in most OS's
>         ABIs—and then
>                explicitly avoid using all variables (and hence the
>         stack), OR
>                to use top level assembly to write the assembly yourself.
> 
>                Now, neither of those options are really what D should
>         use, but
>                I have some other recommendations based on this. 'naked'
>                functions should not be allowed to have any D, except to
>                reference arguments passed to it. In other words, it
>         should not
>                touch the stack. in fact, there's really no reason at all to
>                have the 'naked' statement in the inline assembly. It's
>         not  a
>                property of the assembly, it's a property of the
>         *function*. And
>                because D code should not be used (except perhaps for
>         macros?),
>                'naked' functions should intrinsically be assembly functions.
> 
> 
>            I agree with this. Mixing run-time D and naked asm doesn't
>         make any
>            sense. But, something which I've done which is _very_ useful
>         is to
>            mixin CTFE functions. You get something like:
> 
>            void foo() {
>             asm {
>             naked;
>             }
>             mixin(someasm("EBX")); // becomes asm {mov EAX, EBX; }
>             asm { ret; }
>            }
> 
>            char [] someasm(char [] c) {
>             return "asm { mov EAX," ~ c ~"; }";
>            }
> 
>            I see this as crucial functionality since it gives you an
>            unbelievably powerful macro language in the assembler.
> 
> 
>         it should be no problem to merge asm blocks in a function, the
>         only problem is mixing normal dcode in there as well.
>         I've decided to make this an error in LDC since there is no
>         sensible way to implement D-style function parameters *and* make
>         sure the function really is naked. function parameters in llvm
>         are ssa values, so you manually have to alloca a stack slot and
>         copy the argument into that to make sure the parameter is an l-value
> 
> 
>     I don't understand those last two sentences. Does it mean that you'd
>     only allow 'naked' on extern(C) functions? Or only that mixing D and
>     naked asm would be illegal?
> 
> 
> Sorry, I can see I was a bit unclear. All I meant was that I can't 
> sensibly implement naked and allow arbitrary D code in the mix as well, 
> it's either or... naked should eventually work fine for any calling 
> conventions, it'll just bail out with an error if you try and mix D in 
> between the asm blocks.
>  
> 
> 
>     By the way, in DMD, mixing naked and D code only works if you put a
>     "push EBP; mov   EBP, ESP;" before the first bit of D code, which
>     isn't documented anywhere as far as I know; and I don't know how to
>     make inner functions work. So it's pretty much unspecified behaviour
>     right now.
> 
> 
> nested delegates inside naked functions pose some problems, since they 
> will modify the stack frame as well (like allowing full access to 
> function parameters, like taking the address of one, which was what I 
> was trying to talk about in my reply)
> 
> Consider taking the address of a parameter that is passed by value in 
> EAX, this will allocate a stack slot...
> 
> Hope I was a bit more clear this time :)

Yes. And that's awesome! It means my existing Bigint naked asm code in 
Tango should work on LDC without modification.