<div class="gmail_quote">On Wed, Jan 7, 2009 at 12:41 PM, 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;">
Tomas Lindquist Olsen 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><div></div><div class="Wj3C7c">
On Fri, Jan 2, 2009 at 9:21 AM, Don <<a href="mailto:nospam@nospam.com" target="_blank">nospam@nospam.com</a> <mailto:<a href="mailto:nospam@nospam.com" target="_blank">nospam@nospam.com</a>>> wrote:<br>
<br>
Duane Bailey wrote:<br>
<br>
I am currently porting LDC to PowerPC and, hopefully,<br>
eventually the POWER and CELL platforms as well. The first bit<br>
requires me to port the inline assembler, allowing me to<br>
<br>
review the problems that the D language presents LLVM.<br>
Cool!!!!<br>
<br>
<br>
<br>
LLVM is not a toy virtual machine. It is, perhaps, the most<br>
flexible and powerful compiler toolset ever, spanning massive<br>
numbers of computing platforms. It even supports (in a limited<br>
manner) the PIC16 platform, require insane constraints: there<br>
are no registers, memory can only be accessed in one byte<br>
amounts, and some processors only have 35 instructions.<br>
<br>
<br>
That's pretty impressive. I'm currently using a PIC, but it's so<br>
memory-limited it's hard to believe D ever being workable on it.<br>
<br>
<br>
LLVM, however, is not able to do everything. For some reason,<br>
its current API does not allow the restriction of prologue and<br>
epilogue generation; to allow so would not make sense: the<br>
language itself depends on the maintenance of the stack. The<br>
only way to establish a 'naked' function in *c* is to 'omit' the<br>
frame pointer—technically not allowed in most OS's ABIs—and then<br>
explicitly avoid using all variables (and hence the stack), OR<br>
to use top level assembly to write the assembly yourself.<br>
<br>
Now, neither of those options are really what D should use, but<br>
I have some other recommendations based on this. 'naked'<br>
functions should not be allowed to have any D, except to<br>
reference arguments passed to it. In other words, it should not<br>
touch the stack. in fact, there's really no reason at all to<br>
have the 'naked' statement in the inline assembly. It's not a<br>
property of the assembly, it's a property of the *function*. And<br>
because D code should not be used (except perhaps for macros?),<br>
'naked' functions should intrinsically be assembly functions.<br>
<br>
<br>
I agree with this. Mixing run-time D and naked asm doesn't make any<br>
sense. But, something which I've done which is _very_ useful is to<br>
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<br>
unbelievably powerful macro language in the assembler.<br>
<br>
<br></div></div><div class="Ih2E3d">
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<br>
</div></blockquote>
<br>
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?</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
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.<div class="Ih2E3d">
</div></blockquote><div><br>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)<br>
<br>Consider taking the address of a parameter that is passed by value in EAX, this will allocate a stack slot...<br><br></div></div>Hope I was a bit more clear this time :)<br>