Re: Parameter Passing Via Registers

I wrote
>> ... Conceivably, this could be done even if the
>>procedure is passed as a parameter -- just make sure the register value is
>>part of the closure that you pass.
>>
>>I'm not claiming it's worth the trouble...


Michael Gschwind replies
>You write that "this could be done even if the procedure is passed as a
>parameter". This is not correct in the general case, and the case you line
>out, namely "just make sure the register value is part of the closure that
>you pass", is not feasable. Procedures passed as parameters can be called
>from just about any context, e.g., library functions, separately compiled
>modules etc., thus you cannot change the calling sequence. In the case of
>functions passed as parameters/procedure typed variables, you always have
>to have a standardized calling sequence.


The discussion is worth continuing only in that it illustrates
a very important principle of compiler implementation:
      you can make things work just about any way you want
      as long as you are pigheaded enough to keep at it.
      "In the world of mules,
        there are no rules" -- Ogden Nash


In this case, the function passed as a parameter will have to help set up
its own environment. Essentially you would construct a thunk that sets up
the environment and then calls the funciton; the thunk would then get
passed instead of the original.


You probably have to do this sort of thing anyway, if you are passing
Pascal procedures to library functions, since the library is probably
going to assume a C style pointer to function, with no environment of any
sort. (ah, but where does the thunk get the environment data in this case?
Left as an exercise to the reader)


Like I said, I continue the discussion not because I think anyone cares
about leaving values in registers for use by nested procedures that are
passed as callback functions to Xt library routines, but because one often
hears the statement "it is impossible for a compiler to accomplish X, or
to use technique Y for language Z." Usually such statements are not true.
One simply has to think a little harder, change some other assumptions,
and sometimes build a huge cumbersome mechanism to do it. And then decide
whether it is worth it.


--
Jon Mauney, parsing partisan
Computer Science Dept.
N.C. State University
--

Return to the comp.compilers page.
Search the comp.compilers archives again.