[fpc-devel] Local procedures as procedural parameter
jonas at zeus.ugent.be
Wed Mar 16 22:08:20 CET 2005
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
> 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
> 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
> Also generating code at runtime is a no-go for me. It is heavily CPU
> 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
> 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.
More information about the fpc-devel