[fpc-pascal] how FPC expects string/interface/variant results?

[Tomas Hajny]

Alexandre Leclerc wrote:
> 2006/11/1, Tomas Hajny <XHajT03 at mbox.vol.cz>:
>> Jonas Maebe wrote:
>> > On 01 Nov 2006, at 14:30, Alexandre Leclerc wrote:
>> >
>> >> - Can you find out how FPC expects string/interface/variant results ?
>> >>
>> >> Is there documentation where I could get this information? I think it
>> >> is about cpu registers, etc. (?)
>> >>
>> >> Also, I might ask, how does FPC expect parameters passing? And
>> Methods
>> >> parameter passing?
>> >
>> > This depends on the used calling convention. Especially on i386 there
>> > are many different ones. And from time to time this also changes to
>> > fix compatibility or performance issues. There is no definite
>> > documentation for this apart from the compiler source (which isn't
>> > easy to read, in particular if you are not even sure about concepts
>> > like cpu registers and how they can be used for parameter passing),
>> > or compiling test programs and looking at the generated assembler
>> > code (idem).
>>
>> Although the documentation of calling conventions isn't complete, it's
>> probably worth to mention, that at least part of this information is
>> available in our Programmer's Guide (section Calling Conventions/Calling
>> mechanism). Additional information may be found in our mailing list
>> archive
>> (http://community.freepascal.org:10000/lists/fpc-pascal/2004-May/006960.html).
>
> I can read 'There are three calling conventions which have been used
> as the default in different versions of FPC'.

That's in other words what Jonas wrote too. Only two of them in stable
versions/releases, though, and no changes within one major release number
(i.e. one default convention for 1.x and another for 2.x).


> Will there be a final choice? Maybe my problem is that the calling
> convention has changed lately?

Not that recently - the calling convention hasn't changed during 2.x
lifetime. Moreover, you can still force the old behaviour, i.e. you aren't
required to change your code necessarily. However, the newer convention is
faster, which is the main reason for switching to it as new default. On
top of that, there were some minor changes required for proper
compatibility of the same calling convention with other compilers (bug
fixes). We don't expect to change the current default any more (although
we cannot guarantee that fully), and almost certainly not within 2.x
series. However, it should be always possible for you to keep using the
calling convention supported at one stage even in the future (regardless
of potential future changes of a default one).

Tomas