Dan wrote: >At 10:43 AM -0400 7/29/02, Melvin Smith wrote: >>At 10:45 AM 7/29/2002 +0100, Nicholas Clark wrote: >>The VM and assembler does not need to provide every operator as >>an new 'op'. Eventually, languages with funky operators need to start thinking >>about implementing them as methods or such. > >This is definitely true, for ease of use and maintenace if nothing >else. However, if a language does want to provide ops for its >operators, that's not really something we should care about. Also, >the one big upside to ops is that they're JITtable, where method >calls aren't.
Aha! You said it yourself, instructions are JITtable. So why shouldn't we concentrate on providing enough _primitives_ to allow people to write anything and everything in Parrot. New ops then become JITable and the upside is there is no language specific ops file needed. That way any language compiling to Parrot will run on any Parrot with standard ops. >Ultimately doing things as a (dynamically loaded) op will make the >running of the code faster, since op calls are lower overhead than >method calls. The runtime will likely be smaller as well. The >downside is a larger compiler side. The other downside is that Parrot turns into a Linux kernel and forever accumulates custom ops, PMCs. I think of Parrot as a CPU. When we have adequately designed the CPU, people don't need new ops. -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984
