From: john/lori (lgnjh_at_earthlink.net)
Date: 2005-04-23 17:56:17
Jim Brain wrote:
> It gets worse. The opcode in question could have updated an internal
> register:
>
> $67ff and #$10
>
> 67ff (and) gets pulled.
>
> $6800 is page fault, so force 0. Uh oh, as now .A is corrupt, and there
> is no way to reset it.
>
> The only real way to do this is not allow such things to occur. Scan
> incoming code at page boundaries to insert BRK opcodes to handle such
> issues before you step into them. Or, ensure code that runs in your
> system does not create such issues.
>
> Jim
There have been schemes (or so I've read) that run a slave processor in
parallel to make internal stuff available that would not otherwise be
available
How about running a slave processor but let it lag by one
instruction and take the internal stuff from it when your hardware
throws an exception?
Of course the devil is in the details (I'm imagining feeding the slave
bytes through an fifo)
The timing and/or hardware might get hairy, but I don't see a problem
in principle (just off the top of my head), except being sure the slave
behaved identically (eg. bug fixes or different behavior with
undocumented "opcodes")
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.