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
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
