[fpc-devel] Local procedures as procedural parameter

[Jonas Maebe]

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.

> Note: Also thinking with things like "On x86" is the wrong way for 
> current
> FPC. It should be possible to support things (without hacks) on all
> supported CPUs.

That's why I mentioned x86, because afaik it's the only one where the 
callee removes the parameters from the stack instead of the caller.


Jonas