On Nov 30, 2005, at 22:16, Chip Salzenberg wrote:
Say, I just noticed this: On Wed, Nov 30, 2005 at 12:18:40PM +0100, Leopold Toetsch wrote:.sub foo push_eh handler get_params '(0)', $P0 # no .params yet - sorryI remember at one point that get_params had to be the first opcode in the sub. I didn't like that, but I didn't know you'd fixed it. Are there any remaining limitations on the placement of the pdd03 opcodes?
One small and not tested item is the placement of C<get_params> in subroutines called via tailcall*. But yes, there was a limitation that C<get_params> has to be the first opcode of a subroutine, which is already lifted vastly, as that opcode is now pulling arguments from the caller (before the 'invoke' did push args to the sub). It could be that (for tailcalled subs) above sequence or just get_params is ok. For other subs there are no limitations, but, as you don't know if the sub is being tailcalled ....
This limitation did prevent local exception handler - like above - to be created and is now gone.
I'm still trying to consolidate all the calling conventions stuff, e.g. which of these opcode are mandandatory for 'void' calls/returns. If a 'get_params' opcode is always needed, even with empty arguments, above restriction related to tailcalls is also gone.
The source comment is just related to the C<.params> syntax, which is strictly bound to the ".sub" due to imcc.y magic (or mis-magic) and should be easily fixable now since stack-calling .param can't interfer anymore.
leo
