digitalmars.D - 'naked' keyword
- Duane Bailey (14/14) Jan 01 2009 I am currently porting LDC to PowerPC and, hopefully, eventually the PO...
- bearophile (15/26) Jan 02 2009 I agree. putting "naked" as function attribute seems more correct.
- Duane Bailey (4/5) Jan 02 2009 The problem is, the 'naked' keyword remove the prologue and epilogue, wh...
- Don (28/50) Jan 02 2009 review the problems that the D language presents LLVM.
- Duane Bailey (2/8) Jan 02 2009 Hmm, that makes sense.
- Tomas Lindquist Olsen (75/75) Jan 06 2009 Content-Disposition: inline
- Don (9/128) Jan 07 2009 I don't understand those last two sentences. Does it mean that you'd
- Tomas Lindquist Olsen (81/81) Jan 07 2009 Content-Disposition: inline
- Sean Kelly (2/2) Jan 07 2009 Um... perhaps next time don't base64 encode the message.
- Denis Koroskin (2/4) Jan 07 2009 I have no problem reading his message. It's just PHP News Reader (pnews)...
- Don (3/126) Jan 07 2009 Yes. And that's awesome! It means my existing Bigint naked asm code in
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
Jan 01 2009
Duane Bailey:+ 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 }I agree. putting "naked" as function attribute seems more correct. As they say: "Wisdom begins by calling things by their right names." Putting back the asm{} is a compromise syntax, useful to remove a special case from one of the stages of the compiler: naked void flushIDT() { asm { mov EAX, [ESP+4] lidt [EAX] ret } }except to reference arguments passed to it. In other words, it should not touch the stack.< And because D code should not be used (except perhaps for macros?),<I don't fully understand what you say. From my very limited experiments with naked functions I think I may enjoy to add some I/O into naked functions: to be able to define new variables before the asm and to copy registers into some variable before the final return. What I am asking here may make useless the "naked" attribute, in such case please ignore what I have said here. Bye, bearophile
Jan 02 2009
Duane Bailey <bailey.d.r gmail.com> bearophile Wrote:From my very limited experiments with naked functions I think I may enjoy to add some I/O into naked functions: to be able to define new variables before the asm and to copy registers into some variable before the final return. What I am asking here may make useless the "naked" attribute, in such case please ignore what I have said here.The problem is, the 'naked' keyword remove the prologue and epilogue, which set up the stack frame, i.e. allocates space for variables. So any D code used in a naked function must A) either not use any stack space, a tricky proposition, or B) wait until a bit of assembly does the prologue itself. Cheers! -Duane
Jan 02 2009
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 toreview 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. 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
Jan 02 2009
Don Wrote: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?Hmm, that makes sense.
Jan 02 2009
Content-Disposition: inline T24gRnJpLCBKYW4gMiwgMjAwOSBhdCA5OjIxIEFNLCBEb24gPG5vc3BhbUBub3NwYW0uY29tPiB3 cm90ZToKCj4gRHVhbmUgQmFpbGV5IHdyb3RlOgo+Cj4+IEkgYW0gY3VycmVudGx5IHBvcnRpbmcg TERDICB0byBQb3dlclBDIGFuZCwgaG9wZWZ1bGx5LCBldmVudHVhbGx5IHRoZQo+PiBQT1dFUiBh bmQgQ0VMTCBwbGF0Zm9ybXMgYXMgd2VsbC4gVGhlIGZpcnN0IGJpdCByZXF1aXJlcyBtZSB0byBw b3J0IHRoZQo+PiBpbmxpbmUgYXNzZW1ibGVyLCBhbGxvd2luZyBtZSB0bwo+Pgo+IHJldmlldyB0 aGUgcHJvYmxlbXMgdGhhdCB0aGUgRCBsYW5ndWFnZSBwcmVzZW50cyBMTFZNLgo+IENvb2whISEh Cj4KPgo+PiBMTFZNIGlzIG5vdCBhIHRveSB2aXJ0dWFsIG1hY2hpbmUuIEl0IGlzLCBwZXJoYXBz LCB0aGUgbW9zdCBmbGV4aWJsZSBhbmQKPj4gcG93ZXJmdWwgY29tcGlsZXIgdG9vbHNldCBldmVy LCBzcGFubmluZyBtYXNzaXZlIG51bWJlcnMgb2YgY29tcHV0aW5nCj4+IHBsYXRmb3Jtcy4gSXQg ZXZlbiBzdXBwb3J0cyAoaW4gYSBsaW1pdGVkIG1hbm5lcikgdGhlIFBJQzE2IHBsYXRmb3JtLAo+ PiByZXF1aXJlIGluc2FuZSBjb25zdHJhaW50czogdGhlcmUgYXJlIG5vIHJlZ2lzdGVycywgbWVt b3J5IGNhbiBvbmx5IGJlCj4+IGFjY2Vzc2VkIGluIG9uZSBieXRlIGFtb3VudHMsIGFuZCBzb21l IHByb2Nlc3NvcnMgb25seSBoYXZlIDM1IGluc3RydWN0aW9ucy4KPj4KPgo+IFRoYXQncyBwcmV0 dHkgaW1wcmVzc2l2ZS4gSSdtIGN1cnJlbnRseSB1c2luZyBhIFBJQywgYnV0IGl0J3Mgc28KPiBt ZW1vcnktbGltaXRlZCBpdCdzIGhhcmQgdG8gYmVsaWV2ZSBEIGV2ZXIgYmVpbmcgd29ya2FibGUg b24gaXQuCj4KPj4KPj4gTExWTSwgaG93ZXZlciwgaXMgbm90IGFibGUgdG8gZG8gZXZlcnl0aGlu Zy4gRm9yIHNvbWUgcmVhc29uLCBpdHMgY3VycmVudAo+PiBBUEkgZG9lcyBub3QgYWxsb3cgdGhl IHJlc3RyaWN0aW9uIG9mIHByb2xvZ3VlIGFuZCBlcGlsb2d1ZSBnZW5lcmF0aW9uOyB0bwo+PiBh bGxvdyBzbyB3b3VsZCBub3QgbWFrZSBzZW5zZTogIHRoZSBsYW5ndWFnZSBpdHNlbGYgZGVwZW5k cyBvbiB0aGUKPj4gbWFpbnRlbmFuY2Ugb2YgdGhlIHN0YWNrLiBUaGUgb25seSB3YXkgdG8gZXN0 YWJsaXNoIGEgJ25ha2VkJyBmdW5jdGlvbiBpbgo+PiAqYyogaXMgdG8gJ29taXQnIHRoZSBmcmFt ZSBwb2ludGVy4oCUdGVjaG5pY2FsbHkgbm90IGFsbG93ZWQgaW4gbW9zdCBPUydzCj4+IEFCSXPi gJRhbmQgdGhlbiBleHBsaWNpdGx5IGF2b2lkIHVzaW5nIGFsbCB2YXJpYWJsZXMgKGFuZCBoZW5j ZSB0aGUgc3RhY2spLCBPUgo+PiB0byB1c2UgdG9wIGxldmVsIGFzc2VtYmx5IHRvIHdyaXRlIHRo ZSBhc3NlbWJseSB5b3Vyc2VsZi4KPj4KPj4gTm93LCBuZWl0aGVyIG9mIHRob3NlIG9wdGlvbnMg YXJlIHJlYWxseSB3aGF0IEQgc2hvdWxkIHVzZSwgYnV0IEkgaGF2ZQo+PiBzb21lIG90aGVyIHJl Y29tbWVuZGF0aW9ucyBiYXNlZCBvbiB0aGlzLiAnbmFrZWQnIGZ1bmN0aW9ucyBzaG91bGQgbm90 IGJlCj4+IGFsbG93ZWQgdG8gaGF2ZSBhbnkgRCwgZXhjZXB0IHRvIHJlZmVyZW5jZSBhcmd1bWVu dHMgcGFzc2VkIHRvIGl0LiBJbiBvdGhlcgo+PiB3b3JkcywgaXQgc2hvdWxkIG5vdCB0b3VjaCB0 aGUgc3RhY2suIGluIGZhY3QsIHRoZXJlJ3MgcmVhbGx5IG5vIHJlYXNvbiBhdAo+PiBhbGwgdG8g aGF2ZSB0aGUgJ25ha2VkJyBzdGF0ZW1lbnQgaW4gdGhlIGlubGluZSBhc3NlbWJseS4gSXQncyBu b3QgIGEKPj4gcHJvcGVydHkgb2YgdGhlIGFzc2VtYmx5LCBpdCdzIGEgcHJvcGVydHkgb2YgdGhl ICpmdW5jdGlvbiouIEFuZCBiZWNhdXNlIEQKPj4gY29kZSBzaG91bGQgbm90IGJlIHVzZWQgKGV4 Y2VwdCBwZXJoYXBzIGZvciBtYWNyb3M/KSwgJ25ha2VkJyBmdW5jdGlvbnMKPj4gc2hvdWxkIGlu dHJpbnNpY2FsbHkgYmUgYXNzZW1ibHkgZnVuY3Rpb25zLgo+Pgo+Cj4gSSBhZ3JlZSB3aXRoIHRo aXMuIE1peGluZyBydW4tdGltZSBEIGFuZCBuYWtlZCBhc20gZG9lc24ndCBtYWtlIGFueSBzZW5z ZS4KPiBCdXQsIHNvbWV0aGluZyB3aGljaCBJJ3ZlIGRvbmUgd2hpY2ggaXMgX3ZlcnlfIHVzZWZ1 bCBpcyB0byBtaXhpbiBDVEZFCj4gZnVuY3Rpb25zLiBZb3UgZ2V0IHNvbWV0aGluZyBsaWtlOgo+ Cj4gdm9pZCBmb28oKSB7Cj4gIGFzbSB7Cj4gIG5ha2VkOwo+ICB9Cj4gIG1peGluKHNvbWVhc20o IkVCWCIpKTsgLy8gYmVjb21lcyBhc20ge21vdiBFQVgsIEVCWDsgfQo+ICBhc20geyByZXQ7IH0K PiB9Cj4KPiBjaGFyIFtdIHNvbWVhc20oY2hhciBbXSBjKSB7Cj4gIHJldHVybiAiYXNtIHsgbW92 IEVBWCwiIH4gYyB+IjsgfSI7Cj4gfQo+Cj4gSSBzZWUgdGhpcyBhcyBjcnVjaWFsIGZ1bmN0aW9u YWxpdHkgc2luY2UgaXQgZ2l2ZXMgeW91IGFuIHVuYmVsaWV2YWJseQo+IHBvd2VyZnVsIG1hY3Jv IGxhbmd1YWdlIGluIHRoZSBhc3NlbWJsZXIuCj4KCml0IHNob3VsZCBiZSBubyBwcm9ibGVtIHRv IG1lcmdlIGFzbSBibG9ja3MgaW4gYSBmdW5jdGlvbiwgdGhlIG9ubHkgcHJvYmxlbQppcyBtaXhp bmcgbm9ybWFsIGRjb2RlIGluIHRoZXJlIGFzIHdlbGwuCkkndmUgZGVjaWRlZCB0byBtYWtlIHRo aXMgYW4gZXJyb3IgaW4gTERDIHNpbmNlIHRoZXJlIGlzIG5vIHNlbnNpYmxlIHdheSB0bwppbXBs ZW1lbnQgRC1zdHlsZSBmdW5jdGlvbiBwYXJhbWV0ZXJzICphbmQqIG1ha2Ugc3VyZSB0aGUgZnVu Y3Rpb24gcmVhbGx5IGlzCm5ha2VkLiBmdW5jdGlvbiBwYXJhbWV0ZXJzIGluIGxsdm0gYXJlIHNz YSB2YWx1ZXMsIHNvIHlvdSBtYW51YWxseSBoYXZlIHRvCmFsbG9jYSBhIHN0YWNrIHNsb3QgYW5k IGNvcHkgdGhlIGFyZ3VtZW50IGludG8gdGhhdCB0byBtYWtlIHN1cmUgdGhlCnBhcmFtZXRlciBp cyBhbiBsLXZhbHVlLCBJIGNvdWxkIHByb2JhYmx5IGNvbWUgdXAgd2l0aCBzb21lIG1vcmUgcmVh c29ucywKYnV0IEkgdGhpbmsgdGhpcyBpcyBzdWZmaWNpZW50IHJlYXNvbiB0byBzaW1wbHkgZHJv cCB0aGF0IChpbGwtZGVmaW5lZCkKZmVhdHVyZS4KCipOT1RFOiBuYWtlZCBpcyBub3QgeWV0IDEw MCUgaW1wbGVtZW50ZWQgaW4gbGRjCgoKPgo+Cj4gU28sIEkgcmVjb21tZW5kIHRoZSBmb2xsb3dp bmc6Cj4KPj4KPj4gKyBSZW1vdmUgdGhlIG5ha2VkIGtleXdvcmQgYXMgYW4gYXNzZW1ibHkgJ2lu c3RydWN0aW9uJy4KPj4KPj4gKyBJbnN0YXRlIGl0IGFzIGEgZnVuY3Rpb24gcHJvcGVydHksIHNp bWlsYXJseSB0byAnZXh0ZXJuIChDKScuIFNvIHlvdQo+PiBtaWdodCBzZWUgdGhlIGZvbGxvd2lu ZyBkZWNsYXJhdGlvbjoKPj4KPj4gICAgZXh0ZXJuIG5ha2VkIHZvaWQgZmx1c2hJRFQoKSB7Cj4+ ICAgICAgICBtb3YgRUFYLCBbRVNQKzRdCj4+ICAgICAgICBsaWR0IFtFQVhdCj4+ICAgICAgICBy ZXQKPj4gICAgfQo+Pgo+Cj4gSXQgZG9lc24ndCBuZWVkIHRvIHBhcnQgb2YgdGhlIGZ1bmN0aW9u IHNpZ25hdHVyZSwgdGhvdWdoLCBkb2VzIGl0Pwo+Cj4+Cj4+IFRob3VnaCwgaWYgdGhlIGFzc2Vt Ymx5IGlzIGltcGxpY2l0LCBpdCBtaWdodCBiZSBiZXR0ZXIgdG8gcmVuYW1lIHRoZQo+PiBrZXl3 b3JkICdhc20nIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQgdG8gbWFrZSBpdCBjbGVhcmVyLiBBbnl3 YXksIHRoZXNlCj4+IGNoYW5nZXMgd2lsbCwgaW4gbXkgaHVtYmxlIG9waW5pb24sIG1ha2UgdGhl IGxhbmd1YWdlIGNsZWFuZXIgYW5kIG15IGxpZmUKPj4gZWFzaWVyIGJlY2F1c2UgSSBjYW4gc2lt cGx5IGRlY2xhcmUgdGhpcyBmdW5jdGlvbiBieSBteXNlbGYuCj4+Cj4KPiBCZWNhdXNlIG9mIHdo YXQgSSB3cm90ZSBhYm92ZSwgSSB0aGluayB0aGlzIHJlbW92ZXMgdG9vIG11Y2ggZnVuY3Rpb25h bGl0eS4KPiBJIHRoaW5rIGl0IHdvdWxkIGJlIHF1aXRlIHJlYXNvbmFibGUsIHRob3VnaCwgdG8g bWFrZSBub24tYXNtIGNvZGUKPiBnZW5lcmF0aW9uIGlsbGVnYWwgaW5zaWRlIGEgbmFrZWQgZnVu Y3Rpb24uIEJUVyB0aGlzIHByb2JhYmx5IGluY2x1ZGVzCj4gY29udHJhY3RzIChhdCBwcmVzZW50 LCBjb250cmFjdHMgZG9uJ3Qgd29yayBmb3IgbmFrZWQgZnVuY3Rpb25zIGV2ZW4gaW4KPiBETUQp Lgo+IFdvdWxkIHRoYXQgcmVzdHJpY3Rpb24gYmUgZW5vdWdoPwo+Cj4KPgo+PiBDaGVlcnMhCj4+ Cj4+IC1EdWFuZQo+Pgo+Cg==
Jan 06 2009
Tomas Lindquist Olsen wrote:On Fri, Jan 2, 2009 at 9:21 AM, Don <nospam nospam.com <mailto:nospam 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-valueI 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 withsome 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
Jan 07 2009
Content-Disposition: inline T24gV2VkLCBKYW4gNywgMjAwOSBhdCAxMjo0MSBQTSwgRG9uIDxub3NwYW1Abm9zcGFtLmNvbT4g d3JvdGU6Cgo+IFRvbWFzIExpbmRxdWlzdCBPbHNlbiB3cm90ZToKPgo+PiBPbiBGcmksIEphbiAy LCAyMDA5IGF0IDk6MjEgQU0sIERvbiA8bm9zcGFtQG5vc3BhbS5jb20gPG1haWx0bzoKPj4gbm9z cGFtQG5vc3BhbS5jb20+PiB3cm90ZToKPj4KPj4gICAgRHVhbmUgQmFpbGV5IHdyb3RlOgo+Pgo+ PiAgICAgICAgSSBhbSBjdXJyZW50bHkgcG9ydGluZyBMREMgIHRvIFBvd2VyUEMgYW5kLCBob3Bl ZnVsbHksCj4+ICAgICAgICBldmVudHVhbGx5IHRoZSBQT1dFUiBhbmQgQ0VMTCBwbGF0Zm9ybXMg YXMgd2VsbC4gVGhlIGZpcnN0IGJpdAo+PiAgICAgICAgcmVxdWlyZXMgbWUgdG8gcG9ydCB0aGUg aW5saW5lIGFzc2VtYmxlciwgYWxsb3dpbmcgbWUgdG8KPj4KPj4gICAgcmV2aWV3IHRoZSBwcm9i bGVtcyB0aGF0IHRoZSBEIGxhbmd1YWdlIHByZXNlbnRzIExMVk0uCj4+ICAgIENvb2whISEhCj4+ Cj4+Cj4+Cj4+ICAgICAgICBMTFZNIGlzIG5vdCBhIHRveSB2aXJ0dWFsIG1hY2hpbmUuIEl0IGlz LCBwZXJoYXBzLCB0aGUgbW9zdAo+PiAgICAgICAgZmxleGlibGUgYW5kIHBvd2VyZnVsIGNvbXBp bGVyIHRvb2xzZXQgZXZlciwgc3Bhbm5pbmcgbWFzc2l2ZQo+PiAgICAgICAgbnVtYmVycyBvZiBj b21wdXRpbmcgcGxhdGZvcm1zLiBJdCBldmVuIHN1cHBvcnRzIChpbiBhIGxpbWl0ZWQKPj4gICAg ICAgIG1hbm5lcikgdGhlIFBJQzE2IHBsYXRmb3JtLCByZXF1aXJlIGluc2FuZSBjb25zdHJhaW50 czogdGhlcmUKPj4gICAgICAgIGFyZSBubyByZWdpc3RlcnMsIG1lbW9yeSBjYW4gb25seSBiZSBh Y2Nlc3NlZCBpbiBvbmUgYnl0ZQo+PiAgICAgICAgYW1vdW50cywgYW5kIHNvbWUgcHJvY2Vzc29y cyBvbmx5IGhhdmUgMzUgaW5zdHJ1Y3Rpb25zLgo+Pgo+Pgo+PiAgICBUaGF0J3MgcHJldHR5IGlt cHJlc3NpdmUuIEknbSBjdXJyZW50bHkgdXNpbmcgYSBQSUMsIGJ1dCBpdCdzIHNvCj4+ICAgIG1l bW9yeS1saW1pdGVkIGl0J3MgaGFyZCB0byBiZWxpZXZlIEQgZXZlciBiZWluZyB3b3JrYWJsZSBv biBpdC4KPj4KPj4KPj4gICAgICAgIExMVk0sIGhvd2V2ZXIsIGlzIG5vdCBhYmxlIHRvIGRvIGV2 ZXJ5dGhpbmcuIEZvciBzb21lIHJlYXNvbiwKPj4gICAgICAgIGl0cyBjdXJyZW50IEFQSSBkb2Vz IG5vdCBhbGxvdyB0aGUgcmVzdHJpY3Rpb24gb2YgcHJvbG9ndWUgYW5kCj4+ICAgICAgICBlcGls b2d1ZSBnZW5lcmF0aW9uOyB0byBhbGxvdyBzbyB3b3VsZCBub3QgbWFrZSBzZW5zZTogIHRoZQo+ PiAgICAgICAgbGFuZ3VhZ2UgaXRzZWxmIGRlcGVuZHMgb24gdGhlIG1haW50ZW5hbmNlIG9mIHRo ZSBzdGFjay4gVGhlCj4+ICAgICAgICBvbmx5IHdheSB0byBlc3RhYmxpc2ggYSAnbmFrZWQnIGZ1 bmN0aW9uIGluICpjKiBpcyB0byAnb21pdCcgdGhlCj4+ICAgICAgICBmcmFtZSBwb2ludGVy4oCU dGVjaG5pY2FsbHkgbm90IGFsbG93ZWQgaW4gbW9zdCBPUydzIEFCSXPigJRhbmQgdGhlbgo+PiAg ICAgICAgZXhwbGljaXRseSBhdm9pZCB1c2luZyBhbGwgdmFyaWFibGVzIChhbmQgaGVuY2UgdGhl IHN0YWNrKSwgT1IKPj4gICAgICAgIHRvIHVzZSB0b3AgbGV2ZWwgYXNzZW1ibHkgdG8gd3JpdGUg dGhlIGFzc2VtYmx5IHlvdXJzZWxmLgo+Pgo+PiAgICAgICAgTm93LCBuZWl0aGVyIG9mIHRob3Nl IG9wdGlvbnMgYXJlIHJlYWxseSB3aGF0IEQgc2hvdWxkIHVzZSwgYnV0Cj4+ICAgICAgICBJIGhh dmUgc29tZSBvdGhlciByZWNvbW1lbmRhdGlvbnMgYmFzZWQgb24gdGhpcy4gJ25ha2VkJwo+PiAg ICAgICAgZnVuY3Rpb25zIHNob3VsZCBub3QgYmUgYWxsb3dlZCB0byBoYXZlIGFueSBELCBleGNl cHQgdG8KPj4gICAgICAgIHJlZmVyZW5jZSBhcmd1bWVudHMgcGFzc2VkIHRvIGl0LiBJbiBvdGhl ciB3b3JkcywgaXQgc2hvdWxkIG5vdAo+PiAgICAgICAgdG91Y2ggdGhlIHN0YWNrLiBpbiBmYWN0 LCB0aGVyZSdzIHJlYWxseSBubyByZWFzb24gYXQgYWxsIHRvCj4+ICAgICAgICBoYXZlIHRoZSAn bmFrZWQnIHN0YXRlbWVudCBpbiB0aGUgaW5saW5lIGFzc2VtYmx5LiBJdCdzIG5vdCAgYQo+PiAg ICAgICAgcHJvcGVydHkgb2YgdGhlIGFzc2VtYmx5LCBpdCdzIGEgcHJvcGVydHkgb2YgdGhlICpm dW5jdGlvbiouIEFuZAo+PiAgICAgICAgYmVjYXVzZSBEIGNvZGUgc2hvdWxkIG5vdCBiZSB1c2Vk IChleGNlcHQgcGVyaGFwcyBmb3IgbWFjcm9zPyksCj4+ICAgICAgICAnbmFrZWQnIGZ1bmN0aW9u cyBzaG91bGQgaW50cmluc2ljYWxseSBiZSBhc3NlbWJseSBmdW5jdGlvbnMuCj4+Cj4+Cj4+ICAg IEkgYWdyZWUgd2l0aCB0aGlzLiBNaXhpbmcgcnVuLXRpbWUgRCBhbmQgbmFrZWQgYXNtIGRvZXNu J3QgbWFrZSBhbnkKPj4gICAgc2Vuc2UuIEJ1dCwgc29tZXRoaW5nIHdoaWNoIEkndmUgZG9uZSB3 aGljaCBpcyBfdmVyeV8gdXNlZnVsIGlzIHRvCj4+ICAgIG1peGluIENURkUgZnVuY3Rpb25zLiBZ b3UgZ2V0IHNvbWV0aGluZyBsaWtlOgo+Pgo+PiAgICB2b2lkIGZvbygpIHsKPj4gICAgIGFzbSB7 Cj4+ICAgICBuYWtlZDsKPj4gICAgIH0KPj4gICAgIG1peGluKHNvbWVhc20oIkVCWCIpKTsgLy8g YmVjb21lcyBhc20ge21vdiBFQVgsIEVCWDsgfQo+PiAgICAgYXNtIHsgcmV0OyB9Cj4+ICAgIH0K Pj4KPj4gICAgY2hhciBbXSBzb21lYXNtKGNoYXIgW10gYykgewo+PiAgICAgcmV0dXJuICJhc20g eyBtb3YgRUFYLCIgfiBjIH4iOyB9IjsKPj4gICAgfQo+Pgo+PiAgICBJIHNlZSB0aGlzIGFzIGNy dWNpYWwgZnVuY3Rpb25hbGl0eSBzaW5jZSBpdCBnaXZlcyB5b3UgYW4KPj4gICAgdW5iZWxpZXZh Ymx5IHBvd2VyZnVsIG1hY3JvIGxhbmd1YWdlIGluIHRoZSBhc3NlbWJsZXIuCj4+Cj4+Cj4+IGl0 IHNob3VsZCBiZSBubyBwcm9ibGVtIHRvIG1lcmdlIGFzbSBibG9ja3MgaW4gYSBmdW5jdGlvbiwg dGhlIG9ubHkKPj4gcHJvYmxlbSBpcyBtaXhpbmcgbm9ybWFsIGRjb2RlIGluIHRoZXJlIGFzIHdl bGwuCj4+IEkndmUgZGVjaWRlZCB0byBtYWtlIHRoaXMgYW4gZXJyb3IgaW4gTERDIHNpbmNlIHRo ZXJlIGlzIG5vIHNlbnNpYmxlIHdheQo+PiB0byBpbXBsZW1lbnQgRC1zdHlsZSBmdW5jdGlvbiBw YXJhbWV0ZXJzICphbmQqIG1ha2Ugc3VyZSB0aGUgZnVuY3Rpb24gcmVhbGx5Cj4+IGlzIG5ha2Vk LiBmdW5jdGlvbiBwYXJhbWV0ZXJzIGluIGxsdm0gYXJlIHNzYSB2YWx1ZXMsIHNvIHlvdSBtYW51 YWxseSBoYXZlCj4+IHRvIGFsbG9jYSBhIHN0YWNrIHNsb3QgYW5kIGNvcHkgdGhlIGFyZ3VtZW50 IGludG8gdGhhdCB0byBtYWtlIHN1cmUgdGhlCj4+IHBhcmFtZXRlciBpcyBhbiBsLXZhbHVlCj4+ Cj4KPiBJIGRvbid0IHVuZGVyc3RhbmQgdGhvc2UgbGFzdCB0d28gc2VudGVuY2VzLiBEb2VzIGl0 IG1lYW4gdGhhdCB5b3UnZCBvbmx5Cj4gYWxsb3cgJ25ha2VkJyBvbiBleHRlcm4oQykgZnVuY3Rp b25zPyBPciBvbmx5IHRoYXQgbWl4aW5nIEQgYW5kIG5ha2VkIGFzbQo+IHdvdWxkIGJlIGlsbGVn YWw/CgoKU29ycnksIEkgY2FuIHNlZSBJIHdhcyBhIGJpdCB1bmNsZWFyLiBBbGwgSSBtZWFudCB3 YXMgdGhhdCBJIGNhbid0IHNlbnNpYmx5CmltcGxlbWVudCBuYWtlZCBhbmQgYWxsb3cgYXJiaXRy YXJ5IEQgY29kZSBpbiB0aGUgbWl4IGFzIHdlbGwsIGl0J3MgZWl0aGVyCm9yLi4uIG5ha2VkIHNo b3VsZCBldmVudHVhbGx5IHdvcmsgZmluZSBmb3IgYW55IGNhbGxpbmcgY29udmVudGlvbnMsIGl0 J2xsCmp1c3QgYmFpbCBvdXQgd2l0aCBhbiBlcnJvciBpZiB5b3UgdHJ5IGFuZCBtaXggRCBpbiBi ZXR3ZWVuIHRoZSBhc20gYmxvY2tzLgoKCj4KPiBCeSB0aGUgd2F5LCBpbiBETUQsIG1peGluZyBu YWtlZCBhbmQgRCBjb2RlIG9ubHkgd29ya3MgaWYgeW91IHB1dCBhICJwdXNoCj4gRUJQOyBtb3Yg ICBFQlAsIEVTUDsiIGJlZm9yZSB0aGUgZmlyc3QgYml0IG9mIEQgY29kZSwgd2hpY2ggaXNuJ3Qg ZG9jdW1lbnRlZAo+IGFueXdoZXJlIGFzIGZhciBhcyBJIGtub3c7IGFuZCBJIGRvbid0IGtub3cg aG93IHRvIG1ha2UgaW5uZXIgZnVuY3Rpb25zCj4gd29yay4gU28gaXQncyBwcmV0dHkgbXVjaCB1 bnNwZWNpZmllZCBiZWhhdmlvdXIgcmlnaHQgbm93Lgo+CgpuZXN0ZWQgZGVsZWdhdGVzIGluc2lk ZSBuYWtlZCBmdW5jdGlvbnMgcG9zZSBzb21lIHByb2JsZW1zLCBzaW5jZSB0aGV5IHdpbGwKbW9k aWZ5IHRoZSBzdGFjayBmcmFtZSBhcyB3ZWxsIChsaWtlIGFsbG93aW5nIGZ1bGwgYWNjZXNzIHRv IGZ1bmN0aW9uCnBhcmFtZXRlcnMsIGxpa2UgdGFraW5nIHRoZSBhZGRyZXNzIG9mIG9uZSwgd2hp Y2ggd2FzIHdoYXQgSSB3YXMgdHJ5aW5nIHRvCnRhbGsgYWJvdXQgaW4gbXkgcmVwbHkpCgpDb25z aWRlciB0YWtpbmcgdGhlIGFkZHJlc3Mgb2YgYSBwYXJhbWV0ZXIgdGhhdCBpcyBwYXNzZWQgYnkg dmFsdWUgaW4gRUFYLAp0aGlzIHdpbGwgYWxsb2NhdGUgYSBzdGFjayBzbG90Li4uCgpIb3BlIEkg d2FzIGEgYml0IG1vcmUgY2xlYXIgdGhpcyB0aW1lIDopCg==
Jan 07 2009
Um... perhaps next time don't base64 encode the message. Sean
Jan 07 2009
On Wed, 07 Jan 2009 21:48:33 +0300, Sean Kelly <sean invisibleduck.org> wrote:Um... perhaps next time don't base64 encode the message. SeanI have no problem reading his message. It's just PHP News Reader (pnews) is buggy.
Jan 07 2009
Tomas Lindquist Olsen wrote:
On Wed, Jan 7, 2009 at 12:41 PM, Don <nospam nospam.com
<mailto:nospam nospam.com>> wrote:
Tomas Lindquist Olsen wrote:
On Fri, Jan 2, 2009 at 9:21 AM, Don <nospam nospam.com
<mailto:nospam nospam.com> <mailto:nospam nospam.com
<mailto:nospam 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?
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.
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.
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)
Consider taking the address of a parameter that is passed by value in
EAX, this will allocate a stack slot...
Hope I was a bit more clear this time :)
Yes. And that's awesome! It means my existing Bigint naked asm code in
Tango should work on LDC without modification.
Jan 07 2009