>
> On 14 mrt 2005, at 11:11, [EMAIL PROTECTED] wrote:
>
>>> I would only see the use of being able to pass a local function as a
>>> callback
>>> if the called function can be used for both local and global callback
>>> procedures.
>>
>> It can. When a global proc is passed, the static link is set to nil.
>
> That is not possible, because the static link parameter is currently
> passed as an implicit hidden *first* parameter. If you start passing an
> extra first parameter with the value "nil" to procedures, you'll get
> all sorts of strange effects.
>
> The PPC ABI actually prescribes that the static link parameter should
> always be passed in r11 (which can never be used for any other
> parameter, since regular parameters stop at r10), so then this works.
> However, in that respect we don't follow the PPC ABI, and it would also
> break on other processors so that's not an option.
I agree. As little ABI dependancy as possible.
> The only possibility I see for this is to make the hidden static link
> parameter the last instead of the first parameter.
What I was thinking of was to check for nil, when the procedure parameter
is about to be called. If the static link is nil, it is a global proc, and
it is called as such, if not nil it is called as a local proc.
But this mean there must be two separate code chuncks which sets up the
parameters, since for the local variant the first must be the static link.
Example Powerpc with static link first:
local
static link r3
param no 1 r4
...
global
param no 1 r3
...
To avoid this problem, it would be better to have the static link last.
For an ABI which passes everything on the stack this would not have been
any problem since paremeters are just pushed to the stack, and the push
instructions is relative. Perhaps Wirth did have this kinds of
architectures in mind when designing Pascal.
Olle
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
