www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 'naked' keyword

reply Duane Bailey <bailey.d.r gmail.com> writes:
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
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
parent Duane Bailey <bailey.d.r gmail.com> writes:
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
prev sibling parent reply Don <nospam nospam.com> writes:
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. 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
next sibling parent Duane Bailey <bailey.d.r gmail.com> writes:
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
prev sibling parent reply "Tomas Lindquist Olsen" <tomas.l.olsen gmail.com> writes:
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
parent reply Don <nospam nospam.com> writes:
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-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
 
Jan 07 2009
parent reply "Tomas Lindquist Olsen" <tomas.l.olsen gmail.com> writes:
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
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Um... perhaps next time don't base64 encode the message.


Sean
Jan 07 2009
parent "Denis Koroskin" <2korden gmail.com> writes:
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.


 Sean
I have no problem reading his message. It's just PHP News Reader (pnews) is buggy.
Jan 07 2009
prev sibling parent Don <nospam nospam.com> writes:
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