www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Calling conventions

reply Mike <vertex gmx.at> writes:
Just an idea ... no feature request for D, but for the compiler :)

I've got a lot of calling conventions in my project now. The punks under=
  =

these calling conventions are:

* MSVC's "thiscall"
(for talking to ASIO audio drivers)

... and the very strange ...

* extern (Pascal) with parameters defined in reverse order
(for talking to the graphics tablet under windows - I have no idea which=
  =

compiler spits out binaries like these)

With duct tape and a swiss army knife it's all doable ... but it got me =
 =

thinking: wouldn't it be nice to be able to define calling conventions v=
ia  =

XML or so?

<convention name=3D"myFunkyCallingConvention">
     <thisPtr>ECX</thisPtr>
     <return>EAX</return>
     <stackCleaner>callee</stackCleaner>
     <pushOrder>left-to-right</pushOrder>
     <align>4</align>
</convention>

It doesn't have to be XML of course. Just a little half-readable file wi=
th  =

the definition which the compiler can use to generate the appropriate  =

calling code. And if you need it, you can just pass it to DMD.  =

DMD/DMC++ could come with a bunch of them pre-defined.

What do you think?

-Mike

-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Dec 05 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Mike wrote:

 Just an idea ... no feature request for D, but for the compiler :)
 
 I've got a lot of calling conventions in my project now. The punks under 
 these calling conventions are:
 
 * MSVC's "thiscall"
 (for talking to ASIO audio drivers)
 
 ... and the very strange ...
 
 * extern (Pascal) with parameters defined in reverse order
 (for talking to the graphics tablet under windows - I have no idea which 
 compiler spits out binaries like these)
 
 With duct tape and a swiss army knife it's all doable ... but it got me 
 thinking: wouldn't it be nice to be able to define calling conventions 
 via XML or so?
 
 <convention name="myFunkyCallingConvention">
     <thisPtr>ECX</thisPtr>
     <return>EAX</return>
     <stackCleaner>callee</stackCleaner>
     <pushOrder>left-to-right</pushOrder>
     <align>4</align>
 </convention>
 
 It doesn't have to be XML of course. Just a little half-readable file 
 with the definition which the compiler can use to generate the 
 appropriate calling code. And if you need it, you can just pass it to 
 DMD. DMD/DMC++ could come with a bunch of them pre-defined.
 
 What do you think?


-real.inf on using XML for anything.

Anyway I don't really see the utility of separating the calling 
convention from the place where the function is prototyped.  You need 
both to call the function.  It's like putting the function names in one 
file and all the parameters in another file.  I don't get why that would 
be a good thing.

--bb
Dec 05 2007
parent reply Mike <vertex gmx.at> writes:
On Thu, 06 Dec 2007 03:50:16 +0100, Bill Baxter  =

<dnewsgroup billbaxter.com> wrote:


 -real.inf on using XML for anything.


What's a better alternative to XML? I mean generally, not for this  =

proposal. I'd really like to know that - a format that can represent tre=
es  =

easily and is easily readable.


 Anyway I don't really see the utility of separating the calling  =



 convention from the place where the function is prototyped.  You need =


 =


 both to call the function.  It's like putting the function names in on=


e  =


 file and all the parameters in another file.  I don't get why that wou=


ld  =


 be a good thing.


I thought because it's just too much information to put into the syntax =
 =

(given that Walter thinks it's a good idea to support additional calling=
  =

conventions). So an additional file with than information might be nice,=
  =

and if it's XML or something similar DMC++ or a linker/debugger could us=
e  =

that information too, not only DMD.

-Mike

PS: Can't ... resist ...

I, for one, welcome our new XML-based bitmap image format:

<image name=3D"screenshot.bmpx" width=3D"800px" height=3D"600px">
[snip]
<pixel id=3D"D7A9-192B-48AD-F348" xpos=3D"543" ypos=3D"438"  =


[snip]
</image>
Dec 06 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Mike wrote:

 On Thu, 06 Dec 2007 03:50:16 +0100, Bill Baxter 
 <dnewsgroup billbaxter.com> wrote:
 

 -real.inf on using XML for anything.


 
 What's a better alternative to XML? I mean generally, not for this 
 proposal. I'd really like to know that - a format that can represent 
 trees easily and is easily readable.


Lisp.
Or YAML, or JSON.  All much more readable than XML.


 Anyway I don't really see the utility of separating the calling 
 convention from the place where the function is prototyped.  You need 
 both to call the function.  It's like putting the function names in 
 one file and all the parameters in another file.  I don't get why that 
 would be a good thing.


 
 I thought because it's just too much information to put into the syntax 
 (given that Walter thinks it's a good idea to support additional calling 
 conventions). So an additional file with than information might be nice, 
 and if it's XML or something similar DMC++ or a linker/debugger could 
 use that information too, not only DMD.


I see.  I misread your original proposal as suggesting that the calling 
convention for each function in a file be documented in a separate file. 
  I didn't completely missed that you were talking about a way to 
declare _new_ calling conventions.  My bad.

I don't know much about calling conventions.  Are tehre really that many 
out in the wild?  If DMD doesn't support some of the ones that are in 
use, maybe the more reasonable thing would be to just add those.

--bb
Dec 06 2007
next sibling parent reply Mike <vertex gmx.at> writes:
On Thu, 06 Dec 2007 18:26:24 +0100, Bill Baxter  
<dnewsgroup billbaxter.com> wrote:


 I don't know much about calling conventions.  Are tehre really that many  
 out in the wild?  If DMD doesn't support some of the ones that are in  
 use, maybe the more reasonable thing would be to just add those.


Didn't you encounter that problem with bbTablet? Maybe the C++ compiler  
you used knows that calling convention. If you decide to port bbTablet do  
D, you'll be unpleasently surprised.

I have no idea how many calling conventions there are - but since it's  
pretty arbitrary how you pass the arguments I figure there are lots of  
them, just few popular ones. A quick and certainly wrong Wikipedia search  
gave me 15 for x86 only. A way to define the ABI (maybe name mangling as  
well) would solve the problem once and for all. Put up a project on  
dsource where ABI definitions are hosted and everybody can submit anything  
they encounter in the wild. Any compiler, any weird embedded processor,  
everything.

Maybe it'll be possible with macros, I don't know. Maybe something like

pragma(abi, "thiscall")
{
     void opCall(this, param1, param2)
     {
          // here be assembler code for any calls with a this pointer and 2  
parameters
     }
}

would be good.

-Mike

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Dec 06 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Mike wrote:

 On Thu, 06 Dec 2007 18:26:24 +0100, Bill Baxter 
 <dnewsgroup billbaxter.com> wrote:
 

 I don't know much about calling conventions.  Are tehre really that 
 many out in the wild?  If DMD doesn't support some of the ones that 
 are in use, maybe the more reasonable thing would be to just add those.


 
 Didn't you encounter that problem with bbTablet? Maybe the C++ compiler 
 you used knows that calling convention. If you decide to port bbTablet 
 do D, you'll be unpleasently surprised.


Bummer.  As might be expected, Microsoft's C/C++ compilers understand 
the calling convention (I think it comes from old windows 3.0 days).  So 
I didn't encounter any difficulties with the original version of 
bbTablet.  But if I ever get the chance I would definitely like to 
overhaul it for D (or actually give it a C API so that I can wrap it up 
for both D and Python use).  And that's why I asked you in my first 
message of this thread to describe what you had to do to call the wintab 
functions.  Still interested in knowing that, BTW.

On the other hand, if you've gotten something in D working, and are 
willing to share, I'd be happy to use that.  Are you going to make your 
tablet code available?


 I have no idea how many calling conventions there are - but since it's 
 pretty arbitrary how you pass the arguments I figure there are lots of 
 them, just few popular ones. A quick and certainly wrong Wikipedia 
 search gave me 15 for x86 only. A way to define the ABI (maybe name 
 mangling as well) would solve the problem once and for all. Put up a 
 project on dsource where ABI definitions are hosted and everybody can 
 submit anything they encounter in the wild. Any compiler, any weird 
 embedded processor, everything.
 
 Maybe it'll be possible with macros, I don't know. Maybe something like
 
 pragma(abi, "thiscall")
 {
     void opCall(this, param1, param2)
     {
          // here be assembler code for any calls with a this pointer and 
 2 parameters
     }
 }
 
 would be good.


I believe (but have no good evidence) that there are few enough actual 
calling conventions in use that it would be smarter in the long run to 
just make the compiler understand them all rather than creating a 
do-all, ultimately flexible, user-configurable system where 99.9% of all 
users will only use the built-ins anyway.


--bb
Dec 06 2007
parent Mike <vertex gmx.at> writes:
On Fri, 07 Dec 2007 01:12:37 +0100, Bill Baxter  
<dnewsgroup billbaxter.com> wrote:


 Bummer.  As might be expected, Microsoft's C/C++ compilers understand  
 the calling convention (I think it comes from old windows 3.0 days).  So  
 I didn't encounter any difficulties with the original version of  
 bbTablet.  But if I ever get the chance I would definitely like to  
 overhaul it for D (or actually give it a C API so that I can wrap it up  
 for both D and Python use).  And that's why I asked you in my first  
 message of this thread to describe what you had to do to call the wintab  
 functions.  Still interested in knowing that, BTW.


In C:

UINT API WTInfoA(UINT wCategory, UINT nIndex, LPVOID lpOutput);

In D:

extern (Pascal) typedef UINT function(void *lpOutput, UINT nIndex, UINT  
wCategory) WTInfoFunc;

Give it extern (Pascal) and reverse the definition of the arguments.


 On the other hand, if you've gotten something in D working, and are  
 willing to share, I'd be happy to use that.  Are you going to make your  
 tablet code available?


Can do. But it'll take some time - I'm planning to release a GUI-less  
proof-of-concept-release of my VST host in about two weeks, after that  
I'll work on the Wintab bindings again.


 I believe (but have no good evidence) that there are few enough actual  
 calling conventions in use that it would be smarter in the long run to  
 just make the compiler understand them all rather than creating a  
 do-all, ultimately flexible, user-configurable system where 99.9% of all  
 users will only use the built-ins anyway.


Hmm. Maybe you're right. thiscall and the "Pascal reversed" one are the  
only ones I've seen that aren't supported by DMD.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Dec 06 2007
prev sibling parent reply Mike <vertex gmx.at> writes:
On Thu, 06 Dec 2007 18:26:24 +0100, Bill Baxter  =

<dnewsgroup billbaxter.com> wrote:


 Mike wrote:

  What's a better alternative to XML? I mean generally, not for this  =





 proposal. I'd really like to know that - a format that can represent =




 =


 trees easily and is easily readable.


 Lisp.
 Or YAML, or JSON.  All much more readable than XML.


Hmm ... thanks for the suggestions. I've asked because I've based my pet=
  =

project on XML ...
Maybe I've just done too much HTML to find XML more readable than YAML. =
 =

And JSON ... maybe I've done too much HTML to hate everything that's  =

related to JavaScript :)

Here's the actual plugins.xml file I currently generate and use:

<?xml version=3D"1.0" encoding=3D"UTF-8"?>
<!-- Alison Audiolab Plugin Database -->
<plugindb>
     <plugin type=3D"VST" uniqueId=3D"ANGE" name=3D"Angelina" vendor=3D"=
Big  =

Tick">C:\Programme\Ableton\vsti\angelina\angelina.dll</plugin>
     <plugin type=3D"VST" uniqueId=3D"adl1" name=3D"Analogic Delay"  =

vendor=3D"Daniel Bosshard">C:\Programme\Ableton\vsti\dubtools\Analogic  =

Delay.dll</plugin>
     <plugin type=3D"VST" uniqueId=3D"bdl1" name=3D"Bionic Delay" vendor=
=3D"Daniel  =

Bosshard">C:\Programme\Ableton\vsti\dubtools\Bionic Delay.dll</plugin>
[snip]
</plugindb>

Later on there should be support for other plugin types (a native plugin=
  =

format using DDL, DirectX, Buzz if I get extern (C++) to work with Buzz =
 =

plugins, LADSPA if I ever port to Linux, etc.) and every type needs othe=
r  =

attributes. Doesn't XML suit this perfectly?

-Mike

-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Dec 06 2007
parent reply Derek Parnell <derek nomail.afraid.org> writes:
This is a style that I'm getting some traction with ...

(* Alison Audiolab Plugin Database)
(plugindb
   (plugin (type VST) (uniqueId ANGE) (name Angelina) (vendor Big Tick)
           C:\Programme\Ableton\vsti\angelina\angelina.dll
   )
   (plugin (type VST) (uniqueId adl1) (name Analogic Delay)
           (vendor DanielBosshard)
           C:\Programme\Ableton\vsti\dubtools\Analogic Delay.dll
   )
   (plugin (type VST) (uniqueId bdl1) (name Bionic Delay) 
           (vendor Daniel Bosshard)
           C:\Programme\Ableton\vsti\dubtools\Bionic Delay.dll
    )
)



-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
7/12/2007 9:10:37 AM
Dec 06 2007
next sibling parent Mike <vertex gmx.at> writes:
On Thu, 06 Dec 2007 23:16:43 +0100, Derek Parnell  
<derek nomail.afraid.org> wrote:


 This is a style that I'm getting some traction with ...

 (* Alison Audiolab Plugin Database)
 (plugindb
    (plugin (type VST) (uniqueId ANGE) (name Angelina) (vendor Big Tick)
            C:\Programme\Ableton\vsti\angelina\angelina.dll
    )
    (plugin (type VST) (uniqueId adl1) (name Analogic Delay)
            (vendor DanielBosshard)
            C:\Programme\Ableton\vsti\dubtools\Analogic Delay.dll
    )
    (plugin (type VST) (uniqueId bdl1) (name Bionic Delay)
            (vendor Daniel Bosshard)
            C:\Programme\Ableton\vsti\dubtools\Bionic Delay.dll
     )
 )


So that's what's meant by LISP style ... very nice. That's really much  
easier on the eyes than XML.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Dec 06 2007
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Derek Parnell wrote:

 This is a style that I'm getting some traction with ...
 
 (* Alison Audiolab Plugin Database)
 (plugindb
    (plugin (type VST) (uniqueId ANGE) (name Angelina) (vendor Big Tick)
            C:\Programme\Ableton\vsti\angelina\angelina.dll
    )
    (plugin (type VST) (uniqueId adl1) (name Analogic Delay)
            (vendor DanielBosshard)
            C:\Programme\Ableton\vsti\dubtools\Analogic Delay.dll
    )
    (plugin (type VST) (uniqueId bdl1) (name Bionic Delay) 
            (vendor Daniel Bosshard)
            C:\Programme\Ableton\vsti\dubtools\Bionic Delay.dll
     )
 )


It sure looks like lisp/scheme sexprs.
Is there more to it than that?
By traction do you mean you have a library and/or spec and people 
besides you are starting to use it?  If please let us know more.  The 
sooner XML dies the better.  :-)  Can it be translated 1-to-1 to and 
from XML?  I think that's key for any would-be XML killer.  You've got 
to give the XML addicts an easy way to wean themselves off of it. 
Automatic translators would be a big help.

--bb
Dec 06 2007
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Derek Parnell" <derek nomail.afraid.org> wrote in message 
news:4at1wkm5t6w6.1v2bj3yu4mqy9$.dlg 40tude.net...

 This is a style that I'm getting some traction with ...

 (* Alison Audiolab Plugin Database)
 (plugindb
   (plugin (type VST) (uniqueId ANGE) (name Angelina) (vendor Big Tick)
           C:\Programme\Ableton\vsti\angelina\angelina.dll
   )
   (plugin (type VST) (uniqueId adl1) (name Analogic Delay)
           (vendor DanielBosshard)
           C:\Programme\Ableton\vsti\dubtools\Analogic Delay.dll
   )
   (plugin (type VST) (uniqueId bdl1) (name Bionic Delay)
           (vendor Daniel Bosshard)
           C:\Programme\Ableton\vsti\dubtools\Bionic Delay.dll
    )
 )



 -- 
 Derek
 (skype: derek.j.parnell)
 Melbourne, Australia
 7/12/2007 9:10:37 AM


Hell, use I-exprs and it becomes even more amazing:

(* Alison Audiolab Plugin Database)

plugindb
   plugin
      (type VST)
      (uniqueId ANGE)
      (name Angelina)
      (vendor Big Tick)
      C:\Programme\Ableton\vsti\angelina\angelina.dll

   plugin
      (type VST)
      (uniqueId adl1)
      (name Analogic Delay)
      (vendor DanielBosshard)
      C:\Programme\Ableton\vsti\dubtools\Analogic Delay.dll

   plugin
      (type VST)
      (uniqueId bdl1)
      (name Bionic Delay)
      (vendor Daniel Bosshard)
      C:\Programme\Ableton\vsti\dubtools\Bionic Delay.dll
Dec 06 2007
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:fja5t0$2ld0$1 digitalmars.com...


 Hell, use I-exprs and it becomes even more amazing:

 (* Alison Audiolab Plugin Database)

 plugindb
   plugin
      (type VST)
      (uniqueId ANGE)
      (name Angelina)
      (vendor Big Tick)
      C:\Programme\Ableton\vsti\angelina\angelina.dll

   plugin
      (type VST)
      (uniqueId adl1)
      (name Analogic Delay)
      (vendor DanielBosshard)
      C:\Programme\Ableton\vsti\dubtools\Analogic Delay.dll

   plugin
      (type VST)
      (uniqueId bdl1)
      (name Bionic Delay)
      (vendor Daniel Bosshard)
      C:\Programme\Ableton\vsti\dubtools\Bionic Delay.dll


Actually it doesn't seem like you need the parens at all for those inner 
ones.  I'm probably reading the Scheme RFC wrong tho 
(http://srfi.schemers.org/srfi-49/srfi-49.html if someone wants to correct 
me?).
Dec 06 2007
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Mike wrote:

 <image name="screenshot.bmpx" width="800px" height="600px">
 [snip]
 <pixel id="D7A9-192B-48AD-F348" xpos="543" ypos="438" 

 [snip]
 </image>


Gregor wrote a converter to & from a similar format:
http://www.codu.org/rxml.php

It's useful for the web and other places where readability is paramount.
Dec 06 2007
parent reply Mike <vertex gmx.at> writes:
On Thu, 06 Dec 2007 19:18:35 +0100, Robert Fraser  =

<fraserofthenight gmail.com> wrote:


 Mike wrote:

 <image name=3D"screenshot.bmpx" width=3D"800px" height=3D"600px">
 [snip]
 <pixel id=3D"D7A9-192B-48AD-F348" xpos=3D"543" ypos=3D"438"  =






 [snip]
 </image>


 Gregor wrote a converter to & from a similar format:
 http://www.codu.org/rxml.php

 It's useful for the web and other places where readability is paramoun=


t.

Ah! Just what I was waiting for :)

-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Dec 06 2007
parent reply "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Thu, 06 Dec 2007 18:42:47 -0000, Mike <vertex gmx.at> wrote:


 On Thu, 06 Dec 2007 19:18:35 +0100, Robert Fraser  =



 <fraserofthenight gmail.com> wrote:


 Mike wrote:

 <image name=3D"screenshot.bmpx" width=3D"800px" height=3D"600px">
 [snip]
 <pixel id=3D"D7A9-192B-48AD-F348" xpos=3D"543" ypos=3D"438"  =








 [snip]
 </image>


 Gregor wrote a converter to & from a similar format:
 http://www.codu.org/rxml.php

 It's useful for the web and other places where readability is paramou=




nt.

 Ah! Just what I was waiting for :)


You play the deadpan very well but this is still a sick joke.
Dec 06 2007
parent Mike <vertex gmx.at> writes:
On Fri, 07 Dec 2007 01:44:04 +0100, Bruce Adams  =

<tortoise_74 yeah.who.co.uk> wrote:


 On Thu, 06 Dec 2007 18:42:47 -0000, Mike <vertex gmx.at> wrote:


 On Thu, 06 Dec 2007 19:18:35 +0100, Robert Fraser  =





 <fraserofthenight gmail.com> wrote:


 Mike wrote:

 <image name=3D"screenshot.bmpx" width=3D"800px" height=3D"600px">
 [snip]
 <pixel id=3D"D7A9-192B-48AD-F348" xpos=3D"543" ypos=3D"438"  =










 [snip]
 </image>


 Gregor wrote a converter to & from a similar format:
 http://www.codu.org/rxml.php

 It's useful for the web and other places where readability is  =







 paramount.


 Ah! Just what I was waiting for :)


 You play the deadpan very well but this is still a sick joke.


http://forums.worsethanfailure.com/forums/thread/138582.aspx

-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Dec 06 2007