Too many opcodes
Bluntly, no. Not too many opcodes.
This has been an ongoing issue. I'm well aware that you want to to trim down the opcode count for ages and replace a lot of them with functions with a lightweight calling convention. Well, we already *have* that. We call them (wait for it) *opcodes*. That's one of the really big points of all this. You're micro-optimizing things, and you're not going the right way with it.
Yes, I'm well aware that the computed goto and switch cores are big, and problematic. The answer isn't to reduce the op count. The answer's to make the cores manageable, which doesn't require tossing ops out. It requires being somewhat careful with what ops we put *in*.
It's perfectly fine for a good chunk of the ops to not be in the main switch or cgoto loop, and have to be dispatched as indirect functions, the same as any opcode function from a loadable opcode library is. (Hell, some of these can go into a loadable opcode library if we want, to make sure the infrastructure works, including the packfile metadata that indicates which loadable op libraries need to be loaded) I'm also fine with making some of the ops phantom opcodes, ones that the assembler quietly rewrites. That's fine too, and something I'd like to get in.
So, short answer: Ops aren't going away.
Longer answer: We need to add in the following facilities:
1) Op functions tagged (either in their definitions for all permutations, or in the ops numbering metadata file for individual functions) as to whether they're in the core loop or not. Ones that aren't hit the switch's default: case (and the cgoto core's equivalent, and the JIT's perfectly capable of handling this too) and get dispatched indirectly.
2) The assembler and PIR compiler need to be taught appropriate transforms, which then *could* allow for "add N2, I3, N3" to be turned into "add N2, N3, I3" if we decide that in commutative IxN ops it's OK to make them NxI and so on. (Comparisons too, up to a point -- we can't do this with PMCs)
3) The loadable opcode library stuff needs to be double-checked to make sure it works right, so we can create loadable libraries and actually load them in
4) The metadata in packfiiles to indicate which loadable opcode libraries are in force for code in each segment needs to be double-checked to make sure it works right
5) The ops file to C converter needs to have a knockout list so we can note which combinations aren't supported (and believe me, I fully plan on trimming hard, but only *after* we're functionally complete) or, if we'd rather, it can respect the ops numbering list and just not generate ops not on it.
Once this is done the only difference between 'real' opcodes and fixed-arg low-level functions is which are in the switch/cgoto/jit cores and which aren't, something that should be transparent to the bytecode and tunable as we need to. Which is as it should be.
The list of opcode functions is going to grow a lot, and there's really no reason that it shouldn't. With proper infrastructure there just isn't any need for there to be a difference between opcode functions and library functions.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
