Suggestion for one more extern "C++" statement.

For other topics related to the FreeBASIC project or its community.
D.J.Peters
Posts: 7825
Joined: May 28, 2005 3:28

Suggestion for one more extern "C++" statement.

Postby D.J.Peters » Jun 20, 2011 14:34

It would be great to have one more extern "C++" statement.

extern "GNU C++" same as the current extern "C++"
and the missing extern "MS C++"

I don't talk about how fb should mangle the names
but the hidden this param must be in register ECX and not on the stack.
This differs from GNU C++ calling.

Code: Select all

extern "C++"
type GNU_CLASS
  Add as function (pThis as GNU_CLASS ptr, a as integer, b as integer)   
end type
end extern
FreeBASIC pushes 3 params on the stack and after the call it removes 3*4=12 bytes from stack.

Code: Select all

extern "MS-C++"
type MS_CLASS
  Add as function (pThis as MS_CLASS ptr, a as integer, b as integer)   
end type
end extern
now pThis should be ECX and FreeBASIC must only pop 2*4=8 bytes from stack.

Only a suggestion not a "must have".

Thats all my friends :-)

Joshy

MS C++ *.h

Code: Select all

class CLASS {   
public:
   int a,b,c;
   VIRTUAL int  DLLCALL GetA(){return a;}
   VIRTUAL int  DLLCALL  GetB(){return b;}
   VIRTUAL int  DLLCALL  GetC(){return c;}
   VIRTUAL void DLLCALL  SetA(int value){a=value;}
   VIRTUAL void DLLCALL  SetB(int value){b=value;}
   VIRTUAL void DLLCALL  SetC(int value){c=value;}
   CLASS(){  SetA(7);  SetB(8);  SetC(9); }
};

DLLDECL CLASS* DLLCALL CPPClassCreate();
DLLDECL void   DLLCALL CPPClassRelease(CLASS* &pClass);

MS C++ *.cpp

Code: Select all

LLDECL CLASS* DLLCALL CPPClassCreate() {
   CLASS*  pClass = new CLASS;
   return pClass;
}

DLLDECL void DLLCALL CPPClassRelease(CLASS* &pClass) {
   if (pClass) {
      delete pClass;
      pClass=0;
   }
}

FreeBASIC *.bas

Code: Select all

#define DLLNAME "CPPClasses"

#define _DF(n) declare function n cdecl lib DLLNAME alias #n
#define _DS(n) declare sub      n cdecl lib DLLNAME alias #n

#define THIS_CPPCLASS byref pTHIS as any ptr

function CPP_GET(pThis as any ptr,pFunc as any ptr) as integer
  asm
    mov ecx,[pThis]
    call [pFunc]
    mov [function],eax
  end asm
end function

sub CPP_SET(pThis as any ptr,pFunc as any ptr,value as integer) as integer
  asm
    mov ecx,[pThis]
    push [value]
    call [pFunc]
    pop eax ' only 4 bytes
  end asm
end sub

type FGET as function cdecl (THIS_CPPCLASS) as integer
type FSET as sub      cdecl (THIS_CPPCLASS, as integer)

type PFGET as FGET 'ptr
type PFSET as FSET 'ptr

type VFT ' virtual function table
  as PFGET GetA
  as PFGET GetB
  as PFGET GetC
  as PFSET SetA
  as PFSET SetB
  as PFSET SetC
end type
type PVFT as VFT ptr

extern "C"

type CPPCLASS
  as PVFT    pfunc
  as integer a,b,c
end type

end extern

_DF(CPPClassCreate) as CPPCLASS ptr
_DS(CPPClassRelease) (pClass as CPPCLASS ptr ptr)

dim as CPPCLASS ptr pClass = CPPClassCreate()
dim as any ptr pThis = pClass
print "GetA() 7 = h" & hex(CPP_GET(pThis,pClass->pFunc->GetA),8)
print "GetA() 8 = h" & hex(CPP_GET(pThis,pClass->pFunc->GetB),8)
print "GetA() 9 = h" & hex(CPP_GET(pThis,pClass->pFunc->GetC),8)
CPP_SET(pThis,pClass->pFunc->SetA,1)
CPP_SET(pThis,pClass->pFunc->SetB,2)
CPP_SET(pThis,pClass->pFunc->SetC,3)
print "GetA() 1 = h" & hex(CPP_GET(pThis,pClass->pFunc->GetA),8)
print "GetA() 2 = h" & hex(CPP_GET(pThis,pClass->pFunc->GetB),8)
print "GetA() 3 = h" & hex(CPP_GET(pThis,pClass->pFunc->GetC),8)

CPPClassRelease(@pClass)
sleep
dkl
Site Admin
Posts: 3209
Joined: Jul 28, 2005 14:45
Location: Germany

Postby dkl » Jul 01, 2011 12:53

It surely would be possible, although at the moment the compiler is pretty much focused on "this" being a parameter. Does mingw-gcc support it? I heard something about __thiscall, but I don't know whether that's it.
D.J.Peters
Posts: 7825
Joined: May 28, 2005 3:28

Postby D.J.Peters » Jul 01, 2011 19:51

I heard nothing about __thiscall :-)
but i wrote the PhysX cpp wrapper and modfy the wxWidget cpp wrapper and last but not least i mix FreeBASIC with cpp more than once for the Basic4GL cpp plugin system.

for my job i used VS 6 more than 10 years
and now i like the free VS Express IDE
the best and "trickist" IDE i saw ever

i will never touch the source code of FreeBASIC
i'm writing time by time the last two years my own compiler
and i'm using fasm as backend

if you don't know about fasm
fasm build fasm same as FreeBASIC
DOS, WINDOWS, LINUX only ~90KB 32 and 64 bit
but the best are you don't need a linker anymore for shared libs
(how cool is it ?)

back to the topic ;-) (i'm a litle bit drunken)
would be cool if you can put the hidden this pointer in ECX
inside of an extern "MS-C++" end extern scope

thank you for all of your work on FreeBASIC
i should say it more often :-)

Joshy
marcov
Posts: 2770
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » Jul 01, 2011 20:40

dkl wrote: I heard something about __thiscall, but I don't know whether that's it.


Roughly stdcall for methods, from

http://msdn.microsoft.com/en-us/library ... 80%29.aspx
:

"The __thiscall calling convention is used on member functions and is the default calling convention used by C++ member functions that do not use variable arguments. Under __thiscall, the callee cleans the stack, which is impossible for vararg functions. Arguments are pushed on the stack from right to left, with the this pointer being passed via register ECX, and not on the stack, on the x86 architecture.

One reason to use __thiscall is in classes whose member functions use __clrcall by default. In that case, you can use __thiscall to make individual member functions callable from native code."

__clrcall seems to be something for managed code, and probably isn't interesting at this stage.
cha0s
Site Admin
Posts: 5317
Joined: May 27, 2005 6:42
Location: Illinois
Contact:

Postby cha0s » Jul 08, 2011 22:30

Interesting. I guess that will be quite a bit faster.

I think you're right about __clrcall, aren't MS phasing out .NET in favor of HTML 5 for Windows 8 anyway? heh.
marcov
Posts: 2770
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » Jul 09, 2011 20:15

cha0s wrote:Interesting. I guess that will be quite a bit faster.


It used to, specially in 486 and maybe even P-I and compatibles (K6,6x86) times. Afaik the difference has in recent processors been mitigated a lot because the top of the stack is cached, and the complex instructions to load them cheaper.

Keep in mind that the calling conventions of stuff like MSVC are older than the 486. They don't necessarily reflect the current situation.

I think you're right about __clrcall, aren't MS phasing out .NET in favor of HTML 5 for Windows 8 anyway? heh.


Well, at the same early "anything to make a headline" stage of the development that would become Vista, they said they'd replace the filesystem with a database, and we all know how that turned out:-)

Anyway, if I understood it correctly native languages can interact in three ways with .NET,

1. by becoming managed
2. by becoming unmanaged language but built on top of the (native part) of the CLR runtime. No longer a win32/64 binary, but only as part of a CLR app.
3. by using COM.


While the proponents of "sharped" languages (xxx#) pretend otherwise, IMHO (1) is equal to creating a new language.

(2) is the category for which _clrcall matters. But most native language systems interact (3) via COM with .NET, and afaik clrcall is irrelevant then.

The category (2) is mostly interesting for Microsoft for CLR implementation purposes.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 3 guests