Hi,
New to this list, so please excuse any glaring stupidity.
<such as posting this direct to Dan instead of the list, sorry>
I've been thinking about porting a small language to run on parrot,
and the call/return conventions. This is what I plan to do, at least
for my local routines. I'll follow the rules a bit more closely for
globals and external calls (but not this week).
I'd be interested to see what sort of signature changes between
compile and runtime you think are likely to happen, as I have to admit
I have never encountered such a beast. Doesn't that force
non-prototyped calls?
As I understand it, the requirements are:
Call a routine explicitly and be as efficient as possible/practical.
You know what the parameters are and where they should go.
Call a routine indirectly given two items:
The address of the routine, and
A list (or similar structure) of the parameters.
You don't know, and you probably don't care what they are.
Generally speaking, efficiency in this case is less important.
Optional parameters in both calling methods.
Without optional parameters I will simply translate as follows:
procedure fred(integer x, string y)
to:
_u_fred:
I5=P3[1]
S5=P3[2]
_fred:
Basically, replace the 0/1 prototype flag with a mangled label.
Yes/no?
For optional parameter handling, I will do something like:
procedure fred(integer x=0, string y="Default")
_u_fred:
length I1, P3 # total number of params
lt I1, 1, _fred
I5=P3[1]
lt I1, 2, _fred
S5=P3[2]
_fred:
eq I1, 2 fred_main # where 2 is max_params
set S5 "Default"
eq I1, 1 fred_main
set I5 0
fred_main:
In this first stab, all optional parameters must be grouped on
the rhs. Not sure yet how much more complicated it gets if not.
I don't know what games might need to be played with overflow
parameters in P3, I can imagine needing to extend a short P3 with
some defaults and chop off the first 11 somewhere in _u_fred.
Any comments?
Pete
