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