On Wed, Jul 12, 2000 at 10:03:53PM +0100, Michael Hudson wrote: > Paul Prescod <paul@prescod.net> writes: > > Thinking some more... > > > > If we had first class range syntax then it would be relatively easy to > > recognize the pattern > > > > for i in [x:y:z]: > > .... > > > > Then we could generate a special FOR_INTS bytecode. I've heard that "C" > > has a pretty efficient implementation of that construct. <wink> > Hmm, yes, but how on earth would you implement that in ceval.c? You'd > need another eval loop inside the code for FOR_INTS! (unless I'm > being dense, of course). Nah. We can't use the C for-loop for this, unless the bytecode interpreter is entirely rewritten. The FOR_INT opcode would be something like: on entry, stack contains r, i where r is range-object specifying (start/)step/end, i is loop counter i is incremented by step, checked against end, and if loop hasn't ended yet, r, new 'i' and old 'i' are pushed on the stack, so it contains: r, i+step, i and the rest of the bytecode can remain the same (assign top value to name, etc.) > To invent more statistics on the spot, I'll declare that loop overhead > is a problem in about 3.4% of all interesting loops; what we need is a > way to execute the body quicker... define 'problem' ;) If we can speed things up while keeping the functionality the same, the syntax clearer and the code only slightly more complicated, why not ? :-) Granted, though, if the issue is overall code speed, this isn't going to cut it. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4