Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!decwrl!shelby!neon!Kermit.Stanford.EDU!philip
From: philip@Kermit.Stanford.EDU (Philip Machanick)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Dereferencing ProcPtr in LS Pascal
Message-ID: <1990Feb4.202759.16223@Neon.Stanford.EDU>
Date: 4 Feb 90 20:27:59 GMT
References: <1268@diemen.cc.utas.oz>
Sender: news@Neon.Stanford.EDU (USENET News System)
Reply-To: philip@pescadero.stanford.edu
Organization: Computer Science Department, Stanford University
Lines: 56

I attempted to mail the following, but the original author's address
didnn't work. Treat this with care; it needs to be checked.

In article <1268@diemen.cc.utas.oz> brian Harrold writes:
>
>    I have a procedure in which one of the parameters is of type
>    ProcPtr (pointer to another procedure). Is there any way in
>    LS Pascal to dereference the pointer to the given procedure,
>    and execute it ?
>
> brian Harrold.
> brianh@tasis.utas.oz

The solution is along the following lines:

procedure callProc(** parameters exactly as in proc ** ; theProc:
procPtr);
inline $205F $4ED0 ;  {check the syntax for inline in LS manual}

You will need a different version of callProc for each different
parameter list.

I don't have an assembler, a working example, the LS manual or a Mac
handy: this is from memory and a Motorola assembly language manual. You
should check this. The two hexadecimal numbers represent the following
assembly language:

     movea.l (SP)+, A0   ; pop the procptr into register A0
     jmp     (A0)        ; jump to the address pointed to by register A0

The effect of these instructions is to get you into the code pointed to
by the procPtr, with the stack set up as if you had done a direct call
to the proc (including having the return address in the right place).

You should check in the LS manual that I am right in assuming you can
trash the A0 register (see the section about interface to assembly
langauge). Also, it would be a good idea to run the above through an
assembler to check my hand-translation to hexadecimal.

To call the procPtr proc, do the following:

     callProc(** parameters exactly as in proc **, @proc)

Because of the way non-local variables are referenced, you should
declare the callProc procedure at the outermost level of a unit or of
the main program (i.e., it should not be a local procedure). I think
the compiler enforces this rule for generating the procPtr with the @
operation.

I hope this helps. If you can at all avoid it, don't do this kind of
thing. If you need to pass procedures around as data, use the
object-oriented features of the latest LS compiler instead. This kind
of hack defeats the purpose of a high-level language.

Philip Machanick
philip@pescadero.stanford.edu