Re: [pypy-dev] oopspec
Hi Antonio,
On Wed, May 03, 2006 at 01:00:28AM +0200, Antonio Cuni wrote:
I'm unsure about using 'delslice': it make me think that such an
operation behave exactly like the corresponding python statement, but
that was not my intent: in my mind the difference between 'remove_range'
and 'delslice' is that the first doesn't handle negative indexes and so
it is likely that the target has some built-in method that implement it
natively.
I remember thinking about this that the hint not negative could be
specified somewhere in addition to the basic oopspec:
def ll_getitem_nonneg(func, l, index):
...
ll_getitem_nonneg.oopspec = 'list.getitem(l, index)'
ll_getitem_nonneg.oopspechint = {'index': '=0'} #
def ll_getitem(func, l, index):
...
ll_getitem.oopspec = 'list.getitem(l, index)'
The point is that a backend can ignore the hint and implement a general
getitem operation that accepts negatives and raises IndexError, or
select a more optimized version if it's got one when it sees the hint.
Also, note that all our slice operations at RPython level assume that
indices are non-negative, with a special exception for exactly x[:-1].
(see rslice.py)
A bientot,
Armin
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
[pypy-dev] oopspec
Is there some documentation on oopspec attribute? How one may use it in the backend? Seo Sanghyeon ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] oopspec
Hi Seo, Sanghyeon Seo wrote: Is there some documentation on oopspec attribute? How one may use it in the backend? I think there are no docs about the oopspec attribute. Armin wrote these lines some time ago to respond to the same question: The oopspec string tells what is the abstract list operation that this particular ll_*() function implement. For example: def ll_prepend(l, newitem): ... ll_prepend.oopspec = 'list.insert(l, 0, newitem)' means that ll_prepend() is equivalent to an insert with the index set to zero. In the stirng, the pseudo-arguments between the ( ) are either real argument names of the ll_ function, or constants. So for example, if a backend has got its own way to implement the insert() calls in general, it could figure out from the oopspec that the ll_prepend() helper can be replaced by a custom stub invoking the backend's own version of insertion with an index of 0. That's essentially what the JIT does -- see handle_highlevel_operation() in jit/hintannotator/model.py. The CLI backend uses the oopspec attribute for replacing calls to selected low-level helpers with native builtin methods; the code is still very experimental since it doesn't parse the argument line: it simply forwards the call using the first parameter as the target object and subsequent parameters as method's arguments. By now the only recognized oopspec is 'list.append' (i.e., ll_append) that is translated to the 'Add' method. If you want to look at my code see translator/cli/oopspec.py and the _Call.render method in translator/cli/metavm.py; at the moment I put these files in the cli/ directory, but they are general enough to be shared among multiple backends (metavm would be useful only for backends emitting bytecode, so not for gencl nor gensqueak, I guess). The rationale behind this is that this way a backend can quickly gain full list support by simply supply basic operations such as ll_getitem_fast Co; then each backend can choose what operation to optimize based on their knowledge of the target system. Btw, I have a doubt about oopspec, too: Armin told that the 'oopspec' specifies the abstract operation that each ll_* helper implements; does this abstract operation have to be one of standard list methods or can I add new operations? I was thinking to add a 'll_remove_range' or similar to be used by other helpers such as delslice and company; this way backends can replace ll_remove_range with their almost-surely-present equivalent without having to care about python-specific logic such as slices or so. ciao Anto ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] oopspec
Hi Antonio, On Tue, May 02, 2006 at 12:01:27PM +0200, Antonio Cuni wrote: Btw, I have a doubt about oopspec, too: Armin told that the 'oopspec' specifies the abstract operation that each ll_* helper implements; does this abstract operation have to be one of standard list methods or can I add new operations? I was thinking to add a 'll_remove_range' or similar to be used by other helpers such as delslice and company; this way backends can replace ll_remove_range with their almost-surely-present equivalent without having to care about python-specific logic such as slices or so. It's quite open; every piece of code using oopspec should be prepared to see names that it doesn't know about, and ignore them. So feel free to add new names. As a guideline, let's stick as far as possible to the Python name for the method or for the __xxx__ special method name (with __ removed): 'remove_range' looks like it could be called 'delslice' in oopspec. A bientot, Armin ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] oopspec
Hi Armin Armin Rigo wrote: It's quite open; every piece of code using oopspec should be prepared to see names that it doesn't know about, and ignore them. So feel free to add new names. As a guideline, let's stick as far as possible to the Python name for the method or for the __xxx__ special method name (with __ removed): 'remove_range' looks like it could be called 'delslice' in oopspec. I'm unsure about using 'delslice': it make me think that such an operation behave exactly like the corresponding python statement, but that was not my intent: in my mind the difference between 'remove_range' and 'delslice' is that the first doesn't handle negative indexes and so it is likely that the target has some built-in method that implement it natively. Btw I have not thought to it too much, so I don't know if such a refactoring is worth the pain: maybe it is simply more effective to write a delslice method in C# (or whatever language fit other backends) and forwarding the hypothetic 'delslice' to it, even it would mean that each backend has to write its own implementation if they don't get satisfaction with the default one. ciao Anto ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
