Oops, on-list again. On Monday 08 October 2001 12:12 am, Michael Fischer wrote: > > It is generated as a pass over basic_opcodes.ops, just as the function > definitions in basic_opcodes.c are done. I figured the philosophy was > "Don't hack the output, hack the template" if you want to change the > generated file. What swapping of opcodes do you imagine? I wouldn't have > thought that user code gets to muck with the asm offerings available.
Every compilation unit (like a module, for instance) carries some or all of its own opcode table with it. These are switched out as the scope of the compilation unit changes. External code can and will define their own opcode functions, much in the same way that basic_opcodes.ops defines the default ones for the Parrot interpreter. However, to remove the necessity of opcode numbering coordination, the opcodes are arbitrarily numbered per compilation unit. So opcode 220 in Foo.pm may be a "leading 0" bit test, while opcode 220 in Bar.pm may be pipe creation. As the interpreter loads new code at runtime, it needs to be able to load and dispatch the new opcode. That's why within the current DO_OP loop, you dereference the current function table list from the interpreter structure. > > > Second, the switch will undoubtedly grow too large > > to be efficient. A full switch with as few as 512 branches already > > shows signs of performance degradation. [1] Thirdly, any function calls > > that you then *do* have to make, come at the expense of the switching > > branch, on top of normal function call overhead. > > How many asm opcodes do you imagine we'll have? I'm hardly expert here, > but I have a hard time believing we're going to have anything like 512. > Much of the remaining flexibility would be done in the vtable code. > Unless of course, _every_ new vtable function has to be re-written as > a single opcode... oh dear ... but now I'm getting confused. No. Each PMC opcode will in turn call a vtable op, which invariably will call one of our core ops. How many will there be? Perl 5 currently has over 300, and that doesn't include *anything* regex related (besides m// and s///), which Larry has already deemed will be handled as ops. I estimate that the core interpreter will provide over 800 individual opcodes. (Remember, everything is an opcode, from variable creation to scope deletion.) We can mitigate that by segmenting the opcodes into families. For instance, let's say the most efficent dispatch is via a switch no longer than 256 branches. Since regular expression ops are most likely going to occur mostly in conjunction with other regular expression ops, then we can switch to an alternate dispatch loop where the switch is populated with regex opcode handlers. (Assuming that they're invariant. See below.). Less frequently called opcodes, or opcodes that are already timely, can be relegated forever to function table lookup. > > As I understand it, all the function calls get inlined into the loop, > so what ones are going to be called inside it? Opcodes that are invariant, frequent, and quick. Invariant - Two integers add together only one way. I/O input may be done any number of ways. Frequent - basic math ops occur often. Exit does not. Quick - bit-wise manipulaton of integers should be quick.. Sleep doesn't need to be. The first of each are good candidates for inlining into the switch. The second are not. > > Sorry if I'm being dim and missing issues, I just wanted to get > this thing done, and I followed instructions. Perhaps needs/designs have > changed since instructions were given. Perhaps they have. The above is the last design direction that I'm aware of. > > Um, the latter's include file looks an awful lot like the switch > my patch generates. How does it work better? Not trying to be > antagonistic, I just don't see how it is any different/faster. The switch itself, yes. That's why I didn't point you to that. ;-) You solution should be as fast as the last set that I benchmarked. (Faster even, because the last tweak I made isn't in there, and I am doing the extra comparison.) But you will need to eventually address adding and overriding opcodes, which I don't believe your approach does well. (Which does make the difference.) -- Bryan C. Warnock [EMAIL PROTECTED]
