'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