www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - pragma(mangle)

reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
Stealing the idea from http://d.puremagic.com/issues/show_bug.cgi?id=2698, 
I've implemented pragma(mangle).

Basically,
pragma(mangle, "_mangled__name_")
void myfunction() {}

Will cause the compiler to use "_mangled__name_" as the function's mangle 
string.

Would many people find this a useful thing to have in the compiler?

Also, does anybody know what set of characters to accept in a mangle string? 
Jun 11 2011
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
I'd use it. And any characters usable as a jump label in ask should be accep=
ted. OSX does some weird macro mangling of some posix functions and short of=
 a C or asm trampoline these can't be called in D.

Sent from my iPhone

On Jun 11, 2011, at 1:47 PM, "Daniel Murphy" <yebblies nospamgmail.com> wrot=
e:

 Stealing the idea from http://d.puremagic.com/issues/show_bug.cgi?id=3D269=

 I've implemented pragma(mangle).
=20
 Basically,
 pragma(mangle, "_mangled__name_")
 void myfunction() {}
=20
 Will cause the compiler to use "_mangled__name_" as the function's mangle=20=

 string.
=20
 Would many people find this a useful thing to have in the compiler?
=20
 Also, does anybody know what set of characters to accept in a mangle strin=

=20
=20

Jun 11 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Murphy" <yebblies nospamgmail.com> wrote in message 
news:it0kh7$2v1r$1 digitalmars.com...
 Stealing the idea from http://d.puremagic.com/issues/show_bug.cgi?id=2698, 
 I've implemented pragma(mangle).

 Basically,
 pragma(mangle, "_mangled__name_")
 void myfunction() {}

 Will cause the compiler to use "_mangled__name_" as the function's mangle 
 string.

 Would many people find this a useful thing to have in the compiler?

 Also, does anybody know what set of characters to accept in a mangle 
 string?

It sounds like it may have great potential for working around hashed mangles. And maybe for exposing an API to another link-compatible language like C (or not, I don't know, maybe extern(C) is always good enough for that?). Two possible problems I can see: 1. Can it be reliably demangled? If not, I think that would severely hinder its usefulness. 2. What if "myfunction" is templated?
Jun 11 2011
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:it0m05$6t7$1 digitalmars.com...
 It sounds like it may have great potential for working around hashed 
 mangles. And maybe for exposing an API to another link-compatible language 
 like C (or not, I don't know, maybe extern(C) is always good enough for 
 that?).

You could use it, for example, to provide a function with C++ linkage taking a C++ long parameter, something which I think is currently impossible in D. D also can't provide C functions with names that are D reserved identifiers. extern(C) pragma(mangle, "_pure") void cpure() {}
 Two possible problems I can see:

 1. Can it be reliably demangled? If not, I think that would severely 
 hinder its usefulness.

understand. I'd imagine you'd have to follow D name mangling if you wanted it demangled.
 2. What if "myfunction" is templated?

Currently it attaches to one declaration and alters it's mangle, that's it. I'm not sure what should happen in more complicated situations. I do think this should be possible: template(name, T, U) { extern pragma(mangle, genMangle!(name, T, U) void myfun(name, T, U); }
Jun 11 2011
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 11/06/2011 23:15, Andrej Mitrovic wrote:
 On 6/11/11, Daniel Murphy<yebblies nospamgmail.com>  wrote:
 You could use it, for example, to provide a function with C++ linkage taking
 a C++ long parameter, something which I think is currently impossible in D.

I assumed I must have been doing something wrong when I filed this: http://d.puremagic.com/issues/show_bug.cgi?id=6121 . But I guess not. I can't link DDMD with the DMD 2.053 backend because of this. I'd have to change DMD's long types to int, which might not be a big issue but I'd rather avoid having to patch every release..

When I was working on ddmd this was worked around with a wrapper C file that wrapped the functions with long parameters in functions D accepted. Is that file no longer there? -- Robert http://octarineparrot.com/
Jun 11 2011
parent "Nick Sabalausky" <a a.a> writes:
"Robert Clipsham" <robert octarineparrot.com> wrote in message 
news:it0rec$mii$1 digitalmars.com...
 On 11/06/2011 23:15, Andrej Mitrovic wrote:
 On 6/11/11, Daniel Murphy<yebblies nospamgmail.com>  wrote:
 You could use it, for example, to provide a function with C++ linkage 
 taking
 a C++ long parameter, something which I think is currently impossible in 
 D.

I assumed I must have been doing something wrong when I filed this: http://d.puremagic.com/issues/show_bug.cgi?id=6121 . But I guess not. I can't link DDMD with the DMD 2.053 backend because of this. I'd have to change DMD's long types to int, which might not be a big issue but I'd rather avoid having to patch every release..

When I was working on ddmd this was worked around with a wrapper C file that wrapped the functions with long parameters in functions D accepted. Is that file no longer there?

Yea, it's still there: "bridge/bridge.cpp" I had wondered what exactly that was for. In retrospect, it probably would have been obvious if I had ever actually paid any attention to anything inside that file ;)
Jun 11 2011
prev sibling parent David Nadlinger <see klickverbot.at> writes:
On 6/12/11 9:21 PM, Andrej Mitrovic wrote:
 If you take a diff of DMD's parse.c and DDMD's parser.d, you'll see
 that they're almost identical. So yeah, I think what DDMD devs
 probably do is take a diff of two DMD versions and then manually
 upgrade DDMD's frontend to match. I don't think it's way too much work
 (I'm just assuming though), simple C++ code tends to translate nicely
 into D and I think DMD's C++ sources are nice and readable.

ddmd is obviously a different story, but just merging the commits one-by-one manually has worked quite well for me when doing LDC frontend updates. Merging a whole release worth of changes at once might be more efficient, but I found it a lot more difficult to reason about the changes that way. David
Jun 12 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/11/11, Daniel Murphy <yebblies nospamgmail.com> wrote:
 You could use it, for example, to provide a function with C++ linkage taking
 a C++ long parameter, something which I think is currently impossible in D.

I assumed I must have been doing something wrong when I filed this: http://d.puremagic.com/issues/show_bug.cgi?id=6121 . But I guess not. I can't link DDMD with the DMD 2.053 backend because of this. I'd have to change DMD's long types to int, which might not be a big issue but I'd rather avoid having to patch every release..
Jun 11 2011
parent "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.825.1307830585.14074.digitalmars-d puremagic.com...
 On 6/11/11, Daniel Murphy <yebblies nospamgmail.com> wrote:
 You could use it, for example, to provide a function with C++ linkage 
 taking
 a C++ long parameter, something which I think is currently impossible in 
 D.

I assumed I must have been doing something wrong when I filed this: http://d.puremagic.com/issues/show_bug.cgi?id=6121 . But I guess not. I can't link DDMD with the DMD 2.053 backend because of this. I'd have to change DMD's long types to int, which might not be a big issue but I'd rather avoid having to patch every release..

Are you working on updating DDMD to a newer DMD, or just simply trying to use the newer backend? If the former, then that's fantastic and I look forward to it.
Jun 11 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/12/11, Nick Sabalausky <a a.a> wrote:
 Are you working on updating DDMD to a newer DMD, or just simply trying to
 use the newer backend? If the former, then that's fantastic and I look
 forward to it.

I'd like to really work on it properly (it would seem like an exciting project to work on!), and update DDMD to be more D2-like, e.g. that entire main.d module seems to re-implement argument passing via C APIs just like DMD's C++ code, but this seems unnecessary to me? Replacing that with getopt() would cut that module down to a tiny fragment of its original size. What I'm really interested in doing is building interfaces to DDMD via various functions so it can be used by tools on demand. If I get something rolling I might put it up on github or somewhere, will let you know..
Jun 11 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.828.1307833235.14074.digitalmars-d puremagic.com...
 On 6/12/11, Nick Sabalausky <a a.a> wrote:
 Are you working on updating DDMD to a newer DMD, or just simply trying to
 use the newer backend? If the former, then that's fantastic and I look
 forward to it.

I'd like to really work on it properly (it would seem like an exciting project to work on!), and update DDMD to be more D2-like, e.g. that entire main.d module seems to re-implement argument passing via C APIs just like DMD's C++ code, but this seems unnecessary to me? Replacing that with getopt() would cut that module down to a tiny fragment of its original size.

Actually, what I meant was this: DDMD is currently based on DMD 2.040. Ie, ATM, it's DMD 2.040 ported to D. You said you were trying to use the 2.053 backend with DDMD, so I was just wondering if you were also updating DDMD frontend to be a D port of something newer than 2.040.
 What I'm really interested in doing is building interfaces to DDMD via
 various functions so it can be used by tools on demand. If I get
 something rolling I might put it up on github or somewhere, will let
 you know..

That does sounds cool, too :)
Jun 12 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/12/11 4:23 AM, Nick Sabalausky wrote:
 "Andrej Mitrovic"<andrej.mitrovich gmail.com>  wrote in message
 news:mailman.828.1307833235.14074.digitalmars-d puremagic.com...
 On 6/12/11, Nick Sabalausky<a a.a>  wrote:
 Are you working on updating DDMD to a newer DMD, or just simply trying to
 use the newer backend? If the former, then that's fantastic and I look
 forward to it.

I'd like to really work on it properly (it would seem like an exciting project to work on!), and update DDMD to be more D2-like, e.g. that entire main.d module seems to re-implement argument passing via C APIs just like DMD's C++ code, but this seems unnecessary to me? Replacing that with getopt() would cut that module down to a tiny fragment of its original size.

Actually, what I meant was this: DDMD is currently based on DMD 2.040. Ie, ATM, it's DMD 2.040 ported to D. You said you were trying to use the 2.053 backend with DDMD, so I was just wondering if you were also updating DDMD frontend to be a D port of something newer than 2.040.

I've always wondered what's the methodology of changing ddmd from diffs in dmd. I can only imagine it as a difficult manual process. Andrei
Jun 12 2011
parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:it2l1n$1alh$2 digitalmars.com...
 On 6/12/11 4:23 AM, Nick Sabalausky wrote:
 "Andrej Mitrovic"<andrej.mitrovich gmail.com>  wrote in message
 news:mailman.828.1307833235.14074.digitalmars-d puremagic.com...
 On 6/12/11, Nick Sabalausky<a a.a>  wrote:
 Are you working on updating DDMD to a newer DMD, or just simply trying 
 to
 use the newer backend? If the former, then that's fantastic and I look
 forward to it.

I'd like to really work on it properly (it would seem like an exciting project to work on!), and update DDMD to be more D2-like, e.g. that entire main.d module seems to re-implement argument passing via C APIs just like DMD's C++ code, but this seems unnecessary to me? Replacing that with getopt() would cut that module down to a tiny fragment of its original size.

Actually, what I meant was this: DDMD is currently based on DMD 2.040. Ie, ATM, it's DMD 2.040 ported to D. You said you were trying to use the 2.053 backend with DDMD, so I was just wondering if you were also updating DDMD frontend to be a D port of something newer than 2.040.

I've always wondered what's the methodology of changing ddmd from diffs in dmd. I can only imagine it as a difficult manual process.

I've recently asked about that on the DDMD forum. No response yet, but it's not really a high-traffic forum anyway: http://www.dsource.org/forums/viewtopic.php?t=5946&sid=4ece5dbd7a2352d5de1f61b14452733f As I said there: "I would guess that right strategy would be to compare two versions of DMD (ie, the one DDMD is currently based on, and the one you're trying to update to), and then recreate the changes in DDMD."
Jun 12 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/12/11, Robert Clipsham <robert octarineparrot.com> wrote:
 On 11/06/2011 23:15, Andrej Mitrovic wrote:
 On 6/11/11, Daniel Murphy<yebblies nospamgmail.com>  wrote:
 You could use it, for example, to provide a function with C++ linkage
 taking
 a C++ long parameter, something which I think is currently impossible in
 D.

I assumed I must have been doing something wrong when I filed this: http://d.puremagic.com/issues/show_bug.cgi?id=6121 . But I guess not. I can't link DDMD with the DMD 2.053 backend because of this. I'd have to change DMD's long types to int, which might not be a big issue but I'd rather avoid having to patch every release..

When I was working on ddmd this was worked around with a wrapper C file that wrapped the functions with long parameters in functions D accepted. Is that file no longer there? -- Robert http://octarineparrot.com/

I did have to update some definitions in the bridge file, and now I've just noticed that I've accidentally killed one prototype in the bridge file. So that fixes that issue. I'm left with one nagging symbol, "Symbol Undefined ?fatal YAXXZ (void cdecl fatal(void ))". I'll figure this out later.
Jun 11 2011
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/12/11, Nick Sabalausky <a a.a> wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:it2l1n$1alh$2 digitalmars.com...
 On 6/12/11 4:23 AM, Nick Sabalausky wrote:
 "Andrej Mitrovic"<andrej.mitrovich gmail.com>  wrote in message
 news:mailman.828.1307833235.14074.digitalmars-d puremagic.com...
 On 6/12/11, Nick Sabalausky<a a.a>  wrote:
 Are you working on updating DDMD to a newer DMD, or just simply trying
 to
 use the newer backend? If the former, then that's fantastic and I look
 forward to it.

I'd like to really work on it properly (it would seem like an exciting project to work on!), and update DDMD to be more D2-like, e.g. that entire main.d module seems to re-implement argument passing via C APIs just like DMD's C++ code, but this seems unnecessary to me? Replacing that with getopt() would cut that module down to a tiny fragment of its original size.

Actually, what I meant was this: DDMD is currently based on DMD 2.040. Ie, ATM, it's DMD 2.040 ported to D. You said you were trying to use the 2.053 backend with DDMD, so I was just wondering if you were also updating DDMD frontend to be a D port of something newer than 2.040.

I've always wondered what's the methodology of changing ddmd from diffs in dmd. I can only imagine it as a difficult manual process.

I've recently asked about that on the DDMD forum. No response yet, but it's not really a high-traffic forum anyway: http://www.dsource.org/forums/viewtopic.php?t=5946&sid=4ece5dbd7a2352d5de1f61b14452733f As I said there: "I would guess that right strategy would be to compare two versions of DMD (ie, the one DDMD is currently based on, and the one you're trying to update to), and then recreate the changes in DDMD."

If you take a diff of DMD's parse.c and DDMD's parser.d, you'll see that they're almost identical. So yeah, I think what DDMD devs probably do is take a diff of two DMD versions and then manually upgrade DDMD's frontend to match. I don't think it's way too much work (I'm just assuming though), simple C++ code tends to translate nicely into D and I think DMD's C++ sources are nice and readable.
Jun 12 2011
parent "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.849.1307906475.14074.digitalmars-d puremagic.com...
 On 6/12/11, Nick Sabalausky <a a.a> wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:it2l1n$1alh$2 digitalmars.com...
 I've always wondered what's the methodology of changing ddmd from diffs 
 in

 dmd. I can only imagine it as a difficult manual process.

I've recently asked about that on the DDMD forum. No response yet, but it's not really a high-traffic forum anyway: http://www.dsource.org/forums/viewtopic.php?t=5946&sid=4ece5dbd7a2352d5de1f61b14452733f As I said there: "I would guess that right strategy would be to compare two versions of DMD (ie, the one DDMD is currently based on, and the one you're trying to update to), and then recreate the changes in DDMD."

If you take a diff of DMD's parse.c and DDMD's parser.d, you'll see that they're almost identical. So yeah, I think what DDMD devs probably do is take a diff of two DMD versions and then manually upgrade DDMD's frontend to match. I don't think it's way too much work (I'm just assuming though), simple C++ code tends to translate nicely into D and I think DMD's C++ sources are nice and readable.

The AST is different though. I haven't compared the contents of the files, but a quick comparison of the directory contents suggests that DMD has many different AST classes in a single .h/.c combo (with a separate .h/.c combo for each "category" of AST class types), wheras DDMD splits all the AST types into their own separate .d files. Also, since C++ and D syntax is naturally different, a file compare between a .c and .d would come up with a lot of "changes" that are just syntax differences and not real changes at all. I'd imagine there'd be a lot of that to sort through.
Jun 12 2011