'naked' keyword

Don nospam at nospam.com
Wed Jan 7 03:41:49 PST 2009


Tomas Lindquist Olsen wrote:
> On Fri, Jan 2, 2009 at 9:21 AM, Don <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?

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.

, I could probably come up with
> some more reasons, but I think this is sufficient reason to simply drop 
> that (ill-defined) feature.
> 
> *NOTE: naked is not yet 100% implemented in ldc
>  
> 
> 
> 
>     So, I recommend the following:
> 
> 
>         + Remove the naked keyword as an assembly 'instruction'.
> 
>         + Instate it as a function property, similarly to 'extern (C)'.
>         So you might see the following declaration:
> 
>            extern naked void flushIDT() {
>                mov EAX, [ESP+4]
>                lidt [EAX]
>                ret
>            }
> 
> 
>     It doesn't need to part of the function signature, though, does it?
> 
> 
>         Though, if the assembly is implicit, it might be better to
>         rename the keyword 'asm' or something like that to make it
>         clearer. Anyway, these changes will, in my humble opinion, make
>         the language cleaner and my life easier because I can simply
>         declare this function by myself.
> 
> 
>     Because of what I wrote above, I think this removes too much
>     functionality. I think it would be quite reasonable, though, to make
>     non-asm code generation illegal inside a naked function. BTW this
>     probably includes contracts (at present, contracts don't work for
>     naked functions even in DMD).
>     Would that restriction be enough?
> 
> 
> 
>         Cheers!
> 
>         -Duane
> 



More information about the Digitalmars-d mailing list