'naked' keyword

[Tomas Lindquist Olsen]

On Fri, Jan 2, 2009 at 9:21 AM, Don <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 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20090106/546e02eb/attachment.html>