<div class="gmail_quote">On Fri, Jan 2, 2009 at 9:21 AM, Don <span dir="ltr"><<a href="mailto:nospam@nospam.com">nospam@nospam.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Duane Bailey wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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 <br>
</blockquote>
review the problems that the D language presents LLVM.<br></div>
Cool!!!!<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.<br>
</blockquote>
<br></div>
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.<div class="Ih2E3d"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.<br>
<br>
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. <br>
</blockquote>
<br></div>
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:<br>
<br>
void foo() {<br>
asm {<br>
naked;<br>
}<br>
mixin(someasm("EBX")); // becomes asm {mov EAX, EBX; }<br>
asm { ret; }<br>
}<br>
<br>
char [] someasm(char [] c) {<br>
return "asm { mov EAX," ~ c ~"; }";<br>
}<br>
<br>
I see this as crucial functionality since it gives you an unbelievably powerful macro language in the assembler.<div class="Ih2E3d"></div></blockquote><div><br>it should be no problem to merge asm blocks in a function, the only problem is mixing normal dcode in there as well.<br>
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.<br>
<br>*NOTE: naked is not yet 100% implemented in ldc<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
<br>
So, I recommend the following:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
+ Remove the naked keyword as an assembly 'instruction'.<br>
<br>
+ Instate it as a function property, similarly to 'extern (C)'. So you might see the following declaration:<br>
<br>
extern naked void flushIDT() {<br>
mov EAX, [ESP+4]<br>
lidt [EAX]<br>
ret<br>
}<br>
</blockquote>
<br></div>
It doesn't need to part of the function signature, though, does it?<div class="Ih2E3d"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.<br>
</blockquote>
<br></div>
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).<br>
Would that restriction be enough?<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Cheers!<br>
<br>
-Duane<br>
</blockquote>
</blockquote></div>