Armin Rigo <arigo@tunes.org> writes:

Some more refactoring would be nice here. I'm posting here something we discussed at the end of the latest sprint: from the point of view of decoding the arguments, a frame is just a repository of 'fast locals' slots. Hence the idea that instead of decoding arguments and building a real 'locals' dictionary, we directly put the arguments in a frame-like class. As it only makes sense to use a real PyFrame instance when we are about to call a Python (app-level) function, we could use a base class for the general case:

+ ActivationFrame + PyFrame [the current frame class] + BuiltinFrame

+ ExecutableCode [new proposed name for PyBaseCode] + PyCode [new proposed name for PyByteCode] + BuiltinCode [new proposed name for PyBuiltinCode]

ExecutableCode instances are used as the 'func_code' attribute of function objects; they would have methods to create an ActivationFrame instance of the correct corresponding class, and then the ActivationFrame's list of 'fast locals' would be populated with the generic ExecutableCode.build_arguments(). The base ActivationFrame is essentially nothing more than a 'fast locals' container. It is easy to either use that as the real 'fast locals' during interpretation in PyFrame, or pick the arguments from the list in BuiltinFrame to pass them to the built-in interpreter-level function. I think it looks like a nice way to minimize the number of times the arguments must be copied around.

<aol> me too </aol> Cheers, M. -- Clue: You've got the appropriate amount of hostility for the Monastery, however you are metaphorically getting out of the safari jeep and kicking the lions. -- coonec -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html

Armin Rigo <arigo@tunes.org> writes:

Some more refactoring would be nice here. I'm posting here something we discussed at the end of the latest sprint: from the point of view of decoding the arguments, a frame is just a repository of 'fast locals' slots. Hence the idea that instead of decoding arguments and building a real 'locals' dictionary, we directly put the arguments in a frame-like class. As it only makes sense to use a real PyFrame instance when we are about to call a Python (app-level) function, we could use a base class for the general case:

+ ActivationFrame + PyFrame [the current frame class] + BuiltinFrame

+ ExecutableCode [new proposed name for PyBaseCode] + PyCode [new proposed name for PyByteCode] + BuiltinCode [new proposed name for PyBuiltinCode]

ExecutableCode instances are used as the 'func_code' attribute of function objects; they would have methods to create an ActivationFrame instance of the correct corresponding class, and then the ActivationFrame's list of 'fast locals' would be populated with the generic ExecutableCode.build_arguments(). The base ActivationFrame is essentially nothing more than a 'fast locals' container. It is easy to either use that as the real 'fast locals' during interpretation in PyFrame, or pick the arguments from the list in BuiltinFrame to pass them to the built-in interpreter-level function. I think it looks like a nice way to minimize the number of times the arguments must be copied around.

<aol> me too </aol> Cheers, M. -- Clue: You've got the appropriate amount of hostility for the Monastery, however you are metaphorically getting out of the safari jeep and kicking the lions. -- coonec -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html