Concerns about performance w/Python, Pysco on Pentiums

[Peter Hansen]

Pedro Rodriguez wrote:
> 
> If I focus on the "try/except", and pick up your comment that this should
> not be frequent to fall in the exception case, so why clutter your code
> with this test (or any test, like the one I posted) ? Just consider that
> all opcodes are valid, but that the action for some will raise the
> exception (def executeINVALIDOPCODE(): raise ...).

That's an excellent idea that I hadn't considered.  Although the
HC12 itself has effectively no unimplemented opcodes, and my 
exception is there just until more than 34 are implemented, it's
likely I will never implement some 50 or so of the opcodes as our
real code doesn't use them.  I'll throw in something to auto-build
256 "dummy" opcodes on startup, then allow them to be substituted
with the real ones as they are defined.  Thanks. :)

> What about the next test, with the returned new PC, why not have the
> opcode method do the proper job, only when needed (by passing the
> opcode mode to the execute method, or just knowing, by design of the
> opcode method, how it will affect the CPU PC).

Something like that will probably happen, eventually, but right now
the opcode handler functions are actually unaware of the specific
opcode being executed and therefore don't know which addressing
mode should be used.  I could pass in the opcode, but as far as I
can tell I'm then making the opcode handlers do something that
the CPU itself is supposed to do (thus increasing the amount of
duplicated code, thus reducing maintainability), *plus* I'm now
passing in two parameters instead of just one when I call execute().

Thanks for the ideas.  The thoughts on restructuring are good, but
I'm going to trust in the test-driven development (TDD) approach
to lead the design.  If the code needs to go in the direction 
you suggest, it will lead me there on its own. 

-Peter