Dan Sugalski <[EMAIL PROTECTED]> wrote: > ... 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 seems that it was a bit unclear what my patches did. The confusion seem to arise from the usage of the term opcode. I used it as opcode in the sense: it's handled directly by the run core. The switched core has a case statement for it, the CGoto core has an entry in it's address table and the JIT emits a machine code equivalent. Your usage of opcode seems to be the outer view of a programmer: can I write: acos Nx, Iy or add Nx, Iy, Nz > 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, That's exactly what I've written in that mail. > 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. This is mainly for the function- or method-like opcodes I presume. > 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) Yep, that's what my patch did. And I did *not* touch 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 Lets postpone the loadable ops stuff a bit. We have to lay out first, where they are in force, what about multiple threads and so on. > 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. Ok. And I've made a proposal for the infrastructure too. Please read again the mail and the two about PIC. leo
