Menu
▾
▴
firebird-devel
|
From: Alex P. <pes...@ma...> - 2011-04-07 13:47:48
|
On 04/07/11 17:23, Daniel Rail wrote: > Hi, > > At April-07-11, 9:44 AM, Dmitry Yemanov wrote: > >> I believe some form of queryInterface/upgradeInterface is required in >> the API. But I don't think we should mimic IUnknown precisely without >> really strong reasons. First of all, we don't need GUIDs as interface >> version identifiers, as our objects are limited to Firebird only usage. >> And if Delphi is the only reason to be binary compatible with IUnknown, >> then I'm against it. Times change and now I'd pay more attention to >> Java/.NET along with Python/PHP/whatever than think how to please those >> poor Delphi users ;-) > Whatever the new style of the Firebird API will be, I'm sure that > Delphi will be able to handle it, as long as the data connection > developers(IB Objects, FIB Plus, Upscene, Embarcadero, Devart and > others) are kept in the loop. And, I've just learned that the new > Delphi 64-bit compiler(hopefully released later this year) will only > use fastcall for DLL interfaces(even Microsoft has that same > restriction for 64-bit). I remember at one point in all of this > discussion, there was talks about stdcall and cdecl for the DLL > interfaces, but with Delphi 64-bit, it will only support fastcall. > And, fastcall is also supported by Delphi 32-bit. Moreover, linux is also using fastcall for 64-bit modules. But fastcall is much different from both cdecl and stdcall, moreover it's a kind of other 'dimension' in calling conventions world. I.e. first N register-size parameters (N=6 for linux) are passed not on stack, but in CPU's registers. But for remaining (if we have >6) stdcall/cdecl once more comes to play - should stack pointer be restored by caller or by function? |
|
From: Vlad K. <hv...@us...> - 2011-04-08 06:56:59
|
> And, I've just learned that the new
> Delphi 64-bit compiler(hopefully released later this year) will only
> use fastcall for DLL interfaces(even Microsoft has that same
> restriction for 64-bit).
Where can i read about it ? Because i doubt fastcall is *only* supported
calling convention in Win64. Moreover, in COM. According to MSDN __fastcall
is MS-specific while COM have more wide scope. So, there is no possibility to
use anything else then stdcall in IUnknown despite of 32\64 bitness.
Delphi used "fastcall" as default calling convention for class methods for
a very long time and this is not new and not related to the x64. It is named
"register" in Delphi Help. Probably new marketing department decided to
rename good old "register" by new cool "fastcall" in still not released Delphi
x64 compiler :)
Am i wrong ?
Regards,
Vlad
|
|
From: Daniel R. <da...@ac...> - 2011-04-08 12:11:12
|
Hi, At April-08-11, 3:56 AM, Vlad Khorsun wrote: >> And, I've just learned that the new >> Delphi 64-bit compiler(hopefully released later this year) will only >> use fastcall for DLL interfaces(even Microsoft has that same >> restriction for 64-bit). > Where can i read about it ? Because i doubt fastcall is *only* supported > calling convention in Win64. Moreover, in COM. According to MSDN __fastcall > is MS-specific while COM have more wide scope. So, there is no possibility to > use anything else then stdcall in IUnknown despite of 32\64 bitness. https://forums.codegear.com/thread.jspa?threadID=52117 http://msdn.microsoft.com/en-us/library/ms235286.aspx http://www.embarcadero.com/products/delphi/64-bit (Here it is mentioned in the video presentation that only one calling convention will be supported in 64-bit, but unfortunately doesn't specifically mention which one. Which is where the speculation of fastcall/register originates, as mentioned in the Delphi forum thread, most likely because of the MSDN documentation.) And, here's another document that I found: http://www.agner.org/optimize/calling_conventions.pdf Look on page 16, in the paragraph starting with "Calling convention", the last line refers to 64-bit mode. > Delphi used "fastcall" as default calling convention for class methods for > a very long time and this is not new and not related to the x64. It is named > "register" in Delphi Help. Probably new marketing department decided to > rename good old "register" by new cool "fastcall" in still not released Delphi > x64 compiler :) > Am i wrong ? You are correct, it is "register" in Delphi, which looks to be the same as "fastcall" in C++, after reading the documentation. -- Best regards, Daniel Rail Senior Software Developer ACCRA Solutions Inc. (www.accra.ca) ACCRA Med Software Inc. (www.filopto.com) |
|
From: Vlad K. <hv...@us...> - 2011-04-08 13:42:24
|
> At April-08-11, 3:56 AM, Vlad Khorsun wrote: > >>> And, I've just learned that the new >>> Delphi 64-bit compiler(hopefully released later this year) will only >>> use fastcall for DLL interfaces(even Microsoft has that same >>> restriction for 64-bit). > >> Where can i read about it ? Because i doubt fastcall is *only* supported >> calling convention in Win64. Moreover, in COM. According to MSDN __fastcall >> is MS-specific while COM have more wide scope. So, there is no possibility to >> use anything else then stdcall in IUnknown despite of 32\64 bitness. > > https://forums.codegear.com/thread.jspa?threadID=52117 > http://msdn.microsoft.com/en-us/library/ms235286.aspx > http://www.embarcadero.com/products/delphi/64-bit (Here it is > mentioned in the video presentation that only one calling convention > will be supported in 64-bit, but unfortunately doesn't specifically > mention which one. Which is where the speculation of fastcall/register > originates, as mentioned in the Delphi forum thread, most likely > because of the MSDN documentation.) > > And, here's another document that I found: > http://www.agner.org/optimize/calling_conventions.pdf > Look on page 16, in the paragraph starting with "Calling convention", > the last line refers to 64-bit mode. Thanks. But, if this is true : "In 64 bit mode, there is only one calling convention for each operating system" then we have no problem with interfaces despite of compiler\language on x64 systems. I have no doubt it is true on Windows and modern Linuxes but have no idea about HPUX, AIX, Solaris, etc... Regards, Vlad |
|
From: Dimitry S. <sd...@ib...> - 2011-04-08 13:56:18
|
08.04.2011 15:42, Vlad Khorsun wrote: > Thanks. But, if this is true : "In 64 bit mode, there is only one calling convention for each > operating system" then we have no problem with interfaces despite of compiler\language > on x64 systems. Yep, if forget that current FB API, implemented in current fbclient.dll use stdcall and thus Delphi 64 won't be able to work with it. And if you change this calling convention to fastcall, all programs that already work with 64-bits client will be broken. -- SY, SD. |
|
From: Vlad K. <hv...@us...> - 2011-04-08 14:25:27
|
> 08.04.2011 15:42, Vlad Khorsun wrote:
>> Thanks. But, if this is true : "In 64 bit mode, there is only one calling convention for each
>> operating system" then we have no problem with interfaces despite of compiler\language
>> on x64 systems.
>
> Yep, if forget that current FB API, implemented in current fbclient.dll use stdcall and
> thus Delphi 64 won't be able to work with it. And if you change this calling convention to
> fastcall, all programs that already work with 64-bits client will be broken.
In Win64 stdcall is the same as thiscall, cdecl, register, fastcall, anythingelsecall.
Do you know that all Win32 API declared with stdcall ? Are you going to say that Delphi
Win64 applications wiil not be able to work with Win32 API at all ? :-D
There is no problem with calling conventions on x64 systems between modules by different
compilers as log as all compilers vendors follow the same rules about fastcall. And it seems
they follow.
Regards,
Vlad
|
|
From: Dimitry S. <sd...@ib...> - 2011-04-08 14:43:00
|
08.04.2011 16:25, Vlad Khorsun wrote: >> 08.04.2011 15:42, Vlad Khorsun wrote: >>> Thanks. But, if this is true : "In 64 bit mode, there is only one calling convention for each >>> operating system" then we have no problem with interfaces despite of compiler\language >>> on x64 systems. >> >> Yep, if forget that current FB API, implemented in current fbclient.dll use stdcall and >> thus Delphi 64 won't be able to work with it. And if you change this calling convention to >> fastcall, all programs that already work with 64-bits client will be broken. > > In Win64 stdcall is the same as thiscall, cdecl, register, fastcall, anythingelsecall. Translate, please. How is it possible? If caller push arguments into stack from left to right but callee expect them from right to left, what magic let them to work properly? Or you mean that our 64bits fbclient.dll already uses fastcall only? And any other third-party DLLs as well?.. I have no experience with 64bits compilers, that's why I ask... > Do you know that all Win32 API declared with stdcall ? Are you going to say that Delphi > Win64 applications wiil not be able to work with Win32 API at all ? :-D I don't. The person who said "only one calling convention will be supported in 64-bit" does. -- SY, SD. |
|
From: Vlad K. <hv...@us...> - 2011-04-08 15:15:11
|
> 08.04.2011 16:25, Vlad Khorsun wrote:
>>> 08.04.2011 15:42, Vlad Khorsun wrote:
>>>> Thanks. But, if this is true : "In 64 bit mode, there is only one calling convention for each
>>>> operating system" then we have no problem with interfaces despite of compiler\language
>>>> on x64 systems.
>>>
>>> Yep, if forget that current FB API, implemented in current fbclient.dll use stdcall and
>>> thus Delphi 64 won't be able to work with it. And if you change this calling convention to
>>> fastcall, all programs that already work with 64-bits client will be broken.
>>
>> In Win64 stdcall is the same as thiscall, cdecl, register, fastcall, anythingelsecall.
>
> Translate, please. How is it possible? If caller push arguments into stack from left to
> right but callee expect them from right to left, what magic let them to work properly?
This is compiler, who put argumets on stack, isn't it ? :)
> Or you mean that our 64bits fbclient.dll already uses fastcall only? And any other
> third-party DLLs as well?..
Yes. At least this is how i read papers above.
Regards,
Vlad
|
|
From: Dimitry S. <sd...@ib...> - 2011-04-08 15:26:08
|
08.04.2011 17:15, Vlad Khorsun wrote: > This is compiler, who put argumets on stack, isn't it ? :) Ok, ok. At last I realized that all compilers' authors have agreed and thus all compilers in the world work the same way. Thanks for explanation. -- SY, SD. |
|
From: Adriano d. S. F. <adr...@gm...> - 2011-04-08 15:00:24
|
On 08-04-2011 11:25, Vlad Khorsun wrote: >> 08.04.2011 15:42, Vlad Khorsun wrote: >>> Thanks. But, if this is true : "In 64 bit mode, there is only one calling convention for each >>> operating system" then we have no problem with interfaces despite of compiler\language >>> on x64 systems. >> >> Yep, if forget that current FB API, implemented in current fbclient.dll use stdcall and >> thus Delphi 64 won't be able to work with it. And if you change this calling convention to >> fastcall, all programs that already work with 64-bits client will be broken. > > In Win64 stdcall is the same as thiscall, cdecl, register, fastcall, anythingelsecall. > > Do you know that all Win32 API declared with stdcall ? Are you going to say that Delphi > Win64 applications wiil not be able to work with Win32 API at all ? :-D > > There is no problem with calling conventions on x64 systems between modules by different > compilers as log as all compilers vendors follow the same rules about fastcall. And it seems > they follow. > If fastcall can handle functions with variable number of arguments, there is no problem then. The only affected applications would be the ones written in assembly. Adriano |
|
From: Alex P. <pes...@ma...> - 2011-04-08 15:42:55
|
On 04/08/11 19:00, Adriano dos Santos Fernandes wrote: > On 08-04-2011 11:25, Vlad Khorsun wrote: >>> 08.04.2011 15:42, Vlad Khorsun wrote: >>>> Thanks. But, if this is true : "In 64 bit mode, there is only one calling convention for each >>>> operating system" then we have no problem with interfaces despite of compiler\language >>>> on x64 systems. >>> Yep, if forget that current FB API, implemented in current fbclient.dll use stdcall and >>> thus Delphi 64 won't be able to work with it. And if you change this calling convention to >>> fastcall, all programs that already work with 64-bits client will be broken. >> In Win64 stdcall is the same as thiscall, cdecl, register, fastcall, anythingelsecall. >> >> Do you know that all Win32 API declared with stdcall ? Are you going to say that Delphi >> Win64 applications wiil not be able to work with Win32 API at all ? :-D >> >> There is no problem with calling conventions on x64 systems between modules by different >> compilers as log as all compilers vendors follow the same rules about fastcall. And it seems >> they follow. >> > If fastcall can handle functions with variable number of arguments, > there is no problem then. > Yes, it can. It stores first 4 (on linux 6) arguments in registers, the rest are stored on stack using cdecl conventions. |
|
From: Nikita K. <nn...@em...> - 2011-04-12 06:36:46
|
>Yes, it can. It stores first 4 (on linux 6) arguments in registers, the >rest are stored on stack using cdecl conventions. I must say, there is a difference in treatment of the stack between Windows and Linux systems. Windows not only passes the first 4 parameters in registers but ALWAYS allocates space on stack for them even if the callee doesn't have parameters at all. http://msdn.microsoft.com/en-us/library/ms235286(v=vs.80).aspx - see Calling conversion, the second paragraph. Linux by-term doesn't allocate additional space on stack for the first parameters. |
|
From: marius a. p. <ma...@gm...> - 2011-04-12 09:03:06
|
On Thu, Apr 7, 2011 at 4:23 PM, Daniel Rail <da...@ac...> wrote: > Hi, > > At April-07-11, 9:44 AM, Dmitry Yemanov wrote: > >> I believe some form of queryInterface/upgradeInterface is required in >> the API. But I don't think we should mimic IUnknown precisely without >> really strong reasons. First of all, we don't need GUIDs as interface >> version identifiers, as our objects are limited to Firebird only usage. >> And if Delphi is the only reason to be binary compatible with IUnknown, >> then I'm against it. Times change and now I'd pay more attention to >> Java/.NET along with Python/PHP/whatever than think how to please those >> poor Delphi users ;-) > > Whatever the new style of the Firebird API will be, I'm sure that > Delphi will be able to handle it, as long as the data connection > developers(IB Objects, FIB Plus, Upscene, Embarcadero, Devart and > others) are kept in the loop. And, I've just learned that the new > Delphi 64-bit compiler(hopefully released later this year) will only > use fastcall for DLL interfaces(even Microsoft has that same > restriction for 64-bit). I remember at one point in all of this > discussion, there was talks about stdcall and cdecl for the DLL > interfaces, but with Delphi 64-bit, it will only support fastcall. > And, fastcall is also supported by Delphi 32-bit. I come from qt/lazarus side and seems that with qt there is api for every type of scripting language also for lazarus :) and wrappers seems to be done easily http://doc.qt.nokia.com/qq/qq13-apis.html http://users.telenet.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html Another good api that i love how is defined is opengl there is the stone engraved api that works even after 10-15 years (c examples compiled on my machine without no modification) and there are extensions to the api where experimental api is done ps:we really need a really good c++ for flamerobin and other c++ toolkits :qt/wx How can i test the new api ? there is some doc or samples somewhere ? Damyan idea to use the ibpp on writing the perl driver wasn't so bad after all |
|
From: Alex P. <pes...@ma...> - 2011-04-12 12:23:51
|
On 04/12/11 13:02, marius adrian popa wrote: > How can i test the new api ? there is some doc or samples somewhere ? I'm afraid that it's not ready for tests. If you look at current samples, you\ll sooner of all say - it's awful. It's really not ready. |
|
From: Adriano d. S. F. <adr...@gm...> - 2011-04-12 15:18:51
|
On 12-04-2011 06:02, marius adrian popa wrote: > > ps:we really need a really good c++ for flamerobin and other c++ > toolkits :qt/wx > How can i test the new api ? there is some doc or samples somewhere ? > I'll soon publish some tests at https://github.com/asfernandes/fbstuff. Adriano |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X