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.
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.
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. 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
}
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.
Cheers!
-Duane
