[fpc-devel] Local procedures as procedural parameter

[Peter Vreman]

>
> On 16 Mar 2005, at 21:46, Peter Vreman wrote:
>
>>> Then you can do it just as well on ppc and other processors, but the
>>> point of the trick was to avoid having to do this. Implementing this
>>> sort of hacks will complicate the code generator (I'm not even
>>> immediately sure how it would be implemented).
>>
>> This is a not possible. It is incompatible with Delphi calling
>> conventions
>> and not possible with register calling conventions.
>
> No, that's not true.
>
>> Also take into account
>>  that modes are per unit. And other units (like the RTL) are not in
>> gpc/macpas mode and don't expect the extra parameter and do not remove
>> it
>> from the stack.
>
> The idea was not to push it in the first place if it's nil. The problem
> is at the caller side: if that parameter is not nil, that means the
> procvar is a local parameter and it must be pushed (or loaded into a
> parameter register) when calling the procvar. If it's nil, then it
> means the procvar is a global procedure and it must not be pushed
> (idem).
>
>> Also generating code at runtime is a no-go for me. It is heavily CPU
>> and
>> OS dependent.
>
> No code would have to be generated, what would be required is in case
> of MacPas mode (and only for code compiled in MacPas mode) the
> insertion of a comparison with nil of a parameter and depending on that
> push it or not.

But the framepointer parameter must then be the last. That will make
macpas  local procedures incompatible with the current code where it is
passed as the first parameter. Things like the objects unit and FreeVision
will then be unusable, without the compiler being able to warn/error you
for that.

Also generating code for cdecl on x86 will become more complex:

push para1
..
push paraX
if isoprocvar.framepointer<>nil then
  push parentfp
call proc
dec stack,parasize_on_the_stack-sizeof(parentfp)
if isoprocvar.framepointer<>nil then
  dec stack sizeof(parentfp)