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=


8,=20

 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=


g?=20

=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
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.


The idea is that you can support name mangling that the compiler can't 
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
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
next sibling parent reply "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
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 reply "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
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
next sibling 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
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 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
next sibling 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 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